Data Protection and Residency
Where your data lives, and how it is protected while it lives there, comes down to two things you control directly: how sensitive values are stored, and which regions you deploy to. This article explains both so you can make an informed choice.
Where your data lives, and how it is protected while it lives there, comes down to two things you control directly: how sensitive values are stored, and which regions you deploy to. This article explains both so you can make an informed choice.
Encryption at rest for secrets
Sensitive values you place in the vault — secrets, registry credentials, and the private keys inside TLS bundles — are encrypted before they are ever written to disk. They stay encrypted at rest, and the plaintext is materialised only at deployment time, inside the isolated environment that prepares your container's runtime, then discarded immediately afterwards.
The console and API surface metadata only — handles, names, version counts, attached projects — never the stored value. A value you save cannot be read back out of the platform. See Secrets for the full lifecycle.
Traffic to your containers is encrypted with TLS, and communication between the platform's own components is encrypted in transit. See TLS and certificates.
Encryption at rest covers vault items. Data your application writes to its own storage — persistent volumes, an external database, a cache — is yours to protect according to that store's model. Keep anything sensitive in the vault rather than in plain environment variables or on disk.
Choosing regions for residency
You decide which regions a container runs in. A container's data — the requests it serves and the state it holds — is processed in the regions you select, and nowhere else. If your application must keep processing within a particular jurisdiction, deploy only to regions in that jurisdiction.
Bahriya currently operates four live regions:
| 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 |
To keep processing within Europe, for example, deploy only to helsinki-1 and falkenstein-1 and add no region outside Europe. Residency here is a direct consequence of the regions you choose — there is no hidden replication to regions you did not select.
What crosses a region boundary
- Your application's traffic stays in the region serving it. Each region runs an independent, isolated instance of your container.
- Vault items are provisioned only to the regions where an attached container runs. A secret used by a container that runs only in
helsinki-1is applied only tohelsinki-1. - DNS routing decides which region a given user reaches, but the request is then served entirely within that region. See DNS modes.
If you run in multiple regions, each is a separate copy — plan where your data lives by planning which regions you enable.
Isolation between workloads
Each project runs in its own isolated network space, and no shared state exists between different customers' workloads. Containers in one project cannot reach containers in another, even within the same organisation, unless you explicitly allow it with a network policy. See Private networking.
Practical guidance
- Keep sensitive values in the vault, never in plain environment variables or baked into an image.
- Choose the smallest set of regions that meets your latency and residency needs — fewer regions means a smaller footprint to reason about.
- If residency requirements are strict, document which regions each workload is permitted to run in and review deployments against that list.