Data residency
Where workspace data is stored, how regional rules are enforced, and who is responsible for what.
Storage regions
| Region | Code | Status | Typical use |
|---|---|---|---|
| United States | us-east | Primary, default | Global workspaces, US customers |
| European Union | eu-central | Secondary, opt-in | GDPR-pinned workspaces |
| Brazil | br-south | Planned, Sprint 6 | LGPD-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-southopens, Brazilian workspaces are served fromus-eastwith Standard Contractual Clauses plus an international transfer clause in the DPA, and can pin toeu-centralif preferred. Erasure and DSAR SLAs are identical in every region. - US workspaces. Served from
us-eastwith 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.
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:
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
| Policy | Behaviour |
|---|---|
none (default for EU-pinned) | Backups stay in-region, across availability zones only |
in-region-multi-az | Synchronous 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
| Area | eworks.cloud | Customer |
|---|---|---|
| Physical and infrastructure security | Yes | — |
| Platform patching, hardening, network controls | Yes | — |
| Encryption at rest and in transit | Yes | — |
| Availability, backup, disaster recovery | Yes | Test your restore expectations |
| Identity provider configuration and hygiene | Federation support | Owns IdP, MFA policy, offboarding |
| Role and department assignment | Enforcement | Deciding who gets which role |
| Content placed in the platform | Storage and isolation | Legality, accuracy, minimization, classification |
| Choosing residency and retention | Options and enforcement | The decision itself |
| API key handling on your side | Rotation tooling | Keeping keys out of code and logs |
| Reviewing audit logs and alerts | Generation and retention | Acting on what they show |
| Regulatory role | Processor / operator | Controller |