Skip to main content

Upgrades & migrations

Operator

Ticketra is upgraded by deploying new container images. Database schema changes are applied automatically and safely at startup.

How migrations work​

  • Migrations are sequential, numbered SQL files bundled with the API image.
  • On startup the API takes a PostgreSQL advisory lock, then applies any migrations not yet recorded in the migrations table, inside transactions.
  • The advisory lock means that even if multiple API instances start at once, migrations run once, in order.
  • Already-applied migrations are skipped.

You don't run migrations manually — they happen when the new API container boots.

Upgrade procedure​

# 1. Back up first (always)
#    Admin → Backups → Create Backup   (see the backup guide)

# 2. Pull the new version
git pull            # or fetch the new image tags

# 3. Rebuild and restart
docker compose up -d --build

# 4. Watch the API apply migrations
docker compose logs -f api      # look for "Migration executed: NNN_*.sql"

# 5. Verify health
curl -k https://<host>/api/v1/health
Back up before every upgrade

Take a fresh backup before upgrading. Migrations are forward-only; a backup is your rollback path.

Air-gapped upgrades​

Build and export the new images on a connected machine, transfer them, docker load, then docker compose up -d. See Air-gapped install for the image-transfer workflow.

After upgrading​

  • Confirm health reports database: connected and opensearch: connected.
  • If search looks incomplete, the OpenSearch index rebuilds from PostgreSQL (the source of truth).
  • Review release notes for version-specific steps.

Rollback​

If an upgrade misbehaves, restore the pre-upgrade backup onto the previous image version. See Back up and restore.