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 |
| Implementation | Region choice is configuration; the API stays OpenAI-compatible |
| Start cost | Free plan with plugsky-micro and plugsky-lite, no card required |
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.
- Region selection is configuration — the application code stays the same.
- Verify embeddings, logs and object storage follow the same boundary as prompts.
- 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.
- Keep region and workspace selection in environment configuration from day one.
- Pin a staging workload to the target plane and trace every data store.
- Measure p50 and p95 from production networks against candidate regions.
Try it yourself
Open the AI data residency checklist →
Data residency for developers: what changes
For developers, residency is an implementation detail until a contract makes it a requirement. The practical question is how much code changes when a workload must run in a specific jurisdiction: with an OpenAI-compatible API, the answer is configuration — base URL, workspace and region — rather than a rewrite.
Data residency on Plugsky is delivered by region-locked planes rather than by offices: choose EU (Frankfurt), GCC (UAE), APAC (Singapore) or US (Virginia), and prompts, logs, embeddings and artefacts remain in that jurisdiction by default. For stricter requirements the identical API runs in your VPC, on-prem or air-gapped, so the processing boundary matches your own network boundary.
Architecture and controls
Pin the workload to a region-locked plane, then verify the whole pipeline: prompts and logs as well as embeddings and stored artefacts. Check that your vector store and object storage sit in the same jurisdiction, and test latency from your production network before cut-over.
Integration pattern and rollout
Start on the free plan with plugsky-micro and plugsky-lite and no card to build the integration, then select a plane when the requirement arrives. Keep region selection in environment configuration so workloads can move without touching application code.
Treat region selection as configuration rather than code: the workload is pinned to a plane, the OpenAI-compatible call path stays the same, and your tests verify that every data store follows the boundary. Measure p50 and p95 from your own network against candidate regions before committing, and collect evidence — DPA, subprocessor list, region-scoped logs — as you go.
Limits, evidence and cost
A strict boundary can add latency compared with a globally distributed endpoint, and not every managed service you depend on offers the same region. Measure p50 and p95 from your own network and document the trade-off rather than assuming it away.
Region selection is configuration, not a premium add-on on self-serve plans; check the live pricing page for current tiers. The free plan covers plugsky-micro and plugsky-lite with no card, and the 14-day full-access trial lets you test the architecture before you sign anything.
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 |
| Implementation effort | Region is configuration on an OpenAI-compatible API | Varies by provider | You build regional infrastructure |
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 much code changes for residency?
With an OpenAI-compatible API, region selection is configuration — base URL and workspace settings. Your application code stays the same.
Can we test residency before production?
Yes. Pin a staging workspace to the target plane, run the pipeline end to end, and check that prompts, embeddings and logs all follow the boundary.
Does a closer region always mean lower latency?
Usually shorter network paths help, but not always. Measure p50 and p95 from your production network against candidate regions before deciding.