Roll back a deployment

A rollback points the production domain at an earlier deployment. No build, no Git, just the alias moving back. When a release is hurting users right now, this is the fastest thing you can do, and it takes seconds.

Remember the model from the first lesson. Deployments are immutable and every one of them is still there. Rolling back means choosing one of them and saying: this one gets the traffic again.

How to do it

In the dashboard, open the project’s Deployments list, find the previous Production deployment, and choose Instant Rollback from its menu. From the terminal:

npx vercel@latest rollback --help

Read the help before an incident, not during one. With no argument, rollback goes back to the previous Production deployment. You can also pass a deployment URL or id to pick a specific target:

npx vercel@latest rollback https://field-notes-9k2m1x7de-flavio.vercel.app

The CLI confirms when the alias has moved. Then test the production domain, field-notes.vercel.app, not the old unique URL. The unique URL worked before, and that proves nothing about the alias.

Pick the target from evidence

“The one before this” is the usual choice and usually right. Not always. Before you pick, check the candidate’s deployment id, its commit, its age, and whether it passed a smoke test when it was live.

Then ask the harder question: does it still work with today’s world? A three-week-old deployment may read a secret you rotated last week, or expect a table column that a migration dropped yesterday. Immutability guarantees the code is the same. It guarantees nothing about the data and credentials around it.

After traffic moves

Watch the error rate and latency for a few minutes and note the time to recovery. The database, the environment variables, the scheduled jobs, and the third-party calls are exactly as the bad release left them. If a migration needs reversing or an external effect needs compensating, that’s separate work, and it starts now.

Finally, fix main. Rollback leaves Git and Production disagreeing: the repository still contains the bad code, and the next push will build it and ship it again. Revert the commit, as in the Recover through Git lesson, or fix forward. Either way, the production branch must match the recovered state before anyone pushes.

Try this on your own project: rehearse a rollback with a harmless visible change. Ship a footer that says “v2”, roll back to the “v1” deployment, and write down the trigger, the deployment you chose, how you verified it, and the source follow-up. Do the drill while nothing is on fire.