Upgrades & forward-only migrations
Upgrade Eddytor safely - migrations are forward-only, so snapshot Postgres first.
Upgrading Eddytor is pulling a newer image. The one rule that matters: database migrations are forward-only - there's no down-migration - so snapshot Postgres before you upgrade.
Heads up
Snapshot Postgres before every upgrade. Migrations
don't roll back. A snapshot is your only way back to the previous version's
schema.
How migrations run
The server runs migrations at boot, under a Postgres advisory lock - so
it's safe even with multiple server replicas; only one runs the migration, the
rest wait. The engine skips migrations (EDDYTOR_SKIP_MIGRATIONS=true). The
server is the single authoritative migrator.
- Snapshot Postgres.
- Bump
EDDYTOR_VERSIONin.env. - Pull and recreate:
docker compose pull && docker compose up -d- Wait for health and confirm migrations ran:
docker compose ps # eddytor-server (healthy)
docker compose logs eddytor-server | grep -iE "preflight|migrat|listening"- Snapshot Postgres.
- Bump the image tag and upgrade in place:
helm upgrade eddytor oci://ghcr.io/nordalf/charts/eddytor -n eddytor \
--reuse-values --set image.tag=<new-version>- Watch the rollout and confirm migrations:
kubectl -n eddytor rollout status deploy/eddytor-server --timeout=300s
kubectl -n eddytor logs deploy/eddytor-server | grep -iE "preflight|migrat|listening"
helm test eddytor -n eddytor # hits /healthz on server + engineThe Web UI tracks its own version - bump ui.image.tag independently.
If the server won't come up
- Stuck in
Init(Kubernetes): the DB handshake is failing - re-checkEDDYTOR_DATABASE_URLhost/creds. If you're on an external DB, make surewaitForDbis off (see external datastores). - "secret decrypt failed" at boot: the
EDDYTOR_ENCRYPTION_KEYchanged or is wrong. Restore the correct key - see Backups & key rotation.