Skip to Content
Tares

What is the difference between running tares up with and without —auth, and where do I find the root token?

Plain tares up runs Tares open with no login, while tares up --auth makes every route require a credential, ingest included. A bare --auth generates a root token, saves it in the data dir and prints a click-to-login URL on each launch. Machines get scoped API keys, never the root token.

How it works

Auth is one switch, set when you launch Tares.

  • tares up without --auth: Tares is open. The API, the console and ingest are all reachable without a credential. This is the local default, so it suits a laptop where only you can reach port 8787.
  • tares up --auth: Tares is secured. The console, the API and ingest all require a credential.
  • Bare --auth: Tares generates a root token, persists it to the data dir and prints a click-to-login URL each launch. The URL is your console address followed by ?token= and the root token, so one click signs you in.
  • --auth=token or TARES_AUTH_TOKEN: Tares uses a token you choose instead of generating one. This is the shape for hosted or scripted deploys. TARES_AUTH_TOKEN is what tares up --auth sets, and tares-mcp reads the same variable and sends it to the daemon.

There is no separate ingest token and no read-only mode. The root token is the operator’s login. On a secured instance you mint narrower credentials from it and give those to machines. The deployment reference covers authentication alongside the other launch options.

Set it up

  1. For a local, open instance, start Tares with no flags. The console is at http://127.0.0.1:8787 and your data is in ~/.tares.
tares up
  1. To secure it, add --auth to tares up. Tares generates a root token, saves it to the data dir and prints the click-to-login URL. Open that URL to sign in to the console.
  2. To use your own token, pass --auth= followed by the token, or set TARES_AUTH_TOKEN before you launch. In a compose deployment, set TARES_AUTH_TOKEN on both the daemon and the MCP server. The compose file in the deployment reference requires it and refuses to start without it.
  3. To find the root token later, look at the line printed at launch, because the click-to-login URL appears on every launch. The token itself lives in the data dir, which is ~/.tares for tares up unless you set --data-dir.
  4. Open Settings → API keys in the console and create a key for each machine. Pick a subset of the scopes:
    • read for reads, timelines, the catalog and projects.
    • ingest for POST /ingest/*, /v1/* and writing memories.
    • admin for every change, and it implies the others.
    • findings for recording a finding in a project, only on a project key.
  5. Hand each key to its holder. An MCP agent gets read. A producer such as a Vercel drain, an OTLP exporter or a webhook sender gets ingest. The Claude Code plugin gets read and ingest. The sender passes its key as Authorization: Bearer followed by the key. Keys are shown once, can be revoked and are never returned again.
  6. When you create a push source on a secured instance, Tares mints an ingest key for it and shows it once. Give it to the producer. It then appears in Settings → API keys, where you can mint new keys or deactivate existing ones.

What you get

  • A zero-friction local start. Plain tares up needs no token and no login.
  • One switch that secures everything. With --auth, the console, the API and ingest all require a credential, so no route is left open by accident.
  • A root token you can always recover. It is persisted to the data dir and printed as a click-to-login URL each launch.
  • Least-privilege credentials for machines. Each producer or agent holds a scoped API key, so the root token never leaves the operator.
  • Revocable access. You can revoke any key without touching the root token or the other keys.
  • Project keys for agents that work inside one project. They read that project and record findings in it, and nothing else.

To understand how Tares fits into incident work once it is running, start from the AI SRE guide.

When something else fits

  • If you need per-user SSO, put a proxy such as oauth2-proxy, Tailscale or Caddy basic-auth in front of the console. The root token stays the console login, and machines keep their scoped API keys.
  • If you need a read-only mode or a dedicated ingest token, Tares has neither. Use a key with only the read scope, or only the ingest scope, instead.
  • If you only run Tares on your own machine and nothing else can reach it, plain tares up is enough.

Still stuck? Get help

Last updated on