Connecting to production: the architecture of remote bindings

Remote bindings now generally available let you connect to deployed resources such as R2 buckets and D1 databases while running Worker code on your local machine, enabling testing against real data without redeploying for each iteration, according to The Cloudflare Blog. The system supports per-binding remote or local operation, introduced in Wrangler v4.37.0, by adding remote: true to the binding definition, and it uses Wrangler’s existing OAuth connection to the Cloudflare API.

Production-style bindings work by translating local env.KV[.]get() calls into network requests, but remote bindings bypass the production runtime by routing through a remote proxy server that talks directly to the remote resource, with the local workerd runtime handling the JS RPC interactions over websockets via Cap’n Web. This design allows some bindings to be remote while others remain locally simulated, enabling workflows that share resources across teams or reproduce bugs tied to real data.

The article also notes that the feature extends to the Cloudflare Vite plugin and vitest-pool-workers, broadening support beyond wrangler dev for developers in the JavaScript ecosystem.