Skip to content

Environments

Purpose

What "environment" means in this repository - fewer than a typical setup, and deliberately so.

There is no staging environment

docs/DEPLOYMENT.md states this explicitly: "No staging environment - main is production." Verified against both deploy workflows - neither has an environment: key targeting anything but production Cloudflare resources, and no second D1 database, R2 bucket, or set of Worker names exists anywhere in the repository for a non-production tier.

What actually exists

Environment Real? How to reach it
Local Yes wrangler dev per app/Worker - local D1/R2 emulation, see Local Development
Preview (per-PR) No Not configured - a PR's validate job builds and tests but deploys nothing anywhere
Staging No Does not exist
Production Yes main branch - every push deploys automatically, see CI/CD → Deployment

This is why the Deployment section of this portal has only Local and Production runbooks, not Preview/Staging ones - adding placeholder pages for environments that don't exist would misrepresent the repository, per this portal's own "document actual infrastructure" ground rule.

Practical implications

  • A merged PR is a production deploy. There is no intermediate approval gate between "merged to main" and "live" beyond the validate job passing first (see CI/CD).
  • Local wrangler dev is the only pre-production verification available - test thoroughly locally before merging; see Local Development → Running Apps.
  • D1/R2 are single-instance - a local migration mistake can't accidentally hit production ( local uses --local's SQLite emulation, entirely separate from the remote database), but a --remote migration mistake has no staging tier to catch it first. See Cloudflare → D1 for the exact commands and their blast radius.

Security considerations

Because there's no staging tier, every credential capable of a --remote/deploy action is, by definition, a production credential - see Security for how this repository handles that.