Separate production and preview deployments

A Pages project has one production environment and many previews. The production branch — usually main or master — updates the main site. Every other branch and pull request can create a preview deployment with its own URL.

Push a branch and Cloudflare builds it:

git push origin fix-pricing-table
# Cloudflare builds and publishes:
# https://a1b2c3d4.my-site.pages.dev

You get a real deployment of the real build, served by the real platform. Review happens against that URL, not against someone’s laptop. When the branch merges, the production branch builds and the main site updates.

Deployments are immutable

Treat every deployment as an immutable candidate. Each one gets a permanent URL that keeps serving exactly what was built, even after newer deployments ship. Nobody edits files on the edge; you change the site by producing a new deployment. This is what makes rollback trivial later: old deployments still exist, unchanged.

You can list them:

npx wrangler pages deployment list --project-name my-site
# Environment  Branch             Deployment URL
# Production   master             https://my-site.pages.dev
# Preview      fix-pricing-table  https://a1b2c3d4.my-site.pages.dev

Environment values differ on purpose

Preview and production often need different services and credentials. Pages lets you set environment variables and secrets separately for each environment, so a preview build can point at a test database while production points at the real one.

Configure both intentionally. The classic accident is a preview deployment writing to the production database because someone set one variable for “all environments.” When you add a variable, decide explicitly which environment gets which value.

Previews are public by default

A preview URL is not automatically private. The hash subdomain is hard to guess, but anyone who has the link can open it. If a preview contains sensitive behavior or data — unreleased features, real customer information — protect it. Cloudflare Access can require authentication on preview URLs, or you can keep sensitive data out of preview environments entirely.

Now create one preview change on a practice project. Verify the preview URL serves your change, check which commit and environment it was built from, then promote it through the normal production branch instead of copying files manually.