What must be in place before Caddy can get a TLS certificate when I self-host Tares on a server?

Before Caddy can get a TLS certificate for Tares, your hostname needs an A record that points at the host IP and already resolves. You also open the firewall for SSH, HTTP and HTTPS. Then you start the stack and watch the Caddy logs until the certificate is obtained. The full walkthrough is on Self-host on a server.

How it works

A self-hosted Tares instance is single-tenant. It runs one taresd daemon with one volume (DuckDB is single-writer), the MCP server, and Caddy as a reverse proxy. Caddy terminates TLS and serves one hostname, for example tares.example.com.

Caddy obtains the certificate for that hostname when the stack starts. Two things must be true by then:

• DNS resolves. You create an A record for the hostname that points at the host’s IP. Caddy needs this resolving before it can obtain a TLS certificate.
• The firewall is open. The host allows SSH (port 22), HTTP (port 80) and HTTPS (port 443).

Any Linux host with Docker works, and a 1 GB VM is enough because Tares pulls a prebuilt image and does not build one. The same hostname then serves the console, and the MCP endpoint at /mcp.

Set it up

1. Provision a host. Use any Linux host with Docker. If Docker is not installed, run:

curl -fsSL https://get.docker.com | sh

2. Point DNS. At your DNS provider, create an A record for your hostname (for example tares.example.com) that points at the host’s IP. Wait until it resolves before you start the stack, because Caddy needs it resolving to obtain the certificate.

3. Open the firewall. Allow SSH and HTTP/HTTPS:

ufw allow 22 && ufw allow 80 && ufw allow 443 && ufw --force enable

4. Add the compose file, the Caddyfile and your secrets. Create the docker-compose.yml and Caddyfile on the host from the Server (compose + TLS) section of the Deployment reference. Then set the token and the domain in .env:

cat > .env <<EOF
TARES_AUTH_TOKEN=$(openssl rand -hex 24)
TARES_DOMAIN=tares.example.com
EOF

TARES_AUTH_TOKEN is the bearer token for the console and agents. Keep it. TARES_DOMAIN must be the hostname you created the A record for.

5. Pull, start and watch Caddy. Follow the Caddy logs until the certificate is obtained:

docker compose pull
docker compose up -d
docker compose logs -f caddy     # wait for the certificate to be obtained

6. Verify. Once the certificate is in place, check the health endpoint:

curl -s https://tares.example.com/health
# {"status":"ok","auth_required":true,...}

Then open https://tares.example.com and log in with TARES_AUTH_TOKEN.

What you get

• A single hostname with a valid TLS certificate, served by Caddy in front of Tares.
• A console you reach at https://tares.example.com and sign in to with your TARES_AUTH_TOKEN.
• An MCP endpoint at /mcp on the same hostname. From a workstation you can connect a remote agent with claude mcp add --transport http tares https://tares.example.com/mcp and an Authorization Bearer header that holds your token.
• A health check at /health that reports auth_required as true when auth is on.
• Simple upkeep. Pin a version with TARES_VERSION in .env, then run docker compose pull && docker compose up -d to upgrade. Back up by snapshotting the host or copying tares.duckdb from the data volume.

The root token secures the console, API, MCP and ingest. Hand machines their own scoped API keys rather than the root token. Once the instance is running, AI SRE shows what you can build on it.

When something else fits

• If you only want to try Tares on your own machine, you do not need DNS, a firewall or Caddy. The local install with tares up is the quicker path.
• If you want per-user SSO, front the console with a proxy such as oauth2-proxy or Tailscale. The self-host page points to the Authentication section of the Deployment reference for this.

Related