# Roll back a deployment to the previous release

Roll back a deployment to a kept release without a rebuild. The live release serves until the old one passes its health check. What happens to your data.

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. Your visitors keep using the live release until the old one passes its health check. Use a rollback when a deploy went live and something is wrong.

A rollback starts the kept release again beside the live one, without building it. Caddy keeps sending visitors to the live release until the kept one passes its health check, for up to 120 seconds. Then traffic moves to it, and the release it replaced stops 10 seconds later.

## 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, newest first. Each shows its commit, the commit's message, and when it was built. 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:

Roll back:

```sh
ox rollback shop --wait
```

To pick another release, give its id with `--release`. Without `--wait`, the command 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. It always keeps the newest release that is not live, so there is something to go back to.

## 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.`

Both releases use the same database, and a rollback does not undo migrations. Before each deploy that runs a migrate step, ox saves a **before migration** copy of each PostgreSQL database that has tables, and keeps the last 3.

If the old code cannot work with the new tables, restore the database as a separate step. Before each deploy that runs a migrate step, ox saves a copy of every PostgreSQL database that has tables. It is on the **Backups** tab, marked **before migration**, and ox keeps the last 3. The restore replaces the data, so anything written since that deploy is lost. See [Restore from a backup](https://console.t12.sorv.dev/docs/operate/backups#restore).

## What happens to environment variables

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

Roll back code and variables:

```sh
ox rollback shop --restore-variables --wait
```

This saves the old variables as a new version, so `ox vars history shop` shows the change (see [variable history](https://console.t12.sorv.dev/docs/operate/variables#history)).

## What happens to traffic during a rollback

The old release starts beside the live one. ox waits up to 120 seconds for it to pass the health check. 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.

There is one exception. If your app pins a fixed port in [[app]](https://console.t12.sorv.dev/docs/config#app), two releases cannot run at once. The app then restarts in place and is down for a moment.

## The next push deploys again

A rollback leaves deploy on push on. 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`. 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`.
- `capacity: only ... MB of the server's ... MB is free to reserve, ... MB less than the ... MB shop needs.`: the release you picked sets a larger `[limits] memory` than the live one, and the server has no room for it beside your other projects. Nothing changed. The fixes name the largest limit that fits (`roll back to a release whose memory under [limits] is at most ... MB`) and each project whose stop frees enough room. You can also delete a project you do not need.
- The health check fails: the old release does not start with today's variables or database. Try `--restore-variables`, or read [Health check failed](https://console.t12.sorv.dev/docs/troubleshooting#health-check-failed).
- The message says `roll back without them`: ox did not record the variables of that release. Leave out `--restore-variables`.
- Another run is going: wait for it to finish. See [Another operation is running](https://console.t12.sorv.dev/docs/troubleshooting#busy).

Last updated 2026-10-08. The page as HTML: https://console.t12.sorv.dev/docs/operate/rollback