Regions and zones
Describe location and failure domains for compute, storage, and policy.
Regions group infrastructure that shares placement and storage connectivity. Zones divide a region into failure domains such as separate power or network segments. A rack records a more specific physical location within a zone.
Create an owned region
You have the Organization Admin role. Open Fleet → Regions → Create region, assign a stable region code, and select the permitted node and storage networks. Region codes appear in automation and cannot be changed after resources are created. Display names can be edited.
Create zones before enrolling production nodes. Assign zone names according to physical failure boundaries. Two nodes in the same room do not become independent failure domains because they have different zone labels.
Region codes must be unique within the organization. Zone codes must be unique within their region.
Add allowed projects and node pools explicitly. A project with access to the region can request only the pools and resource classes its effective policy permits. Leave a new region closed to ordinary project admission while validating storage and mesh connectivity.
Record rack location on each node when the placement policy uses rack separation. An omitted rack means that rack-aware admission cannot establish that node's physical independence.
Hosted regions
Hosted regions appear when hosted capacity is enabled for the organization. Operators select from published zones, images, sizes, and storage policies. The physical node inventory is managed by Solarius and is not exposed as an owned fleet. Project resource and operation views remain available.
A self-hosted installation requires a Connector to request hosted capacity. Local regions continue operating independently of Connector health.
The Solarius Compute Cloud reference lists regional compute hostnames. Use the published region and zone identities for placement policy rather than deriving failure domains from those names.
Placement boundaries
A droplet and its attached volumes must belong to the same region. A network interface must use a subnet in that region. A load balancer selects backends that are reachable through its region's network configuration.
Spread groups can require different zones. Storage policies can require replicas in different zones. If the region has too few healthy zones, creation fails or an existing resource reports degraded redundancy. Infra does not silently weaken a required policy.
Move a node's location
Cordon and drain compute before changing a node's zone. If the node stores volume replicas, evacuate or rebuild those replicas under the storage pool's placement policy. A zone change with active placement dependencies is rejected.
Moving a physical server without updating its recorded zone can invalidate failure-domain assumptions. Verify rack, power, network, and storage placement before returning the node to service.
Restrict and retire a region
Remove a project's region permission to prevent new placements there. Existing resources remain managed; the change does not stop them or migrate their data. A residency policy can additionally constrain backups and export destinations.
Before retiring a region:
- Remove project admission under Fleet → Regions → Region to prevent new placements. Existing resources continue running.
- Drain its nodes into eligible capacity, or use disaster recovery to restore workloads elsewhere.
- Remove the region's network services and review retained volumes, snapshots, and backups. Delete only copies no longer required by retention or holds.
- Retire the nodes, then return to the region record and request deletion.
Deletion remains blocked while nodes or application resources refer to the region. The reported dependency IDs identify what remains. Historical operations keep the retired region code for audit lookup.