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 |
| When required | Adopt a region-locked plane when a contract demands it |
| 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.
- Keep plane selection in configuration so you can adopt residency on deal demand.
- Only promise regions you can operate and evidence.
- 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.
- Store region and workspace settings in environment configuration from the start.
- Pin the pilot to the customer's required plane and test from their network.
- Collect the DPA and subprocessor list before the first production request.
Try it yourself
Open the data residency checker →
Data residency for startups: what changes
Startups usually begin with a single global plane and meet residency when a customer makes it a condition of the deal. Region selection is configuration on an OpenAI-compatible API, so it can be adopted when the requirement is real rather than pre-built for every jurisdiction.
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
Keep environment configuration ready for a plane switch, and document which stores — prompts, embeddings, logs — must follow the tenant. Until a requirement arrives, use the free plan with plugsky-micro and plugsky-lite and no card to build without procurement.
Integration pattern and rollout
When the deal lands, pin the pilot workspace to the required plane, test latency from the customer's network, and collect the DPA and subprocessor list for their review. Confirm failover behaviour before the first production request.
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
Do not market residency you cannot evidence. Start with one region you can genuinely operate, learn the process, then expand; a promise you cannot document is worse than an honest roadmap.
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 |
| Deal readiness | Adopt a plane when a contract requires it | Usually global only | Over-engineering early |
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.
When should we add a region-locked plane?
When a customer makes it a contractual condition. Until then, keep plane selection in configuration and avoid pre-building regions you cannot operate.
How fast can we switch?
Region selection is configuration on an OpenAI-compatible API, so the code change is minimal. The work is testing, evidence and support readiness.
What should we promise customers?
Only what you can evidence: the plane, the data categories it covers and the audit trail. Keep the roadmap honest.