Rolling back an update

Rolling back is not just repinning the old image. Because updates migrate the database forward, the older app version would crash-loop against the newer schema — its alembic upgrade head would hit revisions it does not know about. You must downgrade the database first, then repin.

Always have the pre-update database backup from before the upgrade as your ultimate fallback. See Restoring from a backup.

Rollback steps

1. Downgrade the schema using the current (newer) image, which still knows how to step back. Target the revision the older version expects (substitute the correct revision from the release notes):

   sudo docker compose -f /opt/summitpsa/docker-compose.yml exec -T app \
     alembic downgrade <target-revision>

   The downgrade scripts drop the columns and tables the newer version added, returning the schema to the exact shape the older version expects.
2. Repin to the previous image tag and bring it up. Its entrypoint will run alembic upgrade head, which is now a no-op because the schema already matches:

   sudo sed -i 's#ghcr.io/summitpsa/app:NEW#ghcr.io/summitpsa/app:OLD#' \
     /opt/summitpsa/docker-compose.yml
   sudo docker compose -f /opt/summitpsa/docker-compose.yml up -d app

3. Confirm the app is healthy and on the expected revision:

   sudo docker compose -f /opt/summitpsa/docker-compose.yml logs --tail=40 app
   sudo docker compose -f /opt/summitpsa/docker-compose.yml exec -T app alembic current

If the downgrade fails

If you cannot cleanly downgrade the schema, restore the database from the backup you took before the update and bring up the old image against that. Keeping the previous image locally (do not delete it on update) is what makes this fast.