Rollback and approvals | Overlane Docs

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.

Rollback

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:

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.

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, deploy run, deploy releases, guard approvals answer and guard approvals list.