Key facts
| Data planes | EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) region-locked planes |
| Processing boundary | Requests, logs, embeddings and stored artefacts stay in the selected plane |
| Deployment tiers | In-region cloud, private endpoint in your VPC, on-prem and air-gapped |
| Failover | Multi-region failover designed to respect the jurisdiction you select |
| Contracts | DPA with GDPR Article 28 terms, SCCs and PDPL alignment; subprocessor list published |
| Latency note | A strict boundary can add round-trip time — measure p50 and p95 before cut-over |
| Plane selection | EU, GCC, APAC and US planes; VPC, on-prem and air-gapped tiers |
| DR posture | Multi-region failover designed to respect the selected jurisdiction |
TL;DR
- Region-locked planes keep requests, logs and artefacts in the jurisdiction you select.
- VPC, on-prem and air-gapped tiers cover in-country processing requirements.
- Publish a reference diagram that maps every store to a plane and an owner.
- Audit dependencies beyond the AI endpoint — identity and observability move data too.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Classify the workload's data and pick the plane or deployment tier it requires.
- Pin the workspace to that boundary and confirm prompts, embeddings, logs and backups follow it.
- Collect the DPA, subprocessor list and region-scoped audit exports for review.
- Assign a plane per workload class and document the failover path for each.
- Include identity, observability and storage dependencies in the data-flow map.
- Keep plane selection in configuration and rehearse a workload migration.
Try it yourself
Open the data residency checker →
Data residency for enterprise architects: what changes
Enterprise architects turn residency from a contract promise into a diagram: which plane, which stores, which failover path, which evidence. The deliverable is a reference architecture that shows where data lives at every step — including logs, embeddings and backups — and what happens when a region degrades.
A region-locked data plane keeps processing and storage in the jurisdiction you select instead of routing globally by default. Plugsky exposes EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) planes; requests, logs, embeddings and stored artefacts stay in the chosen plane. Where in-country processing is mandatory, the same OpenAI-compatible API runs in your VPC, on-prem or air-gapped, putting the boundary under your control.
Architecture and controls
Choose planes per workload class, define failover policy so it respects the selected jurisdiction, and make the control plane's location explicit. Map each store to a plane and name the owner who can prove it during an audit.
Integration pattern and rollout
Design for change: residency requirements shift by country and contract, so keep plane selection in configuration and model the migration path for a workload that must move. VPC, on-prem and air-gapped tiers cover cases where a managed plane is not enough.
Residency is architecture plus evidence: map every store — prompts, embeddings, logs, backups — to a plane, confirm that failover respects the jurisdiction, and review the DPA, subprocessor list and region-scoped audit exports. Latency and residency trade off, because a strict boundary can mean longer round trips than a globally distributed endpoint.
Limits, evidence and cost
Multi-region failover is designed to respect jurisdiction, but your dependencies may not be: identity providers, observability vendors and CDNs can silently move data. Audit the full path, not just the AI endpoint.
Self-serve pricing is flat monthly with unlimited fair-use usage, so pinning a workload to a plane does not change the billing model — see the live pricing page. Start on the free plan with plugsky-micro and plugsky-lite and no card, and use the 14-day full-access trial to evaluate larger models.
Honest comparison
| Concern | Plugsky residency | Typical global API | Self-hosted |
|---|---|---|---|
| Plane choice | EU, GCC, APAC and US region-locked planes | Few regions, global default routing | Wherever you install it |
| Store coverage | Prompts, embeddings, logs and artefacts follow the plane | Varies by service | You own every store |
| Failover | Designed to respect the selected jurisdiction | Often global | Your DR design |
| Evidence | Region-scoped logs, DPA and subprocessor list | Contract-level commitments | You produce all evidence |
| Operational load | Managed planes with configurable residency | Managed, limited control | Hardware, patching and capacity |
| Reference architecture | Plane per workload class with jurisdiction-aware failover | Few fixed regions | You design every region |
Frequently asked questions
How do we verify data residency?
Check the plane configuration, confirm that prompts, embeddings, logs and backups follow the boundary, review the DPA and subprocessor list, and test failover behaviour.
Which regions are available?
Plugsky exposes EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia) region-locked planes, plus VPC, on-prem and air-gapped deployment options. See the docs for current detail.
Does residency add latency?
It can. A strict boundary may mean longer round trips than a globally distributed endpoint, so measure p50 and p95 from your own production network before committing.
How should we choose planes?
Map workload classes to jurisdictions first, then pick the plane per class. Keep the selection in configuration so requirements can change without redesign.
What dependencies can break residency?
Identity providers, observability tools, CDNs and support tooling can move data across borders. Audit the full path, not just the AI endpoint.
Is in-country processing available?
Yes — VPC, on-prem and air-gapped deployment tiers are available where a managed plane is not sufficient.