· Yair Knijn
EU data residency without splitting your operating record
The common way teams meet an EU data-residency requirement is to run a second copy of everything in an EU region. It works, and it doubles the operational surface. Now there are two billing exports, two audit logs, two identity configurations to keep in step, and a quarterly task to prove the two halves still agree.
The requirement is narrower than the response. A regulator asks where personal data is stored and processed, and whether it leaves the European Economic Area. It does not ask you to fork your whole platform.
Separate the data plane from the control plane
The data that has a residency requirement is customer content: files, case records, the rows in a product database. That is the data plane, and it can sit in an EU database without the rest of the system moving.
The control plane is different. Identity, subscription state, the catalog, the provisioning job that created your Environment: this is configuration and metadata, not the regulated content. Keeping it in one place is what lets you have a single audit trail and a single bill.
For xEvolve and Automate Certificates, Spot Suite keeps each customer's product data in the shared Supabase Postgres project in the EU (Paris), each customer in its own schema, with every row scoped to its tenant. Files sit in Cloudflare R2 in Western Europe, not pinned to an EU jurisdiction. A paid Guardrail Ledger workspace gets a dedicated Supabase project in the region chosen at signup (Frankfurt for the EU); a trial uses the shared project in Paris. The identity and billing record stays in the shared control plane. One Environment, one set of records, and the regulated data where it needs to be.
Cross-border transfers are an event, not a default
The value of keeping the data plane in one known place is that any transfer out of it becomes visible. If nothing leaves that database for ninety days, that is a fact you can state and show, not a hope.
When a transfer is unavoidable, the lawful path is a documented one: Standard Contractual Clauses or another recognised mechanism, recorded against the event. The point is that the architecture makes the transfer the exception that gets logged, rather than something that happens quietly because a service defaulted to a US region.
What this avoids
You skip the reconciliation tax. There is one audit log to export, not two to merge. There is one place a user's access is defined. The residency control is the data plane your Environment is provisioned on, not a parallel universe you maintain by hand.
xEvolve and Automate Certificates keep their databases in the EU; a paid Guardrail Ledger workspace keeps its database in the region you choose at signup. If you have a specific residency or transfer constraint, tell us what you need and we will scope it.