Release and roll back deliberately

A reliable Pages release starts with one reproducible build. The directory you tested is the directory you deploy. Don’t rebuild between test and deployment. If your CI can keep the artifact, deploy that exact artifact.

With Direct Upload, the sequence is explicit:

npm run build
npx wrangler pages deploy dist --project-name my-site
# ✨ Deployment complete!
# https://d4e5f6a7.my-site.pages.dev

With Git integration, Cloudflare builds from the pushed commit. You get the same property a different way: the deployment is pinned to one revision. Either way, keep the deployment history and the source revision together. When something breaks at 2am, “which commit is live?” must have an instant answer.

Smoke-test what users reach

A finished deploy command is not a working site. After deploying, test the public hostname, not only the deployment URL. Check assets, redirects, and any Functions:

curl -o /dev/null -sw '%{http_code}\n' https://www.example.com/
# 200
curl -o /dev/null -sw '%{http_code}\n' https://www.example.com/assets/app.3f9c1a.css
# 200
curl -o /dev/null -sw '%{http_code}\n' https://www.example.com/api/health
# 200

Three requests catch the three classic breakages: wrong output directory, missing fingerprinted assets, and a Function that deployed without its bindings.

Rollback selects, it does not edit

Every deployment is immutable and kept in history. So rolling back means picking a known good deployment and making it live again. In the dashboard, open the deployment list, pick the previous good one, and use “Rollback to this deployment”.

Nothing gets rebuilt. That’s why a rollback can’t fail the way a hurried “fix forward” build can. You are selecting output that already served traffic, not editing files on the edge.

One caution. Rollback restores the static output and the Functions, but it does not rewind external state. If the bad release also migrated a database, selecting an old deployment does not undo that. Plan database changes so the previous version of the site still works with the new schema.

Try this on a practice project while no real users depend on it: deploy a deliberately broken preview, deploy the fix, promote it to production, then roll production back one version and confirm the old content serves.