Skip to content

Rollback

Purpose

The manual procedure for reversing a bad production deploy - there is no automated rollback in this repository, by design (docs/DEPLOYMENT.md §5).

Architecture/context

Every deploy is a wrangler deploy of the current main tree's build output - Cloudflare keeps prior Worker versions internally, but nothing in this repository's tooling drives an automated "revert to previous version" action. Rolling back means redeploying a known-good commit.

Option 1: redeploy the last known-good commit (fast, doesn't rewrite main)

git log --oneline -10                                    # [READ-ONLY] find the last good SHA
git checkout <good-sha>                                  # [SAFE LOCAL] detached HEAD
npm install
npm run build
npx wrangler deploy --config apps/<affected-app>/wrangler.jsonc          # [PRODUCTION]
# or, for the API Worker:
npx wrangler deploy --config workers/api/wrangler.jsonc                  # [PRODUCTION]
git checkout main                                         # [SAFE LOCAL] return to normal branch state
Use this to stop the bleeding immediately. main still has the bad commit at its tip - the next push (including an unrelated one) will redeploy the bad version again unless Option 2 is also done.

Option 2: git revert on main (permanent, triggers a normal deploy)

git checkout main
git pull
git revert <bad-sha>                                       # [SAFE LOCAL] creates a new commit
git push origin main                                       # [PRODUCTION] triggers deploy-production
This is the actual fix - it both restores good code and updates main so future deploys stay correct. Prefer this over Option 1 alone whenever there's time to let CI run.

Database rollback

No automated migration rollback exists - see D1 Operations. If the bad deploy included a destructive migration, a code revert alone does not undo the schema change; a corrective migration must be written.

Validation

After either option: 

npm run smoke:production                                   # [READ-ONLY]
See Verification.

Expected result

The affected app/Worker serves the previous, known-good behavior; smoke test passes.

Troubleshooting

Symptom Check
Redeployed old commit but site still shows new behavior Edge cache - hard refresh, wait briefly, confirm via curl -I for cache headers
deploy-production re-runs and reintroduces the bug main still has the bad commit - use Option 2, not just Option 1

Security considerations

Rollback commands use the same production CLOUDFLARE_API_TOKEN as any deploy - see Infrastructure → Security.