Knowledge > Runbooks > Deployment > Rollback
Rollback a Bad Deployment
Revert a production deployment that is causing errors, crashes, or wrong behavior.
Prerequisites
vercelCLI logged in (vercel whoami→churchwiseai-5386)- GitHub write access (for code reverts)
- WSL access (for voice agent rollback only)
Web App Rollback (churchwiseai-web / pewsearch / ITW)
Option A — Vercel Instant Rollback (Fastest)
Vercel keeps all previous deployments. Promoting a previous deploy to production takes ~10 seconds.
-
Find the last known-good deployment ID
vercel ls --project <project-name>Where
<project-name>is one of:churchwiseai-web,pewsearch-web,sermon-illustrations. Look for the deployment before your broken one. Copy its deployment URL or ID. -
Promote the previous deployment to production In the Vercel Dashboard:
- Go to the project → Deployments tab
- Find the last known-good deployment
- Click "..." → "Promote to Production"
- Confirm
Or, if the Vercel CLI supports it in your version:
vercel promote <deployment-url> --scope churchwiseai-5386 -
Verify production is restored
- Visit the production URL and confirm the site is working
- Check
vercel logs --tail --project <project-name>for any remaining errors
Option B — Git Revert (Preferred for Code Tracking)
-
Identify the bad commit
cd /c/dev/<codebase>git log --oneline -10 -
Revert the bad commit
git revert <bad-commit-sha>This creates a new commit that undoes the change — safe and preserves history.
-
Push to the deploy branch
git pushVercel picks up the push and deploys the reverted code.
-
Verify production is restored
vercel logs --tail --project <project-name>
Voice Agent Rollback
The LiveKit voice agent does not have a dashboard rollback. You must revert the code and redeploy via the LiveKit CLI.
-
Revert the code change
cd /c/dev/churchwiseai-webgit log --oneline -5git revert HEADgit push origin main -
Redeploy the voice agent from the
voice-agent-livekit/directory:C:\dev\lk.exe agent deploy --project cwa-voice --silent -
Test by calling a configured church number and verifying normal behavior.
Database Migration Rollback
Database migrations are the most dangerous rollback scenario. There is no automatic undo.
- Assess the impact first. Determine exactly which rows or schema changes were made.
- Get explicit founder approval before running any rollback query.
- Write the inverse migration manually:
- If you added a column:
ALTER TABLE x DROP COLUMN y; - If you updated rows: restore from the values you captured before the change
- If you inserted rows:
DELETE FROM x WHERE id IN (...);— only with founder approval
- If you added a column:
- NEVER delete rows from
unified_rag_content— this table has 327K irreplaceable records. - NEVER run a rollback that affects
churchesin bulk without founder approval.
Decision: When to Rollback vs. Forward-Fix
| Situation | Action |
|---|---|
| Site is down / 500 errors on all pages | Rollback immediately (Option A) |
| One page is broken | Forward-fix — push a patch |
| Build failed on deploy branch | Fix and push; Vercel won't deploy a failed build |
| Voice agent crashing on all calls | Rollback via WSL immediately |
| DB migration caused data issues | Stop, assess, get founder approval |