Rollbacks

Every successful deploy leaves its release directory on the server. Rolling back re-points the current symlink at an older one and reloads PHP-FPM. It takes seconds, because nothing is rebuilt.

Open the deployment you want to return to and press Roll back.

What a rollback does not do

Your database is never rolled back. Not the schema, not the data, not a single row.

This is the thing to understand before you need it. If the deploy you are undoing ran setup:upgrade and that migrated your schema, rolling the code back leaves new schema under old code. Depending on the migration, that ranges from harmless to a store that will not boot.

A rollback is the right tool for a bad template, a broken layout, a third-party module that misbehaves, a configuration change that shipped in code. It is the wrong tool for a schema migration that went wrong — for that, restore a backup into a new database and deploy onto it. See Backups and restores.

When a rollback is refused

"This release was built for PHP 8.2 — redeploy instead." You changed the environment's PHP version since that release. Its vendor/ directory was built against a different runtime and its compiled code will not load. Deploy the old commit instead, so it is rebuilt properly.

"Release 41 is no longer on the server — it was pruned. Redeploy instead." Only the newest three releases are kept; everything older is deleted at the end of each deploy to bound disk use. Four deploys after the one you want, it is gone. The remedy is the same: deploy that commit again.

Rollback is also unavailable while a deploy is running, and to the release that is already live.

After rolling back

The release you rolled back to is touched so the pruner treats it as recent and does not delete it out from under you.

Your next deploy proceeds normally from your branch — a rollback changes what is being served, not what your repository contains. If the bad code is still on your branch, the next deploy puts it back. Fix it in git, not just on the server.