Multi-Cluster

The cluster registry, not a static documentation list, is the source of truth for currently enabled deployment locations.

Discover enabled locations

1ctl cluster list
1ctl cluster zones

cluster list reports enabled cluster identity, zone, endpoint, priority, default selection, and current health. cluster zones returns the deployment-zone values accepted by user-facing placement workflows. Both commands support --output json.

At the time this guide was verified, the registry returned one healthy default cluster, kul, in zone my-kul-1b. Treat that as an observation, not a permanent topology guarantee.

CLI fields

1ctl deploy and satusky.toml can carry multi-cluster intent:

1ctl deploy --multicluster --multicluster-mode active-passive --backup-enabled

[multicluster]
  enabled = true
  mode = "active-passive"
  backup_enabled = true
  backup_schedule = "daily"
  backup_retention = "168h"
  backup_priority_cluster = 1

Treat these as deployment intent fields. They do not prove that more than one compatible cluster is currently enabled, nor do they imply live stateful replication. Check cluster list, application readiness, and the service-specific backup or replication design before making an RPO or RTO claim.

Administration boundary

1ctl admin deployment adopt and routing-adopt are guarded platform operations for transferring legacy reconciliation ownership. They require an audit reason, exact live UID, resource version, generation, a stable request UUID, and confirmation. Tenant credentials can be denied even when every field is valid; these are not general deployment or disaster-recovery commands.