Add changelog for experimental resource provisioning #25962
Conversation
penalosa
requested review from
a team,
GregBrimble,
WalshyDev,
irvinebroque,
kodster28,
korinne and
mikenomitch
as code owners
github-actions
bot
added
size/s
October 2025
product:workers
|
This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:
|
github-actions
bot
assigned
dcpena,
haleycode,
patriciasantaana,
pedrosousa,
GregBrimble,
irvinebroque,
kodster28,
korinne,
mikenomitch and
WalshyDev
src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
Outdated
Show resolved
Hide resolved
src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
Outdated
Show resolved
Hide resolved
|
|
||
| When developing locally, you can interact with local versions of any KV, D1, R2 resources configured in your Wrangler configuration file, without having to include an id to existing resource | ||
|
|
||
| Once ready to deploy, run `npx wrangler deploy`. Cloudflare will automatically create the resources that do not exist and bind them to your worker. Future deployments will use the same created resources. |
There was a problem hiding this comment.
Bit nitpicky. Do we want to be clear here here that 'binding' here means writing the created resources to the configuration file. Could be an addition to the final sentence eg.
As part of this process, these bindings will be written to your wrangler configuration file. Future deployments of your worker will use these bindings.
…ovisioning.mdx Co-authored-by: emily-shen <[email protected]>
|
|
||
| import { Render, TypeScriptExample, WranglerConfig } from "~/components"; | ||
|
|
||
| If your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can still develop locally and deploy your application seamlessly, without having to run additional commands to create resources. |
There was a problem hiding this comment.
maybe include a sentence that contrasts the before to the now, something like below (but could probably be made smoother):
| If your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can still develop locally and deploy your application seamlessly, without having to run additional commands to create resources. | |
| 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 still develop locally and deploy your application seamlessly, but without having to run additional commands first. |
| @@ -0,0 +1,33 @@ | |||
| --- | |||
| title: Automatic resource provisioning | |||
There was a problem hiding this comment.
should we narrow to "Automatic resource provisioning for KV, D1, and R2" or maybe put the specific resources in the description?
Emily makes a good point here; we have templates also that would benefit from updates as a result of this change which we could follow up with in another PR. eg. https://github.com/cloudflare/templates/tree/main/chanfana-openapi-template which would no longer require the Happy to do this before/after we merge. |
src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
Outdated
Show resolved
Hide resolved
penalosa
force-pushed
the
penalosa/resource-provisioning-changelog
branch
from
189c976 to
b4a007a
Compare
src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
Outdated
Show resolved
Hide resolved
src/content/changelog/workers/2025-10-24-automatic-resource-provisioning.mdx
Outdated
Show resolved
Hide resolved
…ovisioning.mdx Co-authored-by: lrapoport-cf <[email protected]>
…ovisioning.mdx Co-authored-by: lrapoport-cf <[email protected]>
|
|
||
| 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. |
There was a problem hiding this comment.
This sentence reads odd - it's experimental but also default?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Changed the wording a bit—how does that look now?
There was a problem hiding this comment.
Looks good to me, very much in favour of the beta wording.
16 participants
No description provided.