feat: add automatic resource provisioning documentation

src/components/WranglerConfig.astro

@@ -3,6 +3,13 @@ import { parse } from "node-html-parser";
 import { Code, Tabs, TabItem } from "@astrojs/starlight/components";
 import TOML from "@iarna/toml";
 import { parse as jsoncParse } from "jsonc-parser";
+import { z } from "astro:schema";
+
+const props = z.object({
+	removeSchema: z.boolean().optional().default(false),
+});
+
+const { removeSchema } = props.parse(Astro.props);
 
 const slot = await Astro.slots.render("default");
 
@@ -12,15 +19,15 @@ const copy = html.querySelector("div.copy > button");
 
 if (!copy) {
 	throw new Error(
-		`[WranglerConfig] Unable to find copy button in rendered code block HTML.`,
+		`[WranglerConfig] Unable to find copy button in rendered code block HTML.`
 	);
 }
 
 let code = copy.attributes["data-code"];
 
 if (!code) {
 	throw new Error(
-		`[WranglerConfig] Unable to find data-code attribute on copy button.`,
+		`[WranglerConfig] Unable to find data-code attribute on copy button.`
 	);
 }
 
@@ -38,10 +45,11 @@ let toml, json;
 
 if (language === "toml") {
 	toml = code;
-	json = JSON.stringify({
-		"$schema": "./node_modules/wrangler/config-schema.json",
-		...TOML.parse(code),
-	}, null, 2);
+	const parsedToml = TOML.parse(code);
+	const jsonObj = removeSchema
+		? parsedToml
+		: { $schema: "./node_modules/wrangler/config-schema.json", ...parsedToml };
+	json = JSON.stringify(jsonObj, null, 2);
 } else {
 	json = code;
 	toml = TOML.stringify(jsoncParse(code));

src/content/docs/style-guide/components/wrangler-config.mdx

@@ -10,6 +10,7 @@ This component can be used to automatically generate a `jsonc` version of the `t
 
 ```mdx
 import { WranglerConfig } from "~/components";
+
 ```
 
 ## Usage
@@ -25,12 +26,10 @@ database_name = "prod-d1-tutorial"
 database_id = "<unique-ID-for-your-database>"
 ```
 </WranglerConfig>
-
 ````
 
 A `$today` value can be used in this component to automatically insert the today's date. This is useful for suggesting that users set the latest compatibility date.
 
-
 ````mdx live
 import { WranglerConfig } from "~/components";
 
@@ -42,5 +41,21 @@ import { WranglerConfig } from "~/components";
 }
 ```
 </WranglerConfig>
+````
+
+The `removeSchema` prop can be used to remove the `$schema` reference from the generated JSON file. This can be useful if you want to add snippets of configuration files that are easier to copy paste, and are providing toml as the source config format.
+
+If you provide jsonc as the source config format, the `removeSchema` prop will be ignored.
+
+````mdx live
+import { WranglerConfig } from "~/components";
 
-````
+<WranglerConfig removeSchema>
+```toml
+[[d1_databases]]
+binding = "DB" # available in your Worker on env.DB
+database_name = "prod-d1-tutorial"
+database_id = "<unique-ID-for-your-database>"
+```
+</WranglerConfig>
+````

src/content/docs/workers/wrangler/configuration.mdx

@@ -9,7 +9,13 @@ description: Use a configuration file to customize the
   Platform products.
 ---
 
-import { Render, Type, MetaInfo, WranglerConfig } from "~/components";
+import {
+	Render,
+	Type,
+	MetaInfo,
+	WranglerConfig,
+	InlineBadge,
+} from "~/components";
 import { FileTree } from "@astrojs/starlight/components";
 
 Wrangler optionally uses a configuration file to customize the development and deployment setup for a Worker.
@@ -71,6 +77,28 @@ Further, there are a few keys that can _only_ appear at the top-level.
 
 <Render file="vite-environments" product="workers" />
 
+## Automatic provisioning <a href="https://developers.cloudflare.com/changelog/2025-10-24-automatic-resource-provisioning/" target="_blank"><InlineBadge preset="beta" /></a>
+
+Wrangler can automatically provision resources for you when you deploy your Worker without you having to create them ahead of time.
+
+This currently works for KV, R2 and D1 bindings.
+
+To use this feature, add bindings to your configuration file _without_ adding resource IDs, or in the case of R2, a bucket name. Resources will be created with the name of your worker as the prefix.
+
+<WranglerConfig removeSchema>
+
+```toml
+kv_namespaces = [
+  { binding = "<MY_KV_NAMESPACE>" }
+]
+```
+
+</WranglerConfig>
+
+When you run `wrangler dev` local resources will automatically be created which persist between runs. When you run `wrangler deploy` resources will be created for you, and their IDs will be written back to your configuration file.
+
+If you deploy a worker with resources and no resource IDs from the dashboard (e.g. via GitHub), resources will be created, but their IDs will only be accessible via the dashboard. Currently these resource IDs will not be written back to your repository.
+
 ## Top-level only keys
 
 Top-level keys apply to the Worker as a whole (and therefore all environments). They cannot be defined within named environments.
@@ -1422,35 +1450,34 @@ A common example of using a redirected configuration is where a custom build too
 - `my-tool` generates a `dist` directory that contains both compiled code and a new generated deployment configuration file, containing only the settings for the given environment.
   It also creates a `.wrangler/deploy/config.json` file that redirects Wrangler to the new, generated deployment configuration file:
 
-  <FileTree>
-  - dist
-    - index.js
-    - wrangler.jsonc
-  - .wrangler
-    - deploy
-      - config.json
-
-  </FileTree>
-
-  The generated `dist/wrangler.jsonc` might contain:
-
-  ```json
-  {
-  	"name": "my-worker",
-  	"main": "./index.js",
-  	"vars": {
-  		"MY_VARIABLE": "staging variable"
-  	}
-  }
-  ```
+	<FileTree>
+		- dist
+  		- index.js
+  		- wrangler.jsonc
+		- .wrangler
+  		- deploy
+    		- config.json
+	</FileTree>
+
+The generated `dist/wrangler.jsonc` might contain:
+
+```json
+{
+	"name": "my-worker",
+	"main": "./index.js",
+	"vars": {
+		"MY_VARIABLE": "staging variable"
+	}
+}
+```
 
-  Now, the `main` property points to the generated code entry-point, no environment is defined,
-  and the `MY_VARIABLE` variable is resolved to the staging environment value.
+Now, the `main` property points to the generated code entry-point, no environment is defined,
+and the `MY_VARIABLE` variable is resolved to the staging environment value.
 
-  And the `.wrangler/deploy/config.json` contains the path to the generated configuration file:
+And the `.wrangler/deploy/config.json` contains the path to the generated configuration file:
 
-  ```json
-  {
-  	"configPath": "../../dist/wrangler.jsonc"
-  }
-  ```
+```json
+{
+	"configPath": "../../dist/wrangler.jsonc"
+}
+```