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

# Deployment History and Rollback

> Every release is recorded, and any previous one that produced an image can be restored without a rebuild.

Every deploy is recorded against the application: what it built, how it ended,
and the image it produced. That last part is what makes rollback instant.

## Deployment history

The **Deployments** tab lists releases newest first. Each row carries its
status, when it ran, and (when the deploy came from GitHub) the commit it
built.

### Statuses

| Status        | Meaning                                                               |
| ------------- | --------------------------------------------------------------------- |
| **Queued**    | Accepted and waiting for the worker to pick it up.                    |
| **Building**  | Source is being packaged and built into a container image.            |
| **Deploying** | The image is built; the database, migrations and release are running. |
| **Live**      | Serving traffic.                                                      |
| **Failed**    | It did not finish. The previous version is still serving.             |

A failed deploy carries its reason, and where the failure happened during the
build, the build log with it. Where the container built but would not start,
the failure shows what the container printed on its way out.

## Rolling back

Any earlier deployment that produced an image can be restored. Antideploy
points the service back at that image; there is no rebuild, so it takes about
as long as a release rather than a full deploy.

<Steps>
  <Step title="Open Deployments">
    Go to the **Deployments** section of your app.
  </Step>

  <Step title="Choose the release">
    Find the deployment you want back. Rows that can be restored show a **Roll
    back** button; the currently live one does not.
  </Step>

  <Step title="Roll back">
    Click it. The service is re-pointed at that deployment's image and a new
    entry is recorded.
  </Step>
</Steps>

<Warning>
  Rollback restores your **application code only**. It does not reverse database
  migrations.

  If the release you are rolling back from changed your schema, check that the
  older code can still run against it. The safest pattern is additive
  migrations that both versions tolerate.
</Warning>

## Zero-downtime releases

The running version keeps serving until the new one has been built and has
passed its health check. If the new version fails to start, the old one is left
in place and the deploy is marked failed; you do not get a window where
neither is up.

<Note>
  Because each app runs on at most one instance, there is no percentage-based
  rollout, no canary, and no way to have two versions serving at once. The
  cutover is a switch, not a gradual shift.
</Note>

There is no deployment configuration file. Build and start commands come from
analysis of your code, and the release behaviour above is not configurable.

<Card title="Compute" icon="server" href="/docs/infrastructure/compute">
  The single-instance limit and what follows from it.
</Card>