# Rollbacks

Something bad shipped, or something good needs shipping again. Three moves cover it.

## Redeploy

**Redeploy** on an environment ships the branch tip again, through the normal [build pipeline](/platform/deployments/builds). Use it when the code is fine but the deploy context changed:

- After editing [environment variables](/platform/environment-variables) - though saving a changed set redeploys automatically.
- After changing build settings, size, or scaling.
- After a build failed for a transient reason.

## Roll back code

To undo a bad commit, revert it in Git and push:

```bash
git revert HEAD
git push
```

The pipeline treats the revert like any other change and has it live in one build. This keeps Git as the single source of truth - the deployed code always matches the branch, and the rollback itself shows up in [deploy history](/platform/deployments#deploy-history) with its own commit.

> [!NOTE]
> A failed build never replaces the running deploy - the previous deploy keeps serving until a build succeeds. Bad builds don't need rolling back, only bad code that built successfully does.

## Manual releases

Turn off [deploy on push](/create/git-automation#deploy-on-push) and nothing ships until you press **Redeploy**. Pushes still update the repository; the environment waits. This suits scheduled releases: merge all week, ship on Thursday.

## What history shows

Each environment keeps its last 20 deploys - commit SHA, message, author, duration, status, and build steps. That is the audit trail for "what was live when": find the deploy that introduced a problem, open its commit, revert it.

## Related

- [Deploy history](/platform/deployments#deploy-history): What is kept for every environment.
- [Builds](/platform/deployments/builds): Why a build fails and how to read it.
- [Git automation](/create/git-automation): The toggles behind automatic deploys.