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.

Updated 3 Aug 20263 min read

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-1

Your container runs an independent instance in each region. When you add a region, Bahriya:

  1. Creates a deployment in the new region.
  2. Applies the container's secrets and registry pull credentials to that region.
  3. Provisions a TLS certificate for the container's hostname there.
  4. 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:

ModeHow it routes
NoneThe hostname resolves to a single primary region only.
Round-robinThe hostname resolves to every region's IP at once; clients rotate between them, spreading traffic roughly evenly.
GeoEach 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.

Note

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.

From the blog