Data Residency
If your workload needs to stay within a particular country or region, you control that directly through the regions you deploy to. This article explains how residency works on Bahriya, which regions are live, and what is on the roadmap.
If your workload needs to stay within a particular country or region, you control that directly through the regions you deploy to. This article explains how residency works on Bahriya, which regions are live, and what is on the roadmap.
Residency follows your region choice
A container runs an independent instance in each region you select, and its data — the requests it serves and the state it holds — is processed only in those regions. There is no background replication to regions you did not choose. Keeping a workload in a jurisdiction is therefore a matter of selecting only regions in that jurisdiction and adding none outside it.
For example:
- Europe only — deploy to
helsinki-1(Finland) andfalkenstein-1(Germany), and add no region elsewhere. - North America only — deploy to
virginia-1. - Asia-Pacific only — deploy to
singapore-1.
The same applies to vault items: a secret or TLS bundle is provisioned only to the regions where an attached container runs, so a value used solely by a Europe-only container stays in Europe.
Residency is about where data is processed, which you set by choosing regions. This is not a legal or compliance certification — if you have formal regulatory requirements, confirm that a given region's location meets them before you rely on it.
Live regions and their locations
These four regions are live today:
| Region ID | Location | Class |
|---|---|---|
helsinki-1 | Helsinki, Finland (Europe) | Standard |
falkenstein-1 | Falkenstein, Germany (Europe) | Standard |
virginia-1 | Ashburn, Virginia, USA (North America) | Standard |
singapore-1 | Singapore (Asia-Pacific) | Premium |
Deploy only to the regions above when residency matters — only these are available to run your workloads.
Planned regions
The following locations are on the roadmap. They are not live and cannot be selected yet; treat them as an indication of direction, not a commitment you can build against today:
- London
- Jeddah
- Fujairah
- Doha
- Istanbul
- Sydney
- Hillsboro, Oregon
- São Paulo
- Lagos
If a planned region is important to your residency plans, check the regions overview for the current live list before committing.
Keeping data in region
- Deploy narrowly. Select only the regions your residency requirement permits. A single-region deployment keeps everything in one place.
- Keep sensitive values in the vault. Vault items are encrypted at rest and applied only to the regions where an attached container runs. See Data protection and residency.
- Mind external dependencies. If your application calls out to a third-party service, that request leaves the region. Constrain and document those calls — a network policy can limit outbound destinations.
- Review multi-region setups. Adding a region for latency or redundancy also means data is processed there. Make that choice deliberately when residency is a constraint.