Roll back a deployment to the previous release

To roll back a deployment, press Roll back to this on the project's Deployments tab, or run ox rollback <project> --wait. ox puts an older kept release back in charge without building it again, and your visitors keep using the live release until the old one passes its health check. Use it when a deploy went live and something is wrong.

Roll back to the previous release

In the dashboard, open the project and pick the Deployments tab. The Releases card lists the releases ox kept. Press Roll back to this on the one you want, read the note, then press Roll back.

From a terminal, this goes back to the newest release that is not live:

ox rollback shop --wait

To pick another one, give its id with --release. Without --wait, it prints Started rollback on shop: run <id> and the command to read its log.

ox keeps 3 releases for production, 2 for staging and 1 for a preview. When the disk runs low, ox may delete older ones, but it always keeps the newest release that is not live, so there is something to go back to.

What happens to traffic during a rollback

The old release starts beside the live one. ox waits for it to pass the health check, for up to 120 seconds. Only then does traffic move to it, and the release it replaced stops 10 seconds later. Your visitors keep using the live release the whole time.

If the old release fails its health check, ox stops it and nothing changes for your visitors. The run's log says why.

One exception: if your app pins a fixed port in [app], two releases cannot run at once, so the app restarts in place and is down for a moment.

What happens to the database and migrations

A rollback does not undo migrations. The database stays as the newest release left it. The dashboard says so too: Switches back without rebuilding. Database migrations are not reverted.

Before each deploy that runs a migrate step, ox saves a copy of every PostgreSQL database that has tables. You find it on the Backups tab, marked before migrate, and ox keeps the last 3. If the old code cannot work with the new tables, restore that copy as its own step. The restore replaces the data, so anything written since that deploy is lost. See Restore from a backup.

What happens to environment variables

By default, the rolled-back release runs with the variables you have now. To bring back the ones it ran with, tick Also restore the variables this release ran with, or add --restore-variables:

ox rollback shop --restore-variables --wait

That saves the old variables as a new version, so ox vars history shop shows the change (see variable history).

The next push deploys again

A rollback does not turn off deploy on push. The old release stays live until a new commit reaches your branch, and then ox deploys that commit as usual. To hold the rollback while you fix things, run ox autodeploy shop off, and turn it back on when the fix is in.

If the rollback does not work

• no kept release to roll back to: the project has deployed only once, or the release you named is no longer kept. Deploy a known good commit instead, from the Commits drawer or with ox deploy shop --ref <commit> --wait.
• The health check fails: the old release does not start with today's variables or database. Try --restore-variables, or read Health check failed.
• The variables of the release were not recorded: the message says roll back without them. Leave out --restore-variables.
• Another run is going: wait for it to finish. See Another operation is running.