Multi-Region Deployments
Running a container in more than one region puts it closer to your users and keeps it available through a regional outage. This article explains how a multi-region deployment is set up, how traffic is routed to it, and how it is billed.
Running a container in more than one region puts it closer to your users and keeps it available through a regional outage. This article explains how a multi-region deployment is set up, how traffic is routed to it, and how it is billed.
Deploying across regions
You select the regions a container runs in when you create or edit it — in the console, or by repeating the --regions flag in Reis:
reis container:create \
--type http \
--name "Web API" \
--handle web-api \
--image ghcr.io/myorg/api:v1.0.0 \
--project my-project \
--port 8080 \
--regions falkenstein-1 \
--regions virginia-1 \
--regions singapore-1Your container runs an independent instance in each region. When you add a region, Bahriya:
- Creates a deployment in the new region.
- Applies the container's secrets and registry pull credentials to that region.
- Provisions a TLS certificate for the container's hostname there.
- Adds the region's IP to the container's DNS records.
Removing a region reverses this — the deployment is torn down, DNS records are withdrawn, and the region's resources are cleaned up. Each instance is isolated and serves traffic on its own.
How traffic is routed
With more than one region live, a DNS mode decides which region a given request reaches. You set it per container:
| Mode | How it routes |
|---|---|
| None | The hostname resolves to a single primary region only. |
| Round-robin | The hostname resolves to every region's IP at once; clients rotate between them, spreading traffic roughly evenly. |
| Geo | Each user is routed to the nearest region based on where their DNS query originates. |
Round-robin gives you simple global load distribution; geo minimises latency by sending users to their closest instance. Both keep working if a region stops responding — its IP drops out of rotation and clients reach a healthy region instead. See DNS modes for the details and when to use each.
Multi-region routing suits stateless applications, or ones that handle session affinity at the application layer. Any region may serve any request, so do not assume a user returns to the same region on their next call.
Redundancy
Because each region is an independent instance, a problem in one region does not take the others down. With health-aware routing, an unhealthy region is removed from rotation and traffic continues to be served from the rest. Running in two or more regions is the simplest way to keep a service available through a regional outage — give your container a health check so the platform can tell healthy regions from failing ones.
Billing per region
Each region where your container runs is billed independently. A container running in three regions with two replicas each has six replicas billed globally. Premium regions carry a higher rate than standard ones. Add regions for the reach and resilience you need, and keep an eye on the multiplier — three regions is roughly three times the compute cost of one. See How billing works.
Related
From the blog