How does data residency work at Plugsky?

Key facts

EU region	eu-central-1, Frankfurt
GCC region	me-central-1, UAE (Riyadh available on Enterprise)
APAC region	ap-southeast-1, Singapore
US region	us-east-1, Virginia
Enforcement	Region-locked data planes — data never leaves the chosen region
Key custody	Customer-managed keys on Enterprise (KMS or HSM)
Controls	Right-to-audit clauses, audit-log export, zero-knowledge mode
Product status	Live

TL;DR

• Four headline data planes: EU, GCC, APAC and US, plus Riyadh on Enterprise.
• Residency is enforced by architecture, not just promised in a contract.
• Prompts, completions, embeddings and logs all stay in-region.
• Enterprise adds BYOK, zero-knowledge mode and right-to-audit clauses.
• Choose the region closest to your users if latency matters; sovereign rules win when they conflict.

How it works, step by step

1. Map which data classes must stay in which jurisdiction before deployment.
2. Pick a data plane — EU, GCC, APAC or US — and pin the workspace to it.
3. Verify that prompts, completions, embeddings and logs are all in scope.
4. Confirm sub-processors for that region and whether any cross-border transfer remains.
5. Add BYOK, audit-log export and right-to-audit clauses for regulated workloads.
6. Document the evidence path: logs, DPA terms and residency attestations for auditors.

Original data

Try it yourself

Open the AI data residency checklist →

What region-locked actually means

A region-locked data plane keeps your prompts, completions, embeddings and logs inside the region you select. That includes the processing path, not only storage: inference, retrieval and observability are pinned to the same jurisdiction. Because the guarantee is architectural, it does not depend on a contractual promise alone — the platform is built so traffic does not route through another region.

Residency is broader than 'where files sit'. Auditors will ask where processing happened, which sub-processors were involved and how you can prove both. Design your evidence trail at the same time as your architecture.

Available regions and what stays in-region

• EU — eu-central-1 (Frankfurt), aligned with GDPR and ISO 27001 expectations.
• GCC — me-central-1 (UAE), aligned with PDPL, DIFC and NSD; Riyadh is available on Enterprise.
• APAC — ap-southeast-1 (Singapore), aligned with PDPA and MAS expectations.
• US — us-east-1 (Virginia), aligned with SOC 2 and HIPAA programs.

Inference, embeddings, RAG collections and logs stay in the selected plane. If your application runs elsewhere, your data still crosses the boundary once — from your runtime to the region — so keep clients close to the region to avoid adding latency.

Choosing a region and proving it

Start from the strictest rule that applies to you, not the cheapest region. A bank under SAMA or CBUAE guidance should default to the GCC plane; an EU healthcare team should default to Frankfurt; a Singapore SaaS with PDPA obligations should start in APAC. Then verify sub-processors for that plane and confirm whether any transfer mechanism such as SCCs is still required for residual data flows.

To prove residency, export audit logs to your SIEM, keep the DPA and sub-processor list current, and use right-to-audit clauses during vendor reviews. Enterprise agreements support custom data-localization addenda.

Trade-offs, honestly

Residency can cost latency when your users are far from the chosen plane: a GCC-pinned workload serving US users will feel the distance. That is a deliberate trade-off, not a defect, and it is usually the right call when regulation is explicit. Where it is not, multi-region designs and read replicas help — but confirm they do not violate the residency rule before enabling them.

One limitation: not every downstream capability is available in every plane at all times. Check model and feature availability per region, and treat cross-region fallback as a policy decision your security team signs off on.

Honest comparison

Consideration	Plugsky region-locked planes	Single global endpoint	Self-hosted regional cluster
Enforcement	Architectural region lock	Contractual only	You build networking controls
Regions	EU, GCC, APAC, US (+ Riyadh on Enterprise)	Usually one or two	Wherever you deploy
Key custody	Customer-managed keys on Enterprise	Vendor-managed	You own keys
Audit evidence	Audit-log export and right-to-audit	Varies	You build everything
Latency	Best when clients are in-region	Optimised globally by vendor	Depends on your footprint
Ops overhead	Managed	Managed	High