Skip to content

Compose a high availability deployment

The deployment administrator chooses Authority availability, Proxy availability and the hosting platform independently. A load balancer is an entry point to a component; bootstrap admits an Authority to its HA group. These choices apply whether roles share hosts or run on separate hosts.

Decision Options Procedure
Hosting platform Linux services, Compose, Kubernetes or Swarm Deployment examples
Authority One instance; HA with individual destinations; HA behind an L4 LB Authority HA
Authority admission and keyring synchronization Initialize once, bootstrap each additional instance, reload changes automatically Bootstrap and synchronization
Proxy One instance; HA behind an L4 LB Proxy HA
Certificates and Connector route IP or DNS entry; direct, fronted or tunneled Certificates, routes

HA Authority needs a shared PostgreSQL store, stable instance owners, individual private peer addresses and consistent integrity material. Proxy HA needs separate enrolled identities, individual private peer addresses and a common entry point. Configure the selected parts before exposing a node.

Choose the components

Composition Authority routing Proxy routing Complete example
Public L4 LB → HA Proxy → HA Authority without an Authority LB Each Proxy has primary and fallback Authority control and registration destinations Public LB plus private Proxy peers Direct Authority failover: Linux or Compose
Public L4 LB → HA Proxy → private L4 LB → HA Authority Each Proxy dials the Authority LB; Authorities retain individual peers Public LB plus private Proxy peers Authority LB: Linux or Compose
One Proxy → private L4 LB → HA Authority The Proxy dials the Authority LB; no Proxy peering needed Existing single Proxy entry point Authority HA with LB
Public L4 LB → HA Proxy → one Authority Both Proxies dial the same Authority; no Authority bootstrap Public LB plus private Proxy peers Proxy HA

A shared store or a balancer can itself be a single failure point. The deployment owner arranges their availability separately. Multiple processes on one host verify process failures; they do not cover loss of that host.

flowchart LR
    LB[Public L4 LB] --> P1[Proxy A]
    LB --> P2[Proxy B]
    P1 --> A1[Authority A]
    P1 --> A2[Authority B]
    P2 --> A1
    P2 --> A2
    P1 <--> P2
    A1 <--> A2
    A1 --> DB[(Shared PostgreSQL)]
    A2 --> DB

For an Authority LB, insert it between the Proxies and the Authorities. Keep the direct Authority-to-Authority and Proxy-to-Proxy peer paths. An Authority LB carries private control and registration traffic; clients reach the Proxy entry point.

Deploy in dependency order

The deployment owner supplies the store, OIDC settings, certificate trust, private addresses, public entry addresses and firewall rules. Use the same security profile on all roles.

  1. Select the platform and open the required paths from the component guides.
  2. For HA Authority, initialize the first instance and bootstrap the others. Verify matching keyring revisions, readiness and leader takeover.
  3. Select individual Authority destinations or configure its ready LB pool.
  4. Enroll each Proxy separately. For Proxy HA, configure peers and publish only ready backends through the public LB.
  5. Register Connectors through the selected entry, verify two distinct tunnels and central recording, then run deployment acceptance.

Do not continue past a failed readiness, trust or keyring check. Follow the component's recovery procedure before exposing that instance. Never share node identity directories or delete a keyring watermark to make a check pass.

Verify each failure boundary

Run these tests in an acceptance window, restoring each component before testing the next failure. Keep the topology and results with the deployment record; omit secrets and private keys.

Failure Expected result Diagnose through
Stop the Authority write leader Another Authority acquires the lease; new decisions recover Authority verification
Stop the preferred Authority with no Authority LB Proxy control and registration use surviving individual destinations Individual routing
Stop an Authority behind its LB Failed backend is withdrawn; the same LB address reaches a ready instance Authority LB
Stop a Proxy behind the public LB New connections recover through a ready Proxy; existing streams owned by the stopped Proxy end Proxy verification
Stop one mandatory Authority after keyring prepare Activation refuses once its acknowledgement is stale Rotation

Keep database and Authority protected-state backups as a paired recovery set. Use the component guides for bootstrap expiry and recovery, and change planning for rolling restarts.