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 |
| Tenant residency | Select a plane per customer workspace; logs stay in that jurisdiction |
| Delegation | SSO/SCIM and RBAC let customers administer inside their boundary |
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.
- Productise residency as tiers with explicit evidence per tier.
- Keep each tenant's plane mapping in its service record.
- 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.
- Define global, regional and sovereign tiers with their evidence commitments.
- Pin each customer workspace to its required plane at provisioning time.
- Document the plane mapping and audit path in the customer's service record.
Try it yourself
Open the data residency checker →
Data residency for MSPs: what changes
MSPs inherit their customers' residency obligations and multiply them across a portfolio. The service-definition question is which planes you offer, how tenancy maps to jurisdiction, and how you prove separation when one customer's regulator asks and another's does not.
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
Select a plane per customer workspace, keep each customer's logs and artefacts in the same jurisdiction, and use scoped keys and RBAC so delegated administrators stay inside their own boundary. Keep the subprocessor list current and share it in reviews.
Integration pattern and rollout
Productise residency as tiers — global, regional, sovereign — with clear deployment, support and evidence differences. Because the API is OpenAI-compatible, the same integration code serves every tier; tenancy and plane selection are configuration.
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
Operating multiple residency tiers adds process: change management, incident routing and audits per jurisdiction. Price and staff for that overhead rather than treating it as a checkbox, and be explicit about which tier includes VPC, on-prem or air-gapped options.
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 |
| Per-tenant residency | Plane per customer workspace | Usually one global default | You operate each jurisdiction |
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.
Can different customers use different regions?
Yes. Pin each customer workspace to the plane its policy requires, and keep that customer's logs and artefacts in the same jurisdiction.
How do we prove separation at audit?
Use per-tenant workspaces, scoped keys and region-scoped audit exports, and document the plane mapping in the customer's service record.
Do sovereign tiers cost more to operate?
They add process and support overhead in each jurisdiction. Price and staff the tier honestly rather than absorbing it silently.