Where your data lives

EasySiteControl connects to a database you own. Your content, your uploaded files and your own users stay there. This page lists every collection on both sides, so the claim can be checked rather than taken on trust.

In short

Content and end users never enter our database

Every record, form submission, uploaded file and end-user account lives in the MongoDB the client supplied and in the object storage bucket they configured. Our database holds no copy, cache or backup of any of it.

What we hold is what routing requires

A subdomain, a workspace name, the accounts of the people who administer it, and an encrypted connection string. That is the complete set. Without it a request to a workspace cannot be resolved to a database.

We can technically reach a client database, and that is auditable

We hold the key that decrypts connection strings, so a platform administrator can cause the system to connect to a client’s database. This is unavoidable for a service that connects on the client’s behalf. Every platform-admin action is written to an append-only audit log, and suspending or deleting a workspace never touches the client’s data.

Deleting a project deletes our pointer, not the client’s data

Removing a project or an entire workspace deletes the registry rows that route to it. The client’s database and bucket are untouched and remain fully theirs — which also means deletion here is not erasure, and an erasure request has to be carried out in the client’s own database.

Migrating from v1 reads the client’s old database, and writes nothing back to ours

Importing a v1 project reads that project’s legacy collections in place — including v1’s own `roles` — and writes the converted result into the client’s v2 database. Nothing from the imported content passes through the platform registry.

Credentials are write-only

Connection strings, SMTP passwords and storage secret keys go in and never come back out. The API returns them masked, error messages redact them, and they are never written to logs.

Your database — on infrastructure you control

The MongoDB you supplied when creating a project, plus the object-storage bucket you configured. We connect to these; we do not host, replicate or back them up.

schemas / standalone_schemasconfiguration only

Content type definitions — field names, types and validation rules.

modelsconfiguration only

Reusable field groups embedded by component and dynamic-zone fields.

schema_<name>_recordsmay contain personal data

The content itself. One collection per content type.

Whether this holds personal data is entirely the client’s decision — it is whatever they chose to model and publish.

schema_<name>_historymay contain personal data

Per-record change history, including the content before and after each edit and who made it.

Retains deleted content by design, so a mistaken delete is recoverable. Relevant to erasure requests: deleting a record does not erase its history.

<name>_dataconfiguration only

The single document behind a standalone schema — site settings, homepage copy and similar.

project_usersmay contain personal data

People the client invited into the project: email, name, bcrypt password hash, role, invitation and password-reset tokens.

project_rolesconfiguration only

Role definitions and the permissions each grants.

apikeysconfiguration only

API keys as bcrypt hashes, with their permission list, display prefix and last-used time.

The key itself is shown once at creation and never stored in a form we can recover.

mediaFilesmay contain personal data

Metadata for uploaded files: filename, object key, size, MIME type, directory, uploader.

Metadata only. The file bytes live in the client’s own S3-compatible bucket, which we never proxy — the dashboard links directly to it.

forms / form_submissionsmay contain personal data

Form definitions, and everything submitted through them.

Submissions are typically the most sensitive collection in the database: they are whatever a website visitor typed into a contact or application form.

events / event_executionsmay contain personal data

Automation definitions, and a log of each run including the payload that triggered it and the outcome of every action.

Execution payloads embed the record or submission that fired the event, so this log inherits their sensitivity.

endpointsconfiguration only

Custom endpoint definitions: method, slug, auth mode, flow steps and response template.

Invocations are logged to event_executions, so endpoint request bodies inherit that log’s sensitivity.

email_templates / email_logsmay contain personal data

Email templates, and a delivery log of recipient address, subject, source and result.

project_integrationsconfiguration only

The project’s SMTP, S3 and Redis credentials.

Encrypted at rest with the same AES-256-GCM envelope scheme as connection strings. Passwords and secret keys are never returned by the API, even to the workspace owner — they are write-only.

auth_schemas / auth_data_<name>may contain personal data

End-user authentication: the schema definition, and the client’s own end users — email, bcrypt password hash, verification and reset tokens, plus whatever profile fields the client defined.

These are the client’s customers. They exist only in the client’s database and are never copied into ours.

Our database — the platform registry

Everything we store, in full. Its only job is to turn a request for your subdomain into a connection to your database.

clientsconfiguration only

Workspace identity: subdomain, display name, status, timestamps.

ownersmay contain personal data

Workspace owner accounts: email address, name, bcrypt password hash, status, last sign-in.

The only end-user-shaped records we hold. These are the people who administer a workspace, not the client’s own customers.

projectsconfiguration only

Project registry: name, slug, description, status, and the MongoDB connection string for the client’s own database.

The connection string is encrypted at rest with AES-256-GCM envelope encryption. It is the one field here that would grant access to client data, and it is never returned by any API in plaintext.

platform_adminsmay contain personal data

Our own staff accounts: email, name, bcrypt password hash, status, last sign-in.

Our employees, not clients.

admin_auditmay contain personal data

Append-only log of platform-admin actions: who did what to which workspace, and when. Includes admin email and the affected subdomain.

Exists so that any administrative access to a workspace is attributable after the fact.

Practical consequences

  • Erasure requests are carried out in your database. Deleting a project here removes our routing entry only — and note that record history retains deleted content by design.
  • Backups are yours to take. We do not hold a copy of your content to restore from.
  • Data residency follows your database and bucket. Choose their region and your content stays in it.
  • If you leave, your data never has to move. Delete the workspace and your database continues to exist, untouched, with everything in it.