ExoExo
§02 · Deploy & operate

Disaster recovery

Recovering from a major outage with warm standby.

High availability handles local failures. Disaster recovery restores service after a larger outage, such as losing a region.

Warm standby

In this reference design, a smaller Exo service stays running in a recovery region, with a continuously replicated, read-only database. Only one region accepts writes. Separate backups protect against corruption that replication could copy.

Exo control plane · Warm standby reference
Exo warm-standby disaster recoveryProduction traffic uses the primary region. A reduced-capacity Exo control plane is already running in the recovery region. PostgreSQL replicates asynchronously from the primary writer to a read-only standby. Independent backups, WAL, encryption keys and recordings support recovery. Failover fences the old writer, promotes the standby, scales existing capacity, validates service, and switches traffic. Dashed replica outlines represent capacity to add, not running instances.Exo service endpointPrimary regionMulti-AZ · activeRecovery regionWarm standbyProduction trafficFence → promote → verifyLoad balancerLoad balancerExo control planeProduction capacityExo control planeRunning · reduced capacityPostgreSQL primarySingle writerPostgreSQL standbyReplicating · read-onlyAsyncreplicationIndependent backups · WAL · encryption keys · recordings
Scroll to view the full diagram.
Exo control plane · Warm standby reference
Exo warm-standby disaster recoveryProduction traffic uses the primary region. A reduced-capacity Exo control plane is already running in the recovery region. PostgreSQL replicates asynchronously from the primary writer to a read-only standby. Independent backups, WAL, encryption keys and recordings support recovery. Failover fences the old writer, promotes the standby, scales existing capacity, validates service, and switches traffic. Dashed replica outlines represent capacity to add, not running instances.Exo service endpointPrimary regionMulti-AZ · activeRecovery regionWarm standbyProduction trafficFence → promote → verifyLoad balancerLoad balancerExo control planeProduction capacityExo control planeRunning · reduced capacityPostgreSQL primarySingle writerPostgreSQL standbyReplicating · read-onlyAsyncreplicationIndependent backups · WAL · encryption keys · recordings

Before adopting this design, test Exo startup and health checks against the read-only standby. See the warm-standby pattern.

Recovery steps

For managed Exo, control-plane recovery belongs to the Exo operations team, not your cluster team:

  1. Isolate: stop the original region from accepting writes.
  2. Check: confirm available data, encryption keys, and any expected data loss.
  3. Activate: make the standby database writable and increase service capacity.
  4. Verify: test sign-in, session access, and Operator connectivity.
  5. Switch: direct traffic to the recovery region and confirm reconnections.

What your team does

Check that your Operator reconnects and try an Agent session. If your own cluster was affected, restore its workloads and saved files separately. Control-plane recovery does not restore Agent volumes or guarantee that interrupted work resumes.

Recovery targets

Agree how much downtime (RTO) and data loss (RPO) your business can accept. Confirm the service commitments with Exo and test your own recovery plan.

Previous · Deploy & operateHigh availabilityNext · Building agents Model providers