Cloudflare recently announced the general availability of remote bindings for local development. Remote bindings let developers connect to production, deployed resources in their Cloudflare account, rather than using local simulations.
Thanks to the new feature, developers can connect to deployed resources, such as R2 buckets and D1 databases, while running Worker code on their local machine, enabling testing of local code changes against real data and services.
Remote bindings for local development are supported in Wrangler v4.37.0, the Cloudflare Vite plugin, and the @cloudflare/vitest-pool-workers package. For example, developers can tell Wrangler or Vite to send all requests to env.MY_BUCKET using:
{
"name": "my-worker",
"compatibility_date": "2025-09-25",
"r2_buckets": [
{
"bucket_name": "my-bucket",
"binding": "MY_BUCKET",
"remote": true
},
],
}
Although all requests to env.MY_BUCKET will be proxied to the remote resource, the Worker code will execute locally, providing faster execution times without the need to seed local databases with data. Furthermore, developers can pair remote bindings with environments so that staging data can be accessed during local development while production data remains untouched.
Samuel Macleod, senior systems engineer at Cloudflare, and Dario Piotrowicz, web developer at Cloudflare, explain how bindings work under the hood in production. They write:
We wanted to make it really easy for developers to access remote resources without having to change their production Workers code, and so we landed on a solution that required us to fetch data from the remote resource at the point of use in your Worker (…) We realised that we already had a ready-made API waiting for us — the one we use in production! Most bindings on the Workers platform boil down to essentially a service binding.
A service binding is a link between two Workers that allows them to communicate over HTTP or JSRPC. Macleod and Piotrowicz add:
We realised that we could use that natural network boundary to implement remote bindings. Instead of the production runtime translating env.KV.get() to an HTTP call, we could have the local runtime (workerd) translate env.KV.get() to an HTTP call, and then send it directly to the KV service, bypassing the production runtime.
Source: Cloudflare blog
With a remote KV binding, the local Worker no longer uses the local KV simulator. Instead, it talks to a remote proxy client that connects to a proxy server linked to the real KV store, allowing the local Worker to access the live KV data. The reaction of the community has been positive, with Dyords Abuzo writing:
No more ‘it worked on my machine… but where did my data go in production?!’ This is a massive win for developer experience, making building on Cloudflare Workers even more delightful.
The wrangler package now exports utilities such as startRemoteProxySession, allowing tools that do not leverage wrangler dev to also support remote bindings. Starting in Wrangler v4.37.0 (and the matching Vite and Vitest plugin versions v1.13.0 and v0.9.0), remote bindings are available for all projects. Developers can enable them for any binding by adding remote: true in the Wrangler config.
