# Fix KV namespace binding is invalid after wrangler deploy

## TL;DR

The `id` in your `[[kv_namespaces]]` binding does not match a real KV namespace in your account - usually it points at a deleted namespace or at the preview ID. Run `wrangler kv namespace list`, paste the correct production ID into the binding, and redeploy. Deploy-time validation resolves every binding ID against your account, so a stale ID fails the deploy.

## Verbatim error

```text
Error: KV namespace binding is invalid after wrangler deploy
```

## Steps

1. Run `npx wrangler kv namespace list`. Expected: a JSON list; confirm your namespace is present with its current ID.
2. Compare that ID with the `id` under `[[kv_namespaces]]` in wrangler.toml. Expected: you will usually find a mismatch - a deleted-and-recreated namespace or a copied preview ID.
3. Update the binding `id` to the real production namespace ID (keep `preview_id` for local dev). Expected: the IDs in the file match the list output.
4. Run `npx wrangler deploy`. Expected: the deploy succeeds with no binding validation errors.
5. Hit the worker and exercise a KV read and write. Expected: no "binding is invalid" error at runtime.

## Use this when

- "KV namespace binding is invalid" appears right after deploy
- KV worked before a namespace was deleted and recreated
- A `preview_id` was accidentally used as the production `id`

## Not for this skill when

- The binding is undefined only in local dev (missing `preview_id`, different fix)
- The namespace was deleted entirely (recreate it first, then update IDs)
- The deploy fails on authentication or account selection instead

## Variant phrasings

- kv binding invalid production
- wrangler deploy kv namespace not found
- Error 10014 kv binding
- KV namespace ID invalid on deploy

## Why it happens

Namespace IDs change when you delete and recreate a namespace, and configs copied between projects often carry a stale or preview ID. Deploy-time validation resolves each binding ID against your account, so anything that does not resolve is rejected before the worker goes live.

## Edge cases

- In multi-account setups the ID must exist in the account you deploy to; check `wrangler whoami` first.
- workers.dev versus custom domain does not change binding validity.
- Editing secrets or vars does not require rebinding; only the namespace ID matters here.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jrfwmNCHNiA-sgAODOTuJA