---
title: "High availability"
version: "v0.27.0"
canonical: "https://docs.obot.ai/v0.27.0/operations/high-availability"
unreleased: false
---

# High availability

High availability requires the Obot application, database, and storage to remain available together. Configure and test each layer before adding replicas.

<a id="obot-doc-application-replicas-and-storage"></a>

## Application replicas and storage

The [Kubernetes deployment guide](https://docs.obot.ai/v0.27.0/installation/kubernetes-deployment.md#obot-doc-high-availability) describes `replicaCount` and external PostgreSQL. If replicas need the same local files, use a ReadWriteMany Obot data volume. A shared ReadWriteOnce claim is not a multi-replica storage solution.

<a id="obot-doc-failure-behavior"></a>

## Failure behavior

[Tunnel peers](https://docs.obot.ai/v0.27.0/functionality/mcp-tunnels.md#obot-doc-multiple-obot-replicas) route requests to connected tunnel clients across replicas. Failed in-flight requests are not replayed automatically. Peer-token rotation can temporarily interrupt tunneled traffic during a rolling update.

Validate application restart, workload rescheduling, database availability, and storage recovery in a staging environment. Keep [backup and recovery](https://docs.obot.ai/v0.27.0/operations/backup.md) procedures separate from availability configuration.

<a id="obot-doc-plan-each-layer"></a>

## Plan each layer

| Layer          | Required planning                                                                                                                        |
| -------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
| Obot replicas  | Configure the Helm replica count, capacity, and ingress routing. Review pod placement so one node failure does not remove every replica. |
| PostgreSQL     | Use an external production database with its own availability and recovery plan. Additional Obot replicas do not replicate the database. |
| MCP workloads  | Assess their own restart behavior and persistent storage. More Obot replicas do not make each workload highly available.                 |
| Tunnel clients | Operate clients where they can reach the private service; test client and Obot replica loss.                                             |

<a id="obot-doc-verify-failover"></a>

## Verify failover

In a staging environment, establish a client connection and perform a read-only tool call. Replace an Obot pod, reconnect, and verify a new call and its audit record. Separately test database failover and access to any shared files from each replica. Inspect failed in-flight requests; do not assume the gateway retries them.

For workload sizing, see [Capacity](https://docs.obot.ai/v0.27.0/operations/capacity.md). For recovery after data loss, see [Backup and recovery](https://docs.obot.ai/v0.27.0/operations/backup.md).