Data residency
Where a Startup stores and processes its records, set once to the US or the EU, with each customer free to take its own region.
A Startup stores and processes its records in one region, us or eu, chosen before its first record. Each customer can take its own region, whatever the Startup's.
Pick a region
Residency is a Setting with the value us or eu. A Startup inherits it from its Studio unless it sets its own.
The Setting locks once the first record exists, so pick it at the start. To set it, tell your agent "keep the data in the EU", or call Setting.update.
What stays in region
| Stays in region | Detail |
|---|---|
| Records | The owner database and every step that reads it |
| Files | Uploads, documents and media |
| Analytics | The analytics copy of every Event |
| Backups | Every copy and replica, and the archive copy, which sits in a second region inside the same residency |
| Model calls | Routed to models served inside the region |
Every Action records the region it ran in, so the answer to "where was this processed" is a record, not a promise.
A customer in another region
A Customer of your App gets its own Tenant, and a Tenant takes its own region when it is provisioned. A US Startup can serve an EU clinic whose records never leave the EU.
Visitors without consent
A Visitor who has not given Consent is counted by a hash that rotates daily. No cookie is set, and no IP address is stored.
Who else processes it
The platform's subprocessors are named in one table, each under a data processing agreement. A new one appears 30 days before it processes any personal data, and a Customer with a data processing agreement may object in that window.
Answering where data lives
The Privacy and Compliance Systems answer a customer's data-location questions from these records. GDPR applies when a Startup processes personal data of people in the EU or UK, and the framework map shows the Controls that meet it.