wrangler deploy: automatic resource provisioning is on by default and documented only in a changelog (--x-auto-create nowhere)

[oddharsh]

Which page

https://developers.cloudflare.com/workers/wrangler/commands/ (the wrangler deploy section)

What's missing

Automatic resource provisioning is on by default and can create real KV namespaces, R2 buckets, and D1 databases on your account during a deploy. The reference docs for wrangler deploy don't mention it.

Right now the only place it appears is a changelog entry from 2025-10-24, Automatic resource provisioning for KV, R2, and D1, which names --no-x-provision.

A changelog is the wrong home for this. Someone reading wrangler deploy's options today has no way to learn that a binding declared without an ID will be created for them.

Two flags, and one is undocumented anywhere

Both are hidden: true in Wrangler, so --help lists neither. Read from wrangler 4.125.0's own source:

"experimental-provision": {
  describe: "Experimental: Enable automatic resource provisioning",
  type: "boolean",
  default: true,
  hidden: true,
  alias: ["x-provision"]
},
"experimental-auto-create": {
  describe: "Automatically provision draft bindings with new resources",
  type: "boolean",
  default: true,
  hidden: true,
  alias: "x-auto-create"
}

Searching the docs repo: x-provision appears once, in that changelog. experimental-provision, x-auto-create, and experimental-auto-create appear nowhere at all.

Both are accepted by wrangler deploy and wrangler versions upload. Verified by exit code, since --help won't tell you:

wrangler deploy --dry-run --x-bogus-flag        exit 1
wrangler deploy --dry-run --x-provision=false   exit 0
wrangler deploy --dry-run --x-auto-create=false exit 0
wrangler versions upload --dry-run --x-provision=false  exit 0

Why it matters

Anyone running a policy where no deploy path may create account resources has to pin both flags off, on every deploy command, including the ones configured in the Workers Builds dashboard. That's hard to get right when one flag is documented in a changelog and the other isn't documented at all.

Suggested addition

Document both flags in the wrangler deploy options, state that each defaults to true, and say which commands honour them. A note that wrangler versions upload takes them too would help, because the changelog only talks about deploy.

[MattieTK]

Thanks for the feedback, can you clarify how this affects you as here:

Anyone running a policy where no deploy path may create account resources has to pin both flags off, on every deploy command, including the ones configured in the Workers Builds dashboard.

If you can't create the resource that the worker depends on then your worker is going to possibly encounter problems on deployment anyway.

[oddharsh]

Ah for sure - on this account, a binding missing its corresponding id is config drift: a typo, the wrong config file, a half-finished migration, so the two behaviors differ in when the failure surfaces.

With provisioning off, the deploy'd fail loudly immediately, and with provisioning on, the deploy'd go green, wrangler mints a fresh empty namespace, and the Worker reads an empty KV/D1 that shadows the real data. The latter seems worse because nothing outright errors and the symptom is a production Worker quietly serving nothing, which might be hard to diagnose if the user doesn't know better.

You're definitely right on provisioning being a good default for folks standing up a new project. My setup is the other case, where the resources already exist, they're declared in a checked-in config, and creating one ends up being a deliberate act behind a separate write-scoped token run from a workstation. Deploy pipelines hold narrower tokens on purpose in my case (and this feels like a coding agent tendency too), so with provisioning on, every deploy command doubles as a resource-creation path holding whatever credential that pipeline has.

Concretely, my repo has four deploy paths: two local scripts plus the two commands in the Workers Builds dashboard (production deploy and the non-production branch deploy). All four now pin --x-provision=false --x-auto-create=false. But my issue was that getting there took reading wrangler's source for the flag names and probing acceptance by exit code, since --help listed neither. I also missed the branch-deploy command at first, so for a while every branch push ran with both defaults on against a Worker holding production's bindings. I think it's totally possible that this is a weird edge case and/or that this is an impact from the flags being hidden and true.

Whether auto-provisioning should default on is probably a wrangler question, so I don't know if changing it is a question for here :) The docs ask is a bit more narrowly scoped: the wrangler deploy reference could say the behavior exists, name both flags, and note that versions upload honors them too, so the off-switch is learnable to users without the need to read source. Totally defer to your judgement as to whether this is a normal situation to end up in!