Regions

Each service has exactly one region. All replicas of that service remain in the same region. The region is an operator-defined location with a stable ID and a display name. A region can contain several providers, zones, failure domains, and fleet agents.

#Select a service region

New services start in the platform default region. Set the service region under Region in service Settings → Scale. Each option shows the region’s country flag and display name, such as 🇳🇴 Oslo or 🇩🇪 Frankfurt. Flags use the catalog’s explicit country code; the console does not infer countries from names or IDs. The choices come from the platform's region catalog. You cannot enter a free-form region label.

The replica count is the total for the service within that region. The scheduler spreads replicas across failure domains and agents in that region. Scale-up, rollout replacements, failure recovery, and wake relocation all retain the service region. If that region has no eligible capacity, replicas remain pending. Capacity in another region does not change that result. A regional outage does not move the service to another region.

A region change is an explicit service draft change. The next deployment replaces the old replicas in the new region. Old replicas can serve during that controlled replacement until the new replicas pass readiness checks. The platform never changes a service's region because of load or capacity changes.

API clients can omit the region when they create a service. An attached volume with existing data fixes the service region when the request omits a region. Otherwise, the platform saves the configured platform default in the service revision. If no platform default exists, the request must specify a region. It does not defer region selection to each allocation. An update that omits the region preserves the saved service region.

#Traffic and private connectivity

Ingress routes requests to healthy replicas in the service's region. An ingress in another region reaches those replicas through the network. The operator must direct public traffic to a reachable ingress endpoint. The platform does not configure geographic DNS or global anycast.

Services in the same environment retain private connectivity across regions through the encrypted mesh. Private DNS exposes ready replicas in each service's assigned region. Cross-region requests incur network latency and can incur provider transfer charges. Applications must tolerate those delays and network partitions. Use separate services for workloads in different regions.

#Persistent data and sleep

A local volume belongs to one fleet agent. A service with a local volume supports one replica. The volume pins that service to the agent that holds its data. Region selection does not copy or replicate volume data. Automatic volume relocation stays within the source region.

The platform rejects a region edit that conflicts with an attached volume before it saves the draft. This validation also applies to service creation and rollback.

A region outage does not start a database elsewhere with an empty volume. Application replication requires separate services and the application's own replication protocol. Serverless sleep and wake remain service-wide operations within the service region. Wake relocation cannot use another region.

#Operate the catalog

Only platform operators can create or change regions. The fleet page provides Workload regions and Add region. Set Country code to an uppercase ISO 3166-1 alpha-2 code, such as NO or DE. Leave it empty for regions without a country; these display without a flag. Agent enrollment uses a region selector from this catalog. An agent cannot change region while it holds allocations or volumes. Trusted installation inventory also registers its workload regions before agent enrollment. Inventory updates preserve an operator's display name and admission policy.

Clear Accept new services to close a region to new services and explicit moves into that region. Services that already belong there continue to deploy, scale, replace failed replicas, and wake. The admission policy does not remove agents from placement or stop current allocations. Agent cordon and drain operations remain the controls for capacity maintenance.

Use Platform default in the region editor to select the default for new services. Console and API creation use it when the request omits a region. A default change does not move any current service. The platform changes the default atomically and permits only one default. Select another default before you close the current default to new services.

A closed region remains in the catalog, and its existing services retain their region IDs. The catalog has no delete operation, so saved selections retain their identities.

#API and MCP

GET /v1/regions returns the catalog to authenticated users with any token scope. PUT /v1/regions/{regionId} creates or updates a region. The write requires an account-scoped full-access token and platform operator membership. The request body contains name, accepting_services, and country_code. country_code is an uppercase ISO 3166-1 alpha-2 country code or an empty string. An omitted or empty code clears the flag. MCP configure_region accepts the same country_code field.

Set is_default:true to select the platform default. An omitted is_default preserves the current default status. The path supplies the region ID.

Service specs use placement_region, one catalog ID. Repository creation and template requests also accept placement_region for their new services. Allocation status includes region alongside the agent ID. Unknown region IDs fail validation.

MCP provides list_regions and configure_region. The configuration tool returns a preview before confirm:true applies the policy. Service tools, create_service_from_repository, and create_from_template accept placement_region. An omitted region preserves the current service region during an update.