Service‑binding permission enforcement in Wrangler dev --local mode

Question

Determine whether the Wrangler dev server applies the same service‑binding permission checks that exist in the production Cloudflare Workers runtime when the --local flag is used.

The documentation shows that wrangler dev reads bindings from wrangler.toml and offers flags to override or disable remote resources, but it does not specify whether production‑level access‑control checks for service bindings are reproduced locally. This uncertainty makes it unclear if a worker that would be rejected in production could still succeed during local testing.

Does the dev server enforce service‑binding auth policies when --local is set?
If the checks are omitted, what configuration or flag can be used to make the local environment mirror production permission boundaries?

Tasadduq Burney · Answer

Short answer
When you run wrangler dev --local, the local HTTP server starts without performing any authentication or authorization against Cloudflare’s API. It simply loads the bindings you declare in wrangler.toml or via environment variables and runs the worker. Therefore, a worker that would be rejected in production because it references a service binding the account does not own will still start and respond locally.
Why this happens
The local dev server is meant for fast iteration and debugging. It intentionally skips the same permission checks that the production Workers runtime applies. Those checks involve network calls to Cloudflare’s control plane, which would slow down local development and defeat the purpose of a quick, offline test harness.
What you can do to approximate production boundaries

Use the remote proxy mode. Run wrangler dev --remote to forward requests to the real Cloudflare runtime. This will trigger the same permission checks that happen on deployment, and a request will fail with a 403 if the binding is unauthorized.
wrangler dev --remote
# or, if you want to keep the local server but forward traffic:
wrangler dev --remote & # run in background

Validate bindings in CI. Add a step that publishes the worker to a staging environment that mirrors production. If the publish fails, the CI pipeline will surface the permission error before code merges.

Manually test binding availability. Remove a binding from wrangler.toml and run wrangler dev --local. The worker should throw a binding‑not‑found error, confirming that the local environment correctly reports missing bindings but not unauthorized ones.

No flag to enforce production checks locally
Wrangler does not provide a flag that forces the local dev server to reject unauthorized service bindings. The only built‑in way to trigger the full permission logic is to proxy through Cloudflare (via --remote) or to deploy the worker.
How to verify the behavior yourself

Create a binding that your account does not own (e.g., a service worker binding to a different account’s KV namespace).
Run wrangler dev --local and observe that the worker starts and responds to HTTP requests.
Attempt to publish the worker with wrangler publish. You should see a permission error such as Access denied: you do not have permission to bind to ....
Run wrangler dev --remote and send a request. The request will be forwarded to Cloudflare, which will reject it with a 403 if the binding is invalid.

What you need to know next
Do you have a specific binding type (KV, R2, Durable Object, etc.) that you’re concerned about? Knowing that can help narrow down which permission checks are most critical to validate in your CI pipeline.

Service‑binding permission enforcement in Wrangler dev --local mode

1 answer

Short answer

Why this happens

What you can do to approximate production boundaries

No flag to enforce production checks locally

How to verify the behavior yourself

What you need to know next

Your perspective belongs here.

0 question comments