Data residency

Where workspace data is stored, how regional rules are enforced, and who is responsible for what.

Storage regions

RegionCodeStatusTypical use
United Statesus-eastPrimary, defaultGlobal workspaces, US customers
European Unioneu-centralSecondary, opt-inGDPR-pinned workspaces
Brazilbr-southPlanned, Sprint 6LGPD-pinned workspaces (today served from us-east under SCCs)

What stays inside the selected region: chat messages, uploaded documents, embeddings and vector indexes, agent definitions and run outputs, audit events, backups.

What is global by design: workspace name and slug, billing records, aggregate usage counters, and the identity directory entry (email plus IdP subject). These carry no workspace content.

Regional compliance enforcement

  • EU-pinned workspaces. All storage, processing and model inference stay within eu-central. Model providers without an EU endpoint are hidden from the model selector rather than silently routed elsewhere. Support access from outside the EU requires a named, logged, time-boxed grant.
  • Brazil / LGPD. Until br-south opens, Brazilian workspaces are served from us-east with Standard Contractual Clauses plus an international transfer clause in the DPA, and can pin to eu-central if preferred. Erasure and DSAR SLAs are identical in every region.
  • US workspaces. Served from us-east with no cross-border replication unless disaster-recovery replication is explicitly enabled.

Choosing residency at onboarding

Residency is chosen once, when the workspace is created, in Settings → Workspace → Data residency. It cannot be changed in place — moving regions means a supervised migration.

bash
curl -X POST https://api.eworks.cloud/v1/workspaces \
  -H "Authorization: Bearer $EWORKS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Acme EU","residency":"eu-central","enforce_mfa":true}'

Read the current setting:

bash
curl -s https://api.eworks.cloud/v1/workspaces/$WORKSPACE_ID \
  -H "Authorization: Bearer $EWORKS_TOKEN" | jq '{residency, replication, created_at}'
Plan before you provision. A residency migration requires a maintenance window, re-indexing of embeddings, and re-issued API keys. Decide with your privacy team before the first production workload lands.

Cross-region replication

PolicyBehaviour
none (default for EU-pinned)Backups stay in-region, across availability zones only
in-region-multi-azSynchronous replicas in the same region, RPO ≈ 0, RTO under 15 minutes
cross-region-dr (opt-in)Encrypted asynchronous copy to a named secondary region, RPO 15 minutes

Cross-region disaster recovery is off by default. Enabling it for an EU-pinned workspace requires an explicit acknowledgement that data will leave the region, and the acknowledgement is written to the audit trail with the acting admin's identity.

Backups are retained 35 days, encrypted with a separate key, and restore requires two-person approval.

Customer responsibility matrix

Areaeworks.cloudCustomer
Physical and infrastructure securityYes
Platform patching, hardening, network controlsYes
Encryption at rest and in transitYes
Availability, backup, disaster recoveryYesTest your restore expectations
Identity provider configuration and hygieneFederation supportOwns IdP, MFA policy, offboarding
Role and department assignmentEnforcementDeciding who gets which role
Content placed in the platformStorage and isolationLegality, accuracy, minimization, classification
Choosing residency and retentionOptions and enforcementThe decision itself
API key handling on your sideRotation toolingKeeping keys out of code and logs
Reviewing audit logs and alertsGeneration and retentionActing on what they show
Regulatory roleProcessor / operatorController

Next