Skip to main content

Upgrading Tagaris

Upgrading Tagaris means pulling a newer image and recreating the container. The app applies any pending database migrations itself on start, so there is no separate migration step. This page covers all three install methods; where they differ, it says so.

Version tags​

Each release is published under several tags on Docker Hub:

  • latest: the newest release, whichever major version that is. The install guides use it in their examples for simplicity.
  • A major tag such as 2: the newest release within version 2.
  • A minor tag such as 2.2: the newest patch of version 2.2.
  • An exact tag such as 2.2.0: that one release and no other.

For anything beyond a quick trial, pin to a major version rather than latest. Set the image to goodhallsolutions/tagaris:2 (or goodhallsolutions/tagaris-bundled:2), and pulling gives you every version-2 update, fixes and features, when you choose, without an unplanned jump to version 3, which may include changes that need steps on your part. latest is convenient for evaluation but will cross a major version on its own.

Set the tag once, in your compose file or docker run command. You decide when to pull.

Upgrade steps​

Back up first. A backup before an upgrade costs little and makes a rollback trivial; see Backups and restore.

With Docker Compose:

docker compose pull
docker compose up -d

If you pinned an exact version, change the tag in the compose file first, then run the same two commands. The app waits for the database, applies migrations, and starts on the same port. Your data lives in the volumes (or your own database) and carries straight across.

With plain docker run, pull the tag and recreate the container, keeping the same volumes and environment as at install:

docker pull goodhallsolutions/tagaris:2
docker rm -f tagaris
# then run the same docker run command you used to install

Rolling back​

If an upgrade misbehaves, set the image back to the previous tag and run docker compose up -d again. Migrations are additive, so a rollback normally just works. If a release notes a breaking change, restore the backup you took before upgrading.

PostgreSQL major upgrades​

An app upgrade never changes your PostgreSQL major version. Moving PostgreSQL itself to the next major (16 to 17, for example) is a separate task, because PostgreSQL cannot read a data directory written by a different major version in place. How you handle it depends on the install:

  • Standard install (separate database container): PostgreSQL does not upgrade its data directory across majors on its own, so changing the postgres:16 image to a newer major will not load the old data as-is. Take a backup, start the new database on an empty volume, and restore. There is no rush: Tagaris does not require the newest PostgreSQL, so you can stay on 16 until you choose to move.
  • Self-contained install (bundled database): the database is pinned to PostgreSQL 16, and the container refuses to start against data from a different major to protect it. When a future image moves to a newer major, take a full backup in Application settings, start the new image with an empty data volume, then restore.
  • Dedicated database: your server, your schedule. Upgrade PostgreSQL the way you normally do, with Tagaris stopped or during a quiet period.

In every case the safe path is a backup and restore rather than an in-place conversion, and each major-version release will spell out any steps in its notes.