Rollback Plan

Rollback PlanPlan: Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}0.5.0 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}John (AI Director) Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}Alem Bašić (CEO)

Document History

Rollback Summary

1. Rollback Decision Criteria

Roll back immediately if ANY of these conditions occur:

Do NOT roll back for:

• Warning-level alerts that were present pre-deployment
• Increased error rate in non-critical paths < {{MINOR_ERROR_THRESHOLD}}%0.5%
• Expected behavior changes (verify against release notes first)
• Cosmetic/visual issues that don't affect functionality
• Mock BaaS timeout errors (expected in MVP; not production-blocking)

2. Rollback Authority

Authorization contact: {{ROLLBACK_AUTHORITY}}John |(AI {{PHONE}}Director) |— Slack: {{SLACK}}#drop-deploy on alai-talk.slack.com Emergency escalation: Alem Bašić — +47 40 47 42 51

3. Pre-Rollback Assessment

Data Changes Since Deployment

• Deployment time: {{DEPLOYMENT_TIME}}Recorded at time of deployment (see deployment log)
• Data changes since deployment: {{DATA_CHANGES}}Estimated from Fly.io metrics (transaction count in audit_logs)
• Critical data at risk: {{DATA_RISK}}User registrations, completed transactions (both are financial records)
• Acceptable to lose thistransaction data? Yes / No /— Needstransactions analysisare financial records; if loss is possible, prefer forward fix over rollback

Decision:Decision framework:

• If deployment < 30 min ago and 0 transactions completed → Proceed with rollback
/
• If Rollbackdeployment with> data30 preservationmin stepsago /or Dotransactions NOTcompleted rollback→ (dataEscalate lossto unacceptable)
  Alem for decision
• Drop is a PSD2 pass-through model — no funds stored; transaction records are audit trail only

Database Migration Reversibility

IfPhase migration0.5 migrations are all additive (add-only). No column drops, no type changes. Rolling back schema is NOT reversible: Rollback requires database restore from backup (see Section 4.2)safe.

External System State

4. Rollback Procedures

4.1 Application Rollback (Step by Step)

Total estimated time: {{APP_ROLLBACK_TIME}}2–5 minutes

# Step 1: Announce rollback (required)
# Post in war#drop-deploy room:Slack: "ROLLBACK initiated — v{{VERSION}}v0.5.0 → v{{ROLLBACK_VERSION}}v0.4.x — Reason: [state reason]"

# Step 2: Trigger rollback deployment via Fly.io
# Option A — CIFly.io pipelinerollback rollback:to {{CI_ROLLBACK_CMD}}previous release:
flyctl releases list --app drop-app  # Find the previous release number
flyctl deploy --app drop-app --image registry.fly.io/drop-app:v0.4.x

# Option B — DirectFly.io deploymentbuilt-in withrollback previouscommand:
image:flyctl {{DIRECT_ROLLBACK_CMD}}machine update --app drop-app --image registry.fly.io/drop-app:v0.4.x

# Step 3: Monitor rollback progress
{{MONITOR_CMD}}flyctl logs --app drop-app

# Step 4: Confirm rollback complete
curl {{URL}}https://getdrop.no/api/versionhealth
# Should returnreturn: {{ROLLBACK_VERSION}"status":"ok","db":"connected","version":"0.4.x"}

Verification commands:

# Check all instances running rollback version
{{INSTANCE_CHECK_CMD}}flyctl status --app drop-app

# Check health
curl {{URL}}-i https://getdrop.no/api/health

# CheckRun smoke tests against rolled-back version
npx playwright test --project=user-flows

# Verify error rate (shouldhas dropdropped
immediately)flyctl {{ERROR_RATE_CMD}}metrics --app drop-app

4.2 Database Rollback (Migration Down)

Warning: Execute database rollback ONLY after confirming:

1. Application rollback is complete
2. Data loss from migration reversal is acceptable (see Section 3)
3. Down migration is available and(it testedis, for Phase 0.5)

# Step 1: Confirm current migration state
{{MIGRATION_STATUS_CMD}}flyctl ssh console -a drop-app -C "npm run db:migrate:status"

# Step 2: Take emergency backup BEFORE running down migration
{{DB_BACKUP_CMD}}flyctl volumes list --app drop-app  # Get volume ID
# Manual: Create volume snapshot via Fly.io dashboard

# Step 3: Run down migration {{DOWN_MIGRATION_CMD}}(reverses Phase 0.5 security tables)
flyctl ssh console -a drop-app -C "npm run db:migrate:down"
# Drops: audit_logs, rate_limit_requests, transaction_locks tables

# Step 4: Verify migration state
{{MIGRATION_VERIFY_CMD}}flyctl ssh console -a drop-app -C "npm run db:migrate:status"
# Should show v0.4.x migrations only

# Step 5: Verify data integrity
bashflyctl scripts/ssh console -a drop-app -C "npm run db:verify-integrity.shintegrity"

If down migration fails or is not available:fails: Restore from pre-deployment backupFly.io volume snapshot

# Restore from backupvolume {{BACKUP_ID}}snapshot {{DB_RESTORE_CMD}}(requires --backup-idFly.io {{BACKUP_ID}}support or volume recreation)
# Contact: https://community.fly.io/ or fly.io/docs/volumes/

4.3 Configuration Rollback

# Revert environment variables (if changed in this deployment)
{{CONFIG_ROLLBACK_CMD}}# Phase 0.5 added: BCRYPT_ROUNDS, RATE_LIMIT_WINDOW_MS, RATE_LIMIT_MAX_AUTH, RATE_LIMIT_MAX_GENERAL
flyctl secrets set BCRYPT_ROUNDS=10 --app drop-app  # Only if bcrypt rounds is root cause
# Note: JWT_SECRET must remain set — never remove

# Verify configuration {{CONFIG_VERIFY_CMD}}via Fly.io secrets list
flyctl secrets list --app drop-app

Changed configuration to revert:revert (if needed):

4.4 DNSCDN / CDNDNS Rollback

Drop

DNSMVP rollbackis deployed on Fly.io only (ifno CDN for API; static assets via Next.js on Vercel for landing page). No DNS changes wereare made):expected in Phase 0.5.

# RevertVerify current DNS
recordnslookup {{DNS_REVERT_CMD}}getdrop.no

# WaitRevert forvia propagationdomain registrar (TTL:Domene.no {{DNS_TTL}}s)or sleepcurrent {{DNS_TTL}}registrar)
# VerifyTTL: nslookup {{DOMAIN}}

{{CDN_PURGE_CMD}}propagation

bashnpx scripts/smoke-tests.shplaywright {{ENVIRONMENT}}test --project=user-flows

bashflyctl scripts/ssh console -a drop-app -C "npm run db:verify-integrity.sh {{ENVIRONMENT}}integrity"

Vi opplever for øyeblikket et problem med Drop og har startet en tilbakerulling
for å løse det. Vi forventer at tjenesten gjenopprettes innen 10 minutter.
Vi beklager ulempen og vil gi oppdateringer hvert 15. minutt.