When warmhawk update doesn’t go clean.

warmhawk update is meant to be boring: pull, migrate, restart, done. When it isn’t, the fix is almost always to slow down rather than restart repeatedly.

This page covers what warmhawk update actually does (pull the latest tag, run pending migrations, rolling restart), what to check if a migration fails partway through instead of panic-restarting, how to roll back to the previous image tag if an update introduces a regression, and where to read the CHANGELOG before updating anything in production.

What warmhawk update does

It’s a thin wrapper script around four steps, run in order:

1. Pulls the latest image for your configured tag/channel
2. Runs any pending database migrations
3. Performs a rolling docker compose up -d restart
4. Reuses your existing secrets and license from .env — no re-entry, no re-activation

warmhawk update

No manual steps are expected on your end beyond running the command — if you see prompts you don’t recognize, or the update hangs somewhere unexpected, that’s worth investigating rather than dismissing.

A migration fails partway through

Don’t panic-restart the stack repeatedly — that’s the fastest way to turn a recoverable failed migration into a genuinely inconsistent schema. Instead, check exactly what the migration step logged:

docker compose logs migrate

Most migration failures are one of two shapes: a transient connection issue (Postgres wasn’t fully up yet when the migration ran — re-running the update usually clears this), or an actual schema conflict (rare, and usually means a manual change was made to the database outside of WarmHawk’s own migrations at some point). If the logs show a real schema error rather than a connection timeout, stop and take a backup before doing anything else:

docker compose exec api /app/scripts/backup-postgres.sh

Then email support@warmhawk.com with the exact migration log output — a genuine schema conflict is rare enough that it’s worth a second set of eyes before you act on it yourself.

Rolling back a bad update

If the update completed but introduced a regression — something that worked yesterday is broken today — roll back to the previous image tag explicitly rather than trying to patch forward under pressure:

# Edit .env: set the image tag back to the previous known-good version, e.g.
# WARMHAWK_IMAGE_TAG=v2.4.1

docker compose pull
docker compose up -d

This rolls back the application code without touching your database. If the update also ran a migration that the old code isn’t compatible with, you may need a full data restore instead — see backups & Redis durability for that procedure. This is exactly why taking a manual backup right before updating a production instance is worth the extra minute.

Check the CHANGELOG before you update production

Before running warmhawk update against a production instance, read what actually changed between your current version and the new one. Each package maintains its own CHANGELOG.md, linked from the changelog, covering breaking changes, new required environment variables, and migration notes worth knowing about ahead of time rather than discovering mid-update.