Remote Bindings GA (#25153)

* Remote Bindings GA

* document --local

* Update src/content/changelog/workers/2025-09-16-remote-bindings-ga.mdx

Co-authored-by: Dario Piotrowicz <[email protected]>

* Update src/content/changelog/workers/2025-09-16-remote-bindings-ga.mdx

Co-authored-by: lrapoport-cf <[email protected]>

* Apply suggestion from @lrapoport-cf

Co-authored-by: lrapoport-cf <[email protected]>

* Update 2025-09-16-remote-bindings-ga.mdx

---------

Co-authored-by: Dario Piotrowicz <[email protected]>
Co-authored-by: lrapoport-cf <[email protected]>

Author: 3 people

src/content/changelog/workers/2025-09-16-remote-bindings-ga.mdx

@@ -0,0 +1,44 @@
+---
+title: Remote bindings GA - Connect to remote resources (D1, KV, R2, etc.) during local development
+description: You can now connect to R2 buckets, D1 databases, and other resources running on Cloudflare, while running your Worker's code locally, on your own machine.
+products:
+  - workers
+date: 2025-09-16
+---
+
+import { WranglerConfig, Aside } from "~/components";
+
+Three months ago [we announced the public beta](/changelog/2025-06-18-remote-bindings-beta/) of [remote bindings](/workers/development-testing/#remote-bindings) for local development. Now, we're excited to say that it's available for everyone in Wrangler, Vite, and Vitest without using an experimental flag!
+
+With remote bindings, you can now connect to deployed resources like [R2 buckets](/r2/) and [D1 databases](/d1/) while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.
+
+## Example configuration
+
+To enable remote bindings, add `"remote" : true` to each binding that you want to rely on a remote resource running on Cloudflare:
+
+<WranglerConfig>
+
+```jsonc title="wrangler.jsonc"
+{
+	"name": "my-worker",
+	"compatibility_date": "$today",
+
+	"r2_buckets": [
+		{
+			"bucket_name": "screenshots-bucket",
+			"binding": "screenshots_bucket",
+			"remote": true,
+		},
+	],
+}
+```
+
+</WranglerConfig>
+
+When remote bindings are configured, your Worker **still executes locally**, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.
+
+**You can [try out remote bindings](/workers/development-testing/#remote-bindings) for local development today with:**
+
+- [Wrangler v4.37.0](/workers/wrangler/)
+- The [Cloudflare Vite Plugin](/workers/vite-plugin/)
+- The [Cloudflare Vitest Plugin](/workers/testing/vitest-integration/)

src/content/docs/workers/development-testing/index.mdx

@@ -65,7 +65,8 @@ By default, running `wrangler dev` / `vite dev` (when using the [Vite plugin](/w
 During local development, your Worker code interacts with these bindings using the exact same API calls (such as `env.MY_KV.put()`) as it would in a deployed environment. These local resources are initially empty, but you can populate them with data, as documented in [Adding local data](/workers/development-testing/local-data/).
 
 - By default, bindings connect to **local resource simulations** (except for [AI bindings](/workers-ai/configuration/bindings/), as AI models always run remotely).
-- You can override this default behavior and **connect to the remote resource**, on a per-binding basis. This lets you connect to real, production resources while still running your Worker code locally.
+- You can override this default behavior and **connect to the remote resource** on a per-binding basis with [remote bindings](/workers/development-testing/#remote-bindings). This lets you connect to real, production resources while still running your Worker code locally.
+- When using `wrangler dev`, you can temporarily disable all [remote bindings](/workers/development-testing/#remote-bindings) (and connect only to local resources) by providing the `--local` flag (i.e. `wrangler dev --local`)
 
 ## Remote bindings