clawd/skills/app-builder/references/rollback.md

Rollback & Recovery

Levels of Rollback

1. Code Rollback (Most Common)

• Dokploy keeps previous builds
• Redeploy previous compose version from Dokploy UI
• Or: git revert the breaking commit, push, redeploy

2. Database Rollback

• Drizzle doesn't auto-generate down migrations
• For schema changes, write explicit rollback SQL before deploying
• Keep a migrations/rollback/ directory with undo scripts
• For data issues: restore from Dokploy Postgres backup

3. Full Rollback

• Dokploy allows complete service redeployment from any previous state
• Database: restore from backup
• Last resort: rebuild from Gitea source at known-good commit

Pre-Deploy Checklist

Before any production deployment:

• Feature works in test environment
• User has approved in test
• DB migration tested (if schema changed)
• Rollback SQL written (if schema changed)
• Health check passes after deploy

Staging Environment

• Staging should mirror production schema
• Periodically sync staging DB schema with prod
• Never sync prod DATA to staging (privacy)
• Test migrations on staging before prod

If Something Breaks in Prod

1. Assess severity — is the app down or is it a bug?
2. If app is down — redeploy previous Dokploy build immediately
3. If it's a bug — fix in dev, test, deploy fix
4. If DB is corrupted — restore from backup, investigate cause
5. Notify user with what happened and what was done