Why does tares up exit at startup after I upgrade from an install that predates the rename, and what do I have to move?

Tares stops tares up at startup because it finds leftovers from a pre-1.0 install: an old-prefix environment variable or an old database file. The old environment variable names are not read at all, and the daemon prints the exact renames to TARES_*. The old database file name is not picked up either, so the daemon stops instead of starting empty. To fix it, move the old file to tares.duckdb with the daemon stopped. If you use the default data directory, move the whole directory to ~/.tares first.

How it works

Version 1.0 renamed the project and every name that came with it. Tares keeps no compatibility layer, so nothing falls back to an old name. At startup the daemon checks for two kinds of leftovers and exits on either one.

• Environment variables. Every variable with the old prefix is now a TARES_* variable with the same meaning. If any old-prefix variable is still set, tares up and taresd exit. They print each old variable still set in your environment next to the TARES_* name you need, for example the database path variable becomes TARES_DB. Tares does not read the old name, so it never applies your old value on its own.
• The database file. The database file is now tares.duckdb. DuckDB creates a missing file without complaint. If the daemon only looked for the new name, an upgrade that left the old file in place would come up healthy and completely empty, with your data sitting untouched beside it. Instead the daemon stops and prints a message that it found a pre-1.0 database and none at ~/.tares/tares.duckdb.
• The data directory. The default data directory also moved to ~/.tares. If you never set --data-dir or TARES_HOME, your data is still in the old hidden directory in your home, and you move the whole directory before renaming the file inside it.

Three old variables have no TARES_* equivalent. Two were folded into --auth plus scoped API keys in 0.2.0, and one became the standard ANTHROPIC_API_KEY. Unset those three rather than renaming them.

Set it up

1. Stop the daemon. The file move is safe only while taresd is not running.
2. Read the list that tares up printed. For each old-prefix variable, set the TARES_* name shown next to it and unset the old one in your shell profile, service unit or compose file. Variables listed as gone get unset, not renamed. On a server, the Deployment page lists every TARES_* variable and its default.
3. If you never set --data-dir or TARES_HOME, move the whole old data directory to ~/.tares first. Use the directory path your install has been using.
4. Move the old database file inside the data directory to tares.duckdb. The daemon’s message shows the old path it found. In a container the same file lives under /data.
5. Start Tares again.

mv <old-data-dir> ~/.tares                     # only for a default install
mv ~/.tares/<old-database-file> ~/.tares/tares.duckdb   # or /data/… in a container
tares up

The other renames are plain renames with no runtime guard, so check your scripts and manifests for them: the package and command are tares, the daemon is taresd, the MCP proxy is tares-mcp, the flag that points the proxy at the daemon is --taresd, the image is ghcr.io/glassflow/tares, and the Claude Code plugin is tares@tares.

What you get

• Your existing data comes back under the new file name, with nothing re-imported.
• You never end up on a healthy-looking but empty instance, because the daemon refuses to start until the file is in place.
• The daemon prints the exact renames, so you do not have to search your environment for old names.
• Once the variables, the directory and the file are renamed, the instance starts as it did before the upgrade. For the wider setup around it, including sources and triggers, see AI SRE.

When something else fits

• If you want a fresh instance and do not need the old data, remove the leftovers and start clean instead of moving the file.
• If the daemon still exits after the move, read the message again. It names whichever old variable or missing file it still sees, and the Deployment page has the full variable table.

Related