> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Rollback

> Re-ship a previous deploy exactly, with no rebuild.

Every deploy freezes what it shipped: the exact image per service and the spec it ran with.
Rolling back re-ships that frozen state. Nothing is rebuilt and nothing is re-read from
your repository.

## Rolling back

Open the project's **History** tab. A superseded deploy carries a rollback action.
Confirming it creates a new deployment with trigger `rollback` that goes straight to the
deploy phase using the old images.

Because nothing builds, a rollback takes about as long as pods take to start.

## What rollback does exactly

| | Behaviour |
| - | - |
| Images | Pinned. The exact references the original deploy pushed go live again, even if the branch has moved on. |
| Spec | The frozen snapshot the original deploy recorded, not the current file. A redeploy re-reads `slipway.yaml` at the commit, so a later spec change would silently alter what ships. |
| Secrets and variables | Resolved fresh at rollback time. Rolling back code does not un-rotate a credential. |
| The next push | Supersedes the rollback like any other deploy, when auto-deploy is on. |

Because the next push supersedes it, use rollback to recover. To stay on a known commit,
turn auto-deploy off for that source.

## When rollback is refused

Old images do not live forever. The registry keeps each service's last few builds plus
everything a live deploy still references. If cleanup has reclaimed an image, the rollback
is refused and names the reason. Redeploy the commit instead, which rebuilds it.

Deployments made before image manifests existed also cannot roll back, and redeploy
instead.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.