Promote a reviewed change

The most common release on Vercel is a merge. You approve the pull request, merge it into main, and Vercel builds a new Production deployment from the merge commit. When that build succeeds, the production domain moves to it.

Some teams turn automatic promotion off and promote a tested deployment by hand from the dashboard or with vercel promote. Either way, the principle is the same: you must know which immutable deployment is receiving production traffic right now.

Before you merge

Record the current production deployment. You’ll want it in a minute if something goes wrong:

npx vercel@latest ls field-notes --prod

Copy the URL at the top of the list. That’s your known-good release, the one you’ll return to if the smoke test fails.

Now merge the pull request and watch the dashboard. Don’t call the release done when the build starts. Wait for Ready.

After the alias moves

Open the production domain and confirm it serves the new deployment. The deployment page shows which deployment the domain points to, or you can check from the terminal:

npx vercel@latest inspect field-notes.vercel.app

The output lists the deployment id, the commit, and the aliases. The commit should be your merge commit, not the previous one.

Then run the smoke test on the production domain, not on the Preview URL. The Preview passed already. What you’re proving now is that the same code works with production configuration, data and secrets. Load one static page, one note, submit one form, and hit /api/health. Keep the logs open while you do it.

What promotion doesn’t do

Promotion moves code and the build that came with it. It doesn’t copy the Preview database into Production, and it can’t undo a migration that already ran.

So keep schema changes compatible with both the old and the new code while a rollback is still possible. Add the column first, deploy code that reads it, and only drop the old column in a later release.

If a smoke check fails, use the deployment you recorded before the merge to move traffic back. Then fix main, so the next automatic build doesn’t ship the same bug again.

Try this on your own project: merge the footer change, watch the Production deployment go from Building to Ready, and write down both the old and the new deployment identifiers.