Rollback

Revert a bad deployment to the last known-good image.

Option 1: Railway Dashboard (Fastest)

1. Open Railway → select the project
2. Select the affected service
3. Go to the Deployments tab
4. Find the last known-good deployment
5. Click Redeploy on that deployment

Railway re-runs the exact same image that was used for that deployment.

Option 2: GitHub Actions

1. Go to fin-infra Actions
2. Select Deploy to Staging (or Deploy to Production)
3. Run workflow → select the target service
4. Specify the previous image tag (e.g. :<short-sha>)

Image Tags Reference

Tag	Meaning
latest	Most recent build from main
:<short-sha>	Specific commit (all branches)
:<branch-slug>	Branch builds (non-main)

Find the short SHA from the blitz or blitz-ui GitHub commit history, or from the previous successful deployment in Railway.

Registry: ghcr.io/finaisse-org/blitz-<service>

Option 3: Local Script

cd railway
export RAILWAY_API_TOKEN=...
export RAILWAY_PROJECT_ID=...
export RAILWAY_ENVIRONMENT_ID=...

# Redeploy a specific service (picks up latest image)
bun run scripts/deploy.ts blitz-api

To pin a specific image tag, set the IMAGE_TAG environment variable before deploying (check scripts/deploy.ts for exact usage).

Rolling Back via the Release Manifest

If the service was deployed via Release Management's tag/manifest flow, reverting its entry in railway/environments/staging/release.json to an older tag/digest (in a normal PR) is the rollback. Since 2026-09-13 merging that PR deploys it — Release Manifest and Deploy triggers on any merged PR touching the manifest — so the older image goes out without a separate dispatch. No special rollback flag or code path.

No tag is created, so the version monotonicity check never fires and cannot block a rollback.

The rolled-back version number is burned

The fix that follows a rollback cannot reuse the withdrawn version — it was pushed, built, and its image is in GHCR, so monotonicity rejects it. Take the next patch (v0.6.0 withdrawn → fix ships as v0.6.1) and say which version was withdrawn in the revert PR body; nothing records that automatically today. Tracked in fin-infra#204.

Emergency: Revert a Database Migration

Migrations in Blitz are managed per-domain package via Prisma. See blitz/docs/database/migrations.md for rollback steps. Database rollbacks require developer access and should be coordinated carefully — they may require a service rollback to accompany the schema revert.

After Rollback

• [ ] Verify service health: bun run status
• [ ] Check logs: bun run logs -- --service <name>
• [ ] Confirm the rollback resolved the issue
• [ ] Open a post-mortem if this was a P1 incident (see Run & Operate)