Why does the Tares Docker setup use two containers on a shared network, and how do I tear it down?

Tares ships one image that runs as two containers on a shared Docker network, one for the daemon and one for the MCP server, so the MCP server can reach the daemon by name. The console is on port 8787 and the MCP endpoint is on port 8788 at /mcp. To tear down, remove both containers and the network, and remove the data volume only if you want the data deleted.

How it works

One image, ghcr.io/glassflow/tares, serves both processes. It runs the daemon (taresd) by default. It runs the MCP server when you start it with the tares mcp command. You start the image twice with different commands, which gives you two containers:

• taresd runs the daemon. It publishes port 8787 and mounts the tares-data volume at /data.
• tares-mcp runs tares mcp with the streamable-http transport, binds to 0.0.0.0 on port 8788, and publishes that port.

Both containers join a Docker network named tares. On that network the MCP container reaches the daemon at http://taresd:8787, using the daemon’s container name. That is why the MCP container is started with --taresd http://taresd:8787. Without the shared network, the MCP server would have no route to the daemon.

The split keeps data in one place. Tares is a single process writing to a single DuckDB file, and DuckDB is single-writer, so a deployment is exactly one taresd and one data volume. Only the daemon container mounts the volume. The MCP container holds no data and proxies to the daemon.

The two ports serve different clients:

• Port 8787 serves the console at http://localhost:8787.
• Port 8788 serves the MCP endpoint at http://localhost:8788/mcp, for external agents.

The AI SRE guide shows how agents use Tares once it is running.

Set it up

1. Create the shared network.
2. Start the daemon container on that network. It publishes 8787 and mounts the tares-data volume.
3. Start the MCP container from the same image with the tares mcp command, on the same network.

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

4. Open the console at http://localhost:8787. Point your agents at the MCP endpoint at http://localhost:8788/mcp.
5. If you only want the console, run the first two commands and skip the MCP container.
6. To tear it down, remove both containers, then the network. Run the last command only if you also want to delete the data.

docker rm -f taresd tares-mcp
docker network rm tares
docker volume rm tares-data   # only if you also want to delete the data

The volume holds the DuckDB file. If you leave it in place, a later docker run with -v tares-data:/data starts the daemon on the same data. Remove the volume only when you want a clean slate.

What you get

• A running console on port 8787 and an MCP endpoint on port 8788 at /mcp, from one image.
• An MCP server that reaches the daemon by container name, with no host networking tricks.
• One data volume owned by one daemon, which matches the single-writer DuckDB design.
• A console-only option: the first two commands are enough if you do not need external agents.
• A teardown in three lines. Removing the containers and the network leaves your data in the volume until you choose to delete it.
• A pinned version if you want one. Images are published as :latest and as a tag per release.

When something else fits

• On your own machine, you can skip Docker: install the CLI, run tares up for the console, and run tares mcp as a second process if agents need the MCP endpoint.
• On a server that needs TLS, use the compose file with the Caddy reverse proxy. It wires up the daemon, the MCP server and the proxy for you. Both setups are in Deployment.
• Do not run more than one taresd against the same data volume. Run one daemon per volume.

Related