# 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.