Staging and Rollbacks
Two habits separate a launch that recovers gracefully from one that turns into a midnight panic: testing changes somewhere safe before they hit real users, and being able to undo a bad instantly.
A staging environment is just a second copy of your app — same code, separate , separate (or throwaway) — where you try things before production. Most hosts make this nearly free: every gets its own preview URL automatically, so you can click through a change and share it with someone before merging. Use it especially for anything you cannot easily reverse, like a database migration.
Picture the three environments as a ladder a change climbs, with rollback as the rope that drops production straight back to the last good rung:
dev ──▶ staging / preview ──▶ production
(laptop) (PR preview URL) (real users)
try click through live
anything share, verify ┌──────────────┐
│ deploy #42 │ ◀── current (broken)
├──────────────┤
ROLLBACK│ deploy #41 │ ◀── last known good
│ ├──────────────┤
└──▶│ deploy #40 │
└──────────────┘
one command / one click = instant undo
A rollback is your undo button for the whole app. Because these platforms keep every previous deploy, going back to the last good version is usually one command or one dashboard click:
# Cloudflare Pages: redeploy a known-good build
wrangler pages deployment list
wrangler pages deployment rollback <DEPLOYMENT_ID>
# Vercel: promote a previous deployment back to production
vercel rollback <DEPLOYMENT_URL>
Know this command before you need it, not during the outage. The whole point of vibe-coded velocity is that shipping is cheap — but cheap shipping only feels safe when un-shipping is just as cheap.