# 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