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

```text
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

```bash
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

```bash
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

```toml
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

```bash
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