Ship again or ship backwards - Redeploy for settings changes, git revert for bad code, and manual releases when deploy-on-push is off.
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. Use it when the code is fine but the deploy context changed:
- After editing 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:
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 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 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.