region parameter in cerebrium.toml controls placement: run globally on whatever capacity is available (recommended), or pin the app to a specific region. The parameter is optional; when omitted, the platform chooses placement automatically based on the app’s hardware requirements.
Why Use Multi-Region Deployment
- More capacity, less queueing: An app that can run anywhere draws on the GPU capacity of every region. Constraining placement shrinks the pool of available hardware.
- High availability: Traffic shifts away from degraded or busy regions automatically.
- Reduced latency: Requests are routed to healthy capacity, preferring lower-latency regions.
- Data residency: Pin an app to a region to keep sensitive data within a specific geographic region and comply with regulations like GDPR and CCPA.
- No duplicate apps: One app, one endpoint, and one configuration instead of a separate deployment per region.
Run Globally
Setregion = "global" to let the platform place the app in any region with available capacity that matches its hardware requirements:
Geography-based placement is coming soon. This constrains an app to a
geographic area such as the US or the EU to meet data-residency requirements.
Pin a Region
Setregion to a specific region to run the app only there:
Available Regions
United States
- us-east-1 (N. Virginia)
- us-central1 (Kansas City)
Europe
- eu-north-1 (Stockholm)
- eu-north1 (Finland)
Available on request
Contact support to enable access to these regions:- us-west-2 (Oregon)
- eu-west-2 (United Kingdom)
- eu-central-1 (Frankfurt)
- ap-south-1 (Mumbai)
- ap-northeast-1 (Tokyo)
- sa-east-1 (São Paulo)
- ca-central-1 (Montreal)
- me-central-1 (Dubai)
Some regions run on cloud providers other than AWS: when pinning
us-central1
or eu-north1, set provider = "nebius".Hardware Preferences
Placement respects both the region and the hardware requirements of an app. Specify acceptable GPU types in preference order with acompute list (see GPU preference lists):
Endpoints
Apps keep a single endpoint no matter how many regions they run in:How Requests Are Routed
- A request enters through the region closest to where it is made, then routes to a region with a warm instance before a cold start is triggered elsewhere.
- Routing prefers lower-latency regions but does not guarantee the nearest region.
- There is no session affinity. Consecutive requests can be served from different regions.
Scaling Across Regions
min_replicas, max_replicas, and scaling_buffer apply to the app as a whole, not per region. The platform distributes instances across eligible regions based on traffic and available capacity.
View where containers are running:
Storage
Persistent storage is managed per region: an app has an independent/persistent-storage volume in each region it runs in, however placement is configured. Files written in one region are not guaranteed to be available in other regions, and region-local caches, such as model weights downloaded on first load, fill independently per region.
Apps deployed with region = "global" also mount /global-persistent-storage, a single volume shared across every region the app runs in. Files written there are visible from all regions, and reads are cached per region. Use the global volume for data that must be available everywhere and /persistent-storage for region-local data. Manage files on the global volume by passing --region global to the file commands. See Managing Files.
Target a region with the file commands using --region (or its short form -r). This works for all file commands: cp, ls, rm, and download.
--region applies only to the command it’s attached to. The default set by
cerebrium region set is not modified.