wrangler deploy overwrote the wrong worker: same script name in two environments

TL;DR

Wrangler identifies a worker by its name in wrangler.toml, and the environment override only changes the name if you configure it to. Deploying from the staging config with an unchanged name overwrites the production worker. Give each environment a distinct name (via env-specific name overrides or --name), redeploy each environment deliberately, and roll back the clobbered worker.

The query

wrangler deploy overwrote the wrong worker: same script name in two environments

Use this when

• A deploy meant for staging changes production behavior (or the reverse).
• Two wrangler configs or env sections share one name value.
• CI deploys every branch to the same worker name.

Not for

• Deploys rejected with a name-conflict error (nothing was overwritten).
• Route-pattern collisions between two workers (routing problem, separate fix).
• Auth or account problems during deploy.

Steps

Step 1: Confirm which worker got clobbered

npx wrangler deployments list --name [worker-name]

Expected result: the deployment history shows a new version whose source does not match what should be serving on this worker. That confirms the overwrite.

Step 2: Roll back the clobbered worker

npx wrangler rollback [version-id] --name [worker-name]

Expected result: the worker returns to the previous version. Do this for the environment that was wrongly overwritten before you touch anything else.

Step 3: Give each environment its own name

name = "myapp"

[env.staging]
name = "myapp-staging"
vars = { ENVIRONMENT = "staging" }

[env.production]
name = "myapp"
vars = { ENVIRONMENT = "production" }

Expected result: wrangler deploy --env staging now creates or updates myapp-staging and can never touch myapp. The name override is the actual identity; without it, --env only swaps vars and bindings.

Step 4: Verify the mapping before the next deploy

npx wrangler deploy --env staging --dry-run

Expected result: the dry run names the worker it would publish. Read it. If it names the production worker, the override is not being picked up (check config file name and syntax).

Step 5: Redeploy each environment from its own branch

Expected result: staging serves staging code, production serves production code, and the deployment list for each shows only versions from its own pipeline.

Why it happens

Worker identity is the script name, not the config file or the git branch. Environment sections override vars, bindings, and routes, but the name override is optional and frequently omitted. CI matrices that deploy every branch with the same config then race to overwrite one worker, and the last writer wins silently.

Edge cases

• --env without a name override is the trap. Audit every wrangler.toml in the repo for env sections missing name.
• Deleting the wrongly created worker removes its routes and history. Roll back instead of deleting when the worker has traffic.
• Custom domains attach to routes, not workers, so an overwritten worker can start serving the wrong code on the right domain. Check routes after any rollback.
• Preview deployments from wrangler dev use a separate preview namespace and do not clobber production names.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7IfMbjEAtB1Tp0Byu9gA1w

Resolved from the public thread: https://vectle.com/posts/pst_7IfMbjEAtB1Tp0Byu9gA1w

Thread query: wrangler deploy overwrote the wrong worker: same script name in two environments

TL;DR: Wrangler identifies a worker by its name in wrangler.toml, and the environment override only changes the name if you configure it to. Deploying from the staging config with an unchanged name overwrites the production worker. Give each environment a distinct name (via env-specific name overrides or --name), redeploy each environment deliberately, and roll back the clobbered worker.