CI/CD's own rollback-strategies lesson covered rollback as something a pipeline has to be deliberately engineered to support — redeploying a previous artifact, reverting a migration, or routing traffic back to an old version. Vercel's deployment model makes one specific kind of rollback close to instantaneous, because of how it treats every deployment as immutable from the moment it's built.
Intermediate
2 min read
Every deployment is a separate, permanent, immutable artifact
Deployment A (commit abc123) — still fully running, its own URL
Deployment B (commit def456) — still fully running, its own URL
Deployment C (commit ghi789) — PROMOTED to production, own URL + the custom domain
Every single deployment Vercel ever builds — preview or production — keeps running at its own unique URL indefinitely (subject to retention limits), even after a newer one is promoted to production. "Deploying" doesn't mean replacing a previous version in place; it means building a brand-new, fully isolated deployment and then pointing the production domain at it. The previous deployment doesn't stop running — it's simply no longer the one the custom domain resolves to.
Why this makes rollback close to instant
Because an older deployment never actually stopped running, "rolling back" doesn't mean rebuilding an old commit or running a redeploy pipeline from scratch — it means re-pointing the production domain back at a deployment that's already fully built and already warm. This is a genuinely different mechanism than CI/CD's own rollback-strategies lesson describes for a traditional server deployment (redeploy an old artifact, which takes real build/deploy time again) — Vercel's version is closer to flipping a switch than re-running a pipeline.
vercel rollback# or, from the dashboard: click any previous deployment, "Promote to Production"
The real limit: this covers the application layer, not the database
Instant rollback reverts which code is serving production traffic — it does nothing about a database migration that already ran against the new code, or any external side effect (an email already sent, a webhook already processed) the new deployment already triggered before the rollback happened. This is exactly the gap CI/CD's own zero-downtime-deploys-and-migrations lesson covers in depth: a schema migration needs to be backward-compatible with the previous code version specifically so an instant application rollback like this one doesn't immediately break against already-migrated data.
Deployment protection: requiring a check before a deployment can even be promoted
Vercel's deployment protection features (password-protecting a preview, requiring a specific team member's approval before a deployment is promotable) let a team add a deliberate gate on top of the otherwise fully automatic pipeline — closer to CI/CD's own "environments and approvals" concept than anything automatic, and a genuine choice a team makes explicitly rather than something that happens by default.