Release and roll back deliberately

A reliable Pages release starts with one reproducible build. The directory you tested is the directory you deploy. Do not rebuild different bits between test and deployment — if your CI can preserve 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, which gives you the same property a different way: the deployment is pinned to one revision. Either way, keep 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 deployment, test the public hostname, not the deployment URL alone: 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

Because every deployment is immutable and kept in history, rolling back means selecting 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.”

Rollback should select a known good deployment rather than editing output files on the edge. Nothing gets rebuilt, so the rollback cannot fail the way a hurried “fix forward” build can. One caution: rollback restores the static output and Functions, but it does not rewind external state. If the bad release also migrated a database, selecting an old deployment does not undo that.

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