Can I run two Tares daemon replicas against the same data volume for high availability?

Tares runs as exactly one taresd on one data volume, so you do not run two daemon replicas against the same data. A deployment is a single process writing a single DuckDB file, and DuckDB is single-writer. Keep that one daemon running with a restart policy and back up the volume.

How it works

Tares is a single process writing to a single DuckDB file. There is no external database or broker to run alongside it. Because DuckDB is single-writer, the shape of every deployment is the same:

• One taresd process.
• One data volume that holds the DuckDB file, tares.duckdb.
• Do not run multiple replicas against the same data.

The MCP server is a separate process, tares-mcp. It does not write the data. It proxies to the daemon through the --taresd flag or the TARESD_URL variable. You can run it next to the daemon without breaking the single-writer rule, and the same image serves both processes with a different command.

If you set TARES_STATE_DSN, the cell’s state (projects, tickets, agents, settings) lives in Postgres while events stay in the DuckDB file. You still run one taresd. The deployment reference lists every variable the daemon reads.

Set it up

Run one daemon with one named volume, and add the MCP server as a second container if external agents need it.

1. Create a network and start a single taresd with its data volume:

docker network create tares
docker run -d --name taresd --network tares -p 8787:8787 -v tares-data:/data \
  ghcr.io/glassflow/tares:latest
docker run -d --name tares-mcp --network tares -p 8788:8788 \
  ghcr.io/glassflow/tares:latest \
  tares mcp --transport streamable-http --host 0.0.0.0 --port 8788 --taresd http://taresd:8787

2. Keep the count at one. The tares-data volume is mounted by the one taresd container only. Do not start a second taresd on the same volume, and do not scale the daemon service to more than one instance.
3. On a server, use the compose file with TLS from the deployment reference. It defines one taresd service with one tares-data volume and sets restart: unless-stopped, so the daemon comes back after a crash or a host reboot.
4. Pin TARES_VERSION to a release tag for reproducible deploys instead of following :latest.
5. Back up the volume. Snapshot the volume or the host, or copy /data/tares.duckdb. To restore, put the file back before you start the daemon. If TARES_STATE_DSN is set, back up the Postgres state too, with pg_dump or your provider’s backups, and restore both together.

If you are building an incident-response setup on Tares, the AI SRE guide shows what runs on top of this single daemon.

What you get

• A deployment with one writer, so the DuckDB file is never written by two daemons at once.
• A simple operating model: one process, one volume, no external database or broker to keep in step.
• Automatic restarts of the daemon through the compose restart policy.
• A recovery path you control: snapshot the volume or copy tares.duckdb, then restore the file before start.
• The same layout locally, in Docker and on a server, so what you test is what you run.

When something else fits

• If you need more capacity, size the one host and volume that run taresd rather than adding daemon replicas on the same data.
• If you need protection from losing the volume, take regular backups of the DuckDB file, and of Postgres when you use TARES_STATE_DSN, and keep the restore steps ready.

Related