Cloudflare, Inc.

A binding is a name on the Worker’s env object that points at one resource, declared in the Wrangler file and attached when the Worker is deployed. Cloudflare’s docs call it “a permission and an API in one piece”: declaring an R2 binding is what grants the Worker the right to read and write that bucket, and env.MY_BUCKET.put(key, body) is how it does so. The underlying credential never reaches the Worker’s code. Every Worker starts with no access and gets exactly the bindings it declares.

Cloudflare’s Kenton Varda explained the choice in an April 2024 post. Compared with a hostname plus an API key in an environment variable, a binding removes the key, so there is nothing for a stray log line to leak. It closes server-side request forgery: no URL an attacker supplies can reach an internal service, because the only way in is the binding. And it removes the second half of the usual two-step setup, pointing the service at a resource and then granting the resource to the service in an ACL, since declaring the binding does both. Because the platform sees every binding, it can answer which Workers use a given resource. Varda calls bindings “very much inspired by capability-based security”, but not yet a complete capability system, since a Worker can’t hand a binding to another Worker.

Bindings also make the same code run against different resources. Wrangler environments bind the same names to staging namespaces and databases (bindings are not inherited between environments, so each one lists its own), and wrangler dev runs the Worker locally in Miniflare on workerd, the same runtime used in production, with locally simulated KV, R2, D1, Queues and Durable Objects. Remote bindings point a local Worker at the real resources instead. One catch from the docs: when a deploy changes only bindings, Cloudflare may keep running isolates that already exist, so a client built from env and cached in global scope can outlive the value it was built from. Build such clients per request.

Calls between Workers cost almost nothing: by default both Workers of a service binding run on the same thread of the same server. Calls to data are different, because the data has a location. Cloudflare’s own example is a user in Sydney whose Worker makes several round trips to a database in Frankfurt; each trip crosses the planet. The 2023 Smart Placement launch post measured a Worker making three round trips to a Frankfurt database from Sydney and found it 4 to 8 times faster once the Worker ran near the database instead of near the user.

There are three ways to move the Worker. Smart Placement ("mode": "smart", still beta) measures request duration in different locations and forwards requests to one that is significantly faster; it needs steady traffic from several locations, can take 15 minutes to decide, leaves 1% of requests unplaced as a baseline, and only affects fetch handlers, not RPC methods. Placement Hints name the target directly: a cloud region such as "aws:us-east-1", or, experimentally, a host or hostname that Cloudflare probes. The docs say this can cut each query from 20 to 30 milliseconds to 1 to 3. The third way is to leave the Worker near the user and put Hyperdrive in front of the database, which keeps pools of open database connections across Cloudflare’s network and caches read queries; its launch post counts up to seven round trips just to open a Postgres connection without it.

Cloudflare’s own stores have the same question. A D1 primary is created near wherever the create request came from, and queries go to it unless you use the Sessions API with read replicas. A Durable Object is created near its first caller (or where a location hint says) and, per the docs, does not currently move afterwards. So a design usually puts per-user or per-room state in Durable Objects near those users, shared reference data in KV, and the system of record wherever it already lives, with the Worker placed next to whichever of those it talks to most.

Bindings tie code to Cloudflare. env.DB.prepare() and env.CARTS.getByName() are Cloudflare APIs, so moving a Worker elsewhere means rewriting those calls. The exits are at the data layer: R2 speaks the S3 API, Basin Catalog is a standard Iceberg REST catalog, and Hyperdrive fronts a Postgres or MySQL database you own. The open-source workerd runtime can self-host Workers code, but its README warns that it is not a hardened sandbox for untrusted code.

Workers is not Node.js. Code runs in V8 isolates with 128 MB of memory each. The runtime implements a subset of Node APIs, some only partially, and for others Wrangler adds polyfills whose methods throw when called, so some npm packages that assume a full Node process won’t work. Containers exist for code that needs a full runtime, at container prices.

Each product bills by its own unit, which makes costs hard to compare across a design. Workers charge per request and per CPU millisecond, with no charge for wall-clock time; Durable Objects charge for requests and for wall-clock GB-seconds while active; KV per key read or written; D1 per row read and written; Queues per 64 KB operation, usually three per message; R2 for storage and two classes of operations, with no egress fees. Containers, unlike R2 and Queues, do charge for egress: $0.025 per GB in North America and Europe after 1 TB a month.