High availability
Deploy redundant control-plane services and test dependency failure.
A highly available control plane runs redundant management services across failure domains and uses durable shared state. Application workload availability still depends on compute, storage, network, and application design.
Deployment topology
Download the Kubernetes bundle from Deployment portal → Infra → Self-hosted releases and apply it from an administrative terminal connected to the target cluster. Inspect active replicas at Installation settings → Deployment → High availability.
Use the Kubernetes deployment bundle for the pinned Infra release. Place console, API, and worker replicas across separate nodes or zones. Provide an external load balancer and a PostgreSQL deployment with a tested failover procedure.
Every replica must use the same installation identity and compatible encryption configuration. PostgreSQL must expose one authoritative writer with a tested failover procedure. Redundant API processes do not resolve a split database primary.
Choose observation and object storage supported by the multi-replica deployment. Provide redundant HTTPS routing, consistent DNS, synchronized clocks, and access to required key material from every authorized replica. Test shared dependencies as well as individual process loss.
Local directories that work on a single Compose host do not automatically become shared storage in Kubernetes. Select a supported persistent backend and validate its failure behavior before adding replicas.
Initialization and schema
Initialize the installation once. Run schema migrations through the release's coordinated upgrade job before starting incompatible new replicas. Do not run separate setup wizards against the same database.
All active replicas must use a supported release combination. A partially rolled out deployment can continue only within the compatibility range documented by its release manifest.
Worker coordination
Workers claim operation work through persistent coordination state. If a worker fails, another worker reconciles its operation against component state before continuing. A lost worker connection does not imply that the node action stopped.
Avoid stopping multiple workers during migration or storage transitions without checking operation health. Use readiness and graceful shutdown to stop assigning new work before terminating a replica.
Database failure
Database failover defines the promotion and reconciliation checks for a lost management primary.
Loss of writable database access makes configuration changes unavailable. Readiness should remove affected API replicas from normal traffic. Existing workloads can continue when their local dependencies remain healthy.
Database failover must preserve one authoritative writer. Split database primaries can create conflicting management state and cannot be repaired by restarting the API. Follow the database recovery procedure and then reconcile Infra state.
Test failure scenarios
Test the loss of one API replica, one worker, an edge backend, a database primary, and a zone-sized dependency set. Observe request failure, operation recovery, agent reconnect behavior, and retained audit continuity.
Perform tests with representative long-running operations. A successful console page reload tests less than a migration interrupted during ownership transfer. Use Control-plane health to record backlog and recovery.
Backups
Redundancy does not replace control-plane backups. Logical corruption, mistaken deletion, and compromised credentials can affect all replicas. Keep independently protected recovery copies and test restoration into an isolated installation.