SOP: deploying a site change

Every marketing site deploys the same way. Pushing to main is a live production deploy — treat it accordingly.

flowchart TD
  A[Make the change on the staging branch] --> B[Push staging]
  B --> C[Cloudflare Pages builds a preview<br/>site-name.pages.dev]
  C --> D{Preview looks right?<br/>Forms tested if touched?}
  D -- No --> A
  D -- Yes --> E{Customer-facing change?}
  E -- Yes --> F[Get explicit owner approval]
  E -- "Internal/trivial" --> G
  F --> G[Merge staging into main and push]
  G --> H[Cloudflare builds and deploys PRODUCTION]
  H --> I[Spot-check the live site]

The rules

1. Two branches only: main + staging. Never create feature/fix/throwaway branches — they drift and cause mistakes. Delete strays on sight. main is the source of truth; staging is always a clean copy of it plus the change being verified.
2. Verify on the preview first (*.pages.dev), or locally with npm run build && npm run preview. Never push to main unverified.
3. Production pushes are approval-gated. “Push” or “deploy to staging” never implies production. When in doubt, ask.
4. Cloudflare runs npm run build (output dist/, NODE_VERSION=20). Never commit dist/ or node_modules/.
5. Env-var changes need a redeploy. Cloudflare Pages Functions only bind new env vars on a fresh deployment — push an empty commit if there’s nothing else to ship.

Verb glossary (so nobody miscommunicates)

You say	It means
”push” / “push live”	Commit, push, and deploy per this SOP
”deploy”	Deploy only — the code is already pushed. If the environment is ambiguous, ask; never assume production.

After deploying

• Spot-check the live page you changed.
• If the quote form was touched: submit a test lead end-to-end (email + Podium text + dashboard lead), then delete the test lead from the dashboard.