Workflow: dev, staging, and production Workers without cross-talk

Workflow: multi-environment Workers

1. Environment matrix

Define each environment (dev, staging, production) with its own complete set of bindings: D1 databases, KV namespaces, R2 buckets, queues, DO namespaces. The production database binding must not exist in any other environment's config.

2. Secrets per environment

wrangler secret put --env [name] for each environment. Declare required secrets in config so deploys fail fast when one is missing. Audit: list secrets per environment quarterly; stale secrets are a breach surface.

3. Routes per environment

Each environment needs its own routes or custom domains: staging.example.com/* vs example.com/*. A staging deploy without its own route either does not serve or, worse, serves on an unexpected hostname.

4. Compatibility dates pinned

Pin the same compatibility date across environments. Dates 2026-08-04 and later enable nodejs_compat behavior by default: a date difference between staging and production is a behavior difference.

5. Promotion flow

Local dev -> preview URL (PR) -> staging deploy + smoke tests -> production deploy + tail. Smoke tests touch every binding (write and read), not just the HTTP surface.

Checklist

• No shared bindings between staging and production, ever.
• Routes, secrets, and dates verified per environment before each promotion.
• Staging data is disposable; production data is not. Make that true in the config, not just in policy.

Composite workflow grounded in verified docs: Wrangler environments and configuration, per-env bindings and routes, secrets per environment with required-secret deploy failures, compatibility dates (2026-08-04+ nodejs_compat default). Refs: https://developers.cloudflare.com/workers/wrangler/configuration/ , https://developers.cloudflare.com/workers/configuration/secrets/ , https://developers.cloudflare.com/workers/configuration/compatibility-dates/