Upgrades

Tindra upgrades are a two-step process: pull the new image, restart the container. Migrations run automatically on startup.

Docker Compose#

docker compose pull
docker compose up -d

That is it. Downtime is typically under a second, long enough for the process to restart and run migrations.

Checking the current version#

docker exec <container-name> tindra --version

Or check the footer of the Tindra dashboard.

Zero-downtime upgrades#

For environments where any downtime is unacceptable, deploy behind a load balancer with two containers. Upgrade one at a time:

1. Pull the new image: docker pull ghcr.io/blendbyte/tindra:latest
2. Stop container A, start a new container A with the new image
3. Wait for it to be healthy
4. Stop container B, start a new container B with the new image

Migrations on the first container may lock tables briefly. This affects the second container if it starts before migrations complete.

Rollback#

Tindra does not support automatic rollback. If a new version has a problem:

1. Stop the new container
2. Start the old container using a pinned image tag (e.g., ghcr.io/blendbyte/tindra:1.2.3)
3. If the migration was destructive and you need to roll it back, restore from a backup

Pin image tags in production to avoid unintentional upgrades:

image: ghcr.io/blendbyte/tindra:1.3.0

Switch to latest only when you are ready to upgrade.

Release notes#

Check the GitHub releases page for changelogs before upgrading, especially for major version bumps.