Skip to content

Rolling back

Application only

If a release misbehaves but the schema has not changed. Replace the tag with the version you were on before the upgrade - git tag --sort=-v:refname | head lists them. The example is the release before the current one, which is the rollback almost everybody is actually doing:

bash
cd /path/to/manager
git checkout v1.7.1
cd deploy/docker

# Put MANAGER_VERSION back too, or the interface keeps reporting the version you rolled away from.
sed -i 's/^MANAGER_VERSION=.*/MANAGER_VERSION=1.7.1/' .env

docker compose up -d --build
docker compose exec app php artisan manager:doctor

After a migration

Do not run migrate:rollback on a production installation as a first response. A down migration that drops a column discards data that the previous release cannot recover either. Rolling back a schema is a data-loss operation dressed as a convenience.

The safe order is:

  1. Stop the workers and scheduler so nothing writes while you decide: docker compose stop worker scheduler
  2. Restore the database from the backup taken before the upgrade.
  3. Check out the previous tag and rebuild.
  4. Run manager:doctor and manager:audit:verify.
  5. Start the workers again.

Restoring a backup rewinds the audit log to the moment it was taken. That is expected, and it is why manager:audit:verify runs afterwards: the chain will be intact but shorter, and anyone reviewing the history needs to know when a rewind happened.

Connector compatibility

Rolling the platform back below a connector's protocol version will make those connectors fail verification. They will keep retrying and report the failure locally; nothing is lost, but the fleet shows as not reporting until the versions line up again.

If you have to stay rolled back, pin affected connectors to the matching release.

Emergency: stop accepting connector traffic

To stop the platform accepting reports without taking it down:

bash
docker compose stop redis

Replay protection fails closed, so every connector request is rejected with a 503 while Redis is unavailable, and the interface keeps working. This is a blunt instrument, and it is the fastest one available.

AGPL-3.0-or-later. An independent product for Craft CMS, not affiliated with or endorsed by Pixel & Tonic.