Data residency
[ aligned ]us · eu · apac — available
[ what it actually means ]
Data residency is the commitment that your content is stored in a region you choose — for regulatory reasons, contractual reasons, or simple sovereignty preference. It is narrower than people often assume: residency governs where data lives at rest, and unless stated otherwise, processing and support access can still cross borders. We offer residency in the US, EU, and APAC, and we are specific below about what stays in region and what does not, because a residency promise with unstated exceptions is a residency problem waiting to be discovered.
[ our posture ]
Three regions, chosen at workspace creation
US, EU, and APAC. The region is set when a workspace is created, applies to user content and context data at rest, and does not change silently — migration between regions is an explicit, logged operation initiated by the customer.
What stays in region — and what does not
User content, context graph data, and run traces stay in the selected region at rest. Billing records, account metadata, and aggregate operational telemetry are global. Model inference may route outside the region unless region-pinned routing is enabled, which constrains the model pool and is the customer's trade-off to make.
Transfers covered by SCCs
Where data does cross borders — support access, global metadata — transfers from the EU run under Standard Contractual Clauses in our DPA, with the subprocessor list stating each vendor's region.
Residency is verifiable, not asserted
Enterprise customers can request the storage-region configuration for their workspace and the audit-log entries for any cross-region access. A residency claim you cannot check is marketing; ours is a query.
[ request documentation ]
Region configuration documentation, the cross-border data-flow summary, and SCC module details are available on request.
More frameworks