Upgrades & forward-only migrations
Upgrade Eddytor safely - migrations are forward-only, so snapshot Postgres first.
Upgrading Eddytor is pulling a newer image. One rule matters:
Heads up
Snapshot Postgres before every upgrade. Migrations are
forward-only - there's no down-migration - so 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): re-checkEDDYTOR_DATABASE_URLhost/creds, and on an external DB make surewaitForDbis off - see Install the chart. - Boot fails with a secret-decrypt error: the
EDDYTOR_ENCRYPTION_KEYchanged or is wrong - see Backups & key rotation.