---
title: "Rollback and approvals"
description: "Roll an environment back in one command, what a failed deploy leaves serving, how protected environments are approved, and how artifact digests stop a changed build."
---

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

# Rollback and approvals

## Rollback

```sh
overlane deploy rollback production --reason "checkout is failing" --force
overlane deploy rollback staging --reason "bad copy" --dry-run
```

One call puts the environment back on its previous release, or on a release you name with `--to`, and records who did it, when and why. The restored release is marked live again and the one it replaced is marked rolled back. A rollback restores something that was already approved and verified when it was deployed, so it is not held for a new approval; the guardrail rules still see it as the `rollback.run` action, so a team rule can restrict it. If the provider fails, nothing changes and the answer says which release is still serving. The command needs `--force` when there is no terminal.

## A failed deploy

A deploy has two steps at the provider: build a candidate that is not live, then promote it. A failure in either leaves the previous release serving. The failed release is recorded with the reason, and `deploy run` exits 1.

## Protected environments

A deploy to `production` or `prod`, or to any environment created with `--protected`, waits for an approval. The answer exits 6 and names the command that answers it:

```sh
overlane guard approvals list --status pending
overlane guard approvals answer apr_1 --decision approve --evidence "reviewed the run and the diff" --reason "matches the task"
overlane deploy run --env production --commit 0123456789abcdef0123456789abcdef01234567 --run run_abc123 --approval apr_1
```

The approval shows what will run: the commit, the artifact digest, the CI run and the environment. It covers exactly that deploy; another commit or artifact needs its own approval. An independent second agent can answer it, and a person always can. Team rules can add approvals to other environments or tools with the [rule files](/review/guardrail-rules/).

**Verified work does not grant a deploy.** A task can be verified, with passing CI evidence for the commit, and its deploy to a protected environment still waits for the approval. Authority to deploy comes from the guardrail decision alone.

## Artifact digests

CI records the digest of every artifact a step declares. At deploy the service reads the stored artifact again and hashes it:

- A digest that does not match the one recorded at build refuses the deploy (exit 6) and nothing is sent to the provider. Rebuild from the commit.
- `--expect-digest` refuses the deploy unless the recorded digest is the one you expect.
- A run that did not pass, or that built a different commit, has nothing to deploy.

## Records

`overlane deploy releases` lists each release with its status, whether it is live, the commit, the actor and the URL. Rollbacks are kept with their release, actor and reason.

Command reference: [deploy rollback](/cli/deploy-rollback/), [deploy run](/cli/deploy-run/), [deploy releases](/cli/deploy-releases/), [guard approvals answer](/cli/guard-approvals-answer/) and [guard approvals list](/cli/guard-approvals-list/).

Source: https://docs.overlane.app/git-ci-deploy/rollback-and-approvals/index.mdx