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 |
| Sovereign tiers | In-region cloud, VPC, on-prem and air-gapped for citizen-data workloads |
| Identity | SSO/SCIM and RBAC with region-scoped audit events |
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.
- Sovereignty covers people and process, not only storage location.
- Assemble the evidence pack before the pilot, not after the contract.
- 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.
- Choose the deployment tier against the classification of each workload.
- Federate identity through the government directory with SSO and SCIM.
- Rehearse failover and audit export as part of the pilot evidence.
Try it yourself
Open the AI data residency checklist →
Data residency for government teams: what changes
Government workloads tie residency to sovereignty: citizen data stays under national jurisdiction, processing is accountable, and the supply chain is documented for procurement. The bar is not only where data is stored but who can reach it and under which legal process.
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
Use in-region cloud, VPC, on-prem or air-gapped tiers depending on classification, and keep keys, logs and backups inside the same boundary. Federate identity through your own directory with SSO (SAML 2.0 or OIDC), SCIM provisioning and RBAC scoped to public-sector roles.
Integration pattern and rollout
Build the evidence pack early: plane configuration, deployment tier, DPA and subprocessor list, audit exports and support model. Pilot with a citizen-facing, read-heavy workload, prove the boundary in an exercise, and widen scope only when the evidence holds.
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
Region-locking is necessary but not sufficient for sovereignty: personnel access, support paths and administrative tooling matter too. Plugsky's certifications are in progress rather than complete, so record readiness honestly in procurement documents.
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 |
| Sovereignty | In-region, VPC, on-prem and air-gapped tiers | Mostly commercial regions | You own national 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.
Which deployment tier suits classified work?
Air-gapped or on-prem tiers keep processing inside your environment. Choose based on classification and validate with your own authority.
How do we federate identity?
Use SAML 2.0 or OIDC SSO with SCIM provisioning, and scope RBAC to public-sector roles so administrative access stays accountable.
What evidence should procurement request?
Plane configuration, deployment tier, DPA and subprocessor list, audit exports, support model and a complete data-flow map.