Upgrading

Upgrades are a version bump and a restart. Migrations run automatically before the application starts, and upgrading from any earlier published release is supported.

Back up first

Some migrations cannot be rolled back without restoring the database. Take a dump before you change the version:

docker compose exec db pg_dump -U app -Fc app > pre-upgrade.dump

See Backups for the automatic timer and the restore procedure.

Bump the version and restart

# in .env
CONATUS_VERSION=0.2.0-beta.3

docker compose pull
docker compose up -d

CONATUS_VERSION must match a published release image tag without the leading v. GitHub release v0.2.0-beta.3 is CONATUS_VERSION=0.2.0-beta.3. Releases are listed at github.com/nojusmorkunas/conatus/releases.

Pin a real version rather than leaving latest in place on anything you care about. The latest tag is not published during the public beta. After the first stable release, using it would also make the next unrelated docker compose up -d an upgrade.

What happens on start

Compose runs the migrate job from the -ops image and waits for it to finish successfully before starting app. If a migration fails, the app does not start on a half-migrated database. Read the logs, restore the dump, and report it:

docker compose logs migrate

The MCP sidecar is versioned separately

CONATUS_MCP_VERSION tracks conatus-mcp, which is released on its own schedule. Bumping CONATUS_VERSION does not move it, and it does not need to move in lockstep. See MCP server.

Changelog

Release notes live with the code: CHANGELOG.md.