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 |
| Transfer posture | DPA with GDPR Article 28 terms, SCCs and PDPL alignment; subprocessors published |
| Evidence | Region-scoped audit logs exportable to SIEM for examiner review |
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.
- Map each data category to a plane and prove failover stays in-jurisdiction.
- Collect region-scoped logs and DPA wording as review evidence, not afterthoughts.
- 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.
- Classify data categories and assign each an approved plane before migration.
- Test failover in a controlled exercise and confirm it respects the jurisdiction.
- Assemble the DPA, subprocessor list and region-scoped audit exports for review.
Original data
Try it yourself
Open the data residency checker →
Data residency for banks: what changes
Banks face localisation rules, cross-border transfer restrictions and examiner questions about where every byte lives. A residency architecture that survives review maps each data category to a plane, proves that failover stays in-jurisdiction, and produces logs an examiner can read without translation.
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
Classify data first — customer records, transaction data, model inputs, logs — then pin each class to an approved plane. Confirm that backups and failover respect the same jurisdiction, and make sure audit events are stored and exportable from the same region.
Integration pattern and rollout
Run a residency proof before signing: inspect the plane configuration, test failover behaviour in a controlled exercise, and collect the DPA, subprocessor list and region-scoped logs. Because the API is OpenAI-compatible, moving a workload between planes is configuration rather than a rewrite.
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
Residency is not confidentiality: region-locking keeps data in place while encryption and access control limit who can read it. Combine both, and validate the jurisdictional question with counsel rather than assuming a region list settles it.
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 |
| Examiner evidence | Region-scoped logs, DPA and subprocessor list | Contract-level commitments | You produce all evidence |
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 do we prove residency to an examiner?
Show the plane configuration, region-scoped logs, the DPA and the subprocessor list, and demonstrate failover behaviour in a controlled exercise.
Does failover respect the jurisdiction?
Multi-region failover is designed to respect the selected jurisdiction. Validate the behaviour for your workspace during testing rather than assuming it.
What about backups and logs?
Treat them as datasets: confirm they are stored and exported from the same plane as primary data, and include them in your data map.