Skip to content

Add changelog for experimental resource provisioning #25962

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Oct 24, 2025
+28 −1
Merged

Add changelog for experimental resource provisioning #25962

Show file tree
Hide file tree
Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4cb81e6
Add changelog
penalosa Oct 21, 2025
ef6f98b
Update src/content/changelog/workers/2025-10-24-automatic-resource-pr…
penalosa Oct 21, 2025
b4a007a
feedback
penalosa Oct 21, 2025
b628009
Update src/content/changelog/workers/2025-10-24-automatic-resource-pr…
penalosa Oct 23, 2025
8582d28
Update src/content/changelog/workers/2025-10-24-automatic-resource-pr…
penalosa Oct 23, 2025
5ec2080
Update 2025-10-24-automatic-resource-provisioning.mdx
penalosa Oct 24, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
title: Automatic resource provisioning for KV, R2, and D1
description: Wrangler can now automatically provision KV, R2, and D1 resources when deploying your Worker
products:
- workers
date: 2025-10-24
---

import { Render, TypeScriptExample, WranglerConfig } from "~/components";

Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.

Automatic provisioning is still experimental, but we're turning it on by default to make it easier to try out and test. It currently works for KV, R2, and D1 bindings. You can disable the feature using the `--no-x-provision` flag.
Copy link
Contributor

@irvinebroque irvinebroque Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence reads odd - it's experimental but also default?

Copy link
Contributor

@irvinebroque irvinebroque Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I intuit the logic here

It can be default because it doesn't actually change anything if you have a configuration already

As a customer i still have questions though

  • if it's default behavior how can it also be experimental? Sounds like it is just default?
  • if I mess up and omit a KV namespace ID, and then deploy, can I inadvertently have a bad deployment?

I'm guessing we have answers here but feels like there's something left unsaid maybe?

Copy link
Contributor Author

@penalosa penalosa Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's default behavior how can it also be experimental?

The idea is that it's on by default (so anyone can use it without having to add experimental flags), but that it's still experimental to give us a bit of an out to be able to make breaking changes. In particular, I'm trying to leave space open for changing whether or not this is interactive by default. That all said, it's a stable feature, so maybe that's being a bit overcautious.

if I mess up and omit a KV namespace ID, and then deploy, can I inadvertently have a bad deployment?

No, that's what this feature supports. As part of the deploy process a real namespace would be provisioned, and so you'd end up with a deployment that worked exactly as it did during local dev.

Copy link
Contributor

@petebacondarwin petebacondarwin Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we should change the wording to say that this feature is in open beta (which is really what we are doing here), and point out that this means we may make breaking changes to it?

Copy link
Contributor Author

@penalosa penalosa Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed the wording a bit—how does that look now?

Copy link
Contributor

@MattieTK MattieTK Oct 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, very much in favour of the beta wording.


To use this feature, update to [email protected] and add bindings to your config file _without_ resource IDs e.g.:

```jsonc
{
"kv_namespaces": [{ "binding": "MY_KV" }],
"d1_databases": [{ "binding": "MY_DB" }],
"r2_buckets": [{ "binding": "MY_R2" }],
}
```

`wrangler dev` will then automatically create these resources for you locally, and on your next run of `wrangler deploy`, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.

Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.
2 changes: 1 addition & 1 deletion src/content/docs/workers/runtime-apis/bindings/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ import { DirectoryListing, WranglerConfig } from "~/components";

Bindings allow your Worker to interact with resources on the Cloudflare Developer Platform. Bindings provide better performance and less restrictions when accessing resources from Workers than the [REST APIs](/api/) which are intended for non-Workers applications.

The following bindings available today:
The following bindings are available today:

<DirectoryListing />

Expand Down
Loading