# Cloudflare Dynamic Workers [[Cloudflare]] Dynamic Workers let a [[Cloudflare Workers|Worker]] start other Workers at runtime, from code it passes in as strings, and run that code in a fresh V8 isolate. "Dynamic Workers" is the official product name. The API behind it is the **Worker Loader API**: a `worker_loaders` binding, usually exposed as `env.LOADER`. Older posts call the feature "Dynamic Worker Loader" or "Dynamic Worker Loading", and the old docs page under Workers bindings now redirects to the product's own docs section. It's the lowest-level way to get a Worker running on Cloudflare. Your code composes the Worker on the fly (modules, compatibility date, bindings, network access, limits, log sinks), and nothing gets deployed through the Cloudflare API. The main job is running code you didn't write and don't trust: a script an LLM produced a second ago, a user's plugin, a whole AI-generated app. ## Why It Matters Containers are the usual answer for sandboxing agent code, and they're heavy. They take hundreds of milliseconds to boot and hundreds of MB of memory, so people keep them warm and reuse them across tasks, which quietly weakens the isolation they were supposed to provide. An isolate starts in a few milliseconds and uses a few MB. Cloudflare's own figures: about 100x faster to start and 10 to 100x more memory efficient than a typical container. At that cost, you can create one sandbox per request, run one snippet and throw it away. That's what makes the [[Code Mode MCP Pattern]] practical at consumer scale. The model writes one script against a typed API instead of chaining a dozen tool calls, the script runs in a Dynamic Worker, and only the result goes back into the [[Context Window]]. Cloudflare claims up to 80% savings on inference tokens, and its own MCP server exposes the entire Cloudflare API through two tools (search and execute) in under 1,000 tokens. ## How It Works - **Binding**: add `worker_loaders: [{ binding: "LOADER" }]` to the [[Wrangler]] config. It doesn't point at any resource; it only gives access to the API - **`load(code)`**: creates a fresh Dynamic Worker for a one-off run, with no caching. This is the Code Mode case - **`get(id, callback)`**: caches by ID so the isolate can stay warm across requests. The callback only runs when no warm copy exists, and it must return identical code for a given ID (use `name:version` or a hash of the code). Warmth is never guaranteed: two requests on the same stub can land in different isolates - **`WorkerCode` object**: `compatibilityDate`, optional `compatibilityFlags`, `mainModule`, `modules`, `env`, `globalOutbound`, `tails` and `limits` - **Languages**: [[JavaScript]] (ES modules and CommonJS), [[Python]] (with the `python_workers` compatibility flag) and [[Web Assembly (WASM)|WebAssembly]]. There is no build step, so [[TypeScript]] and npm dependencies must be bundled first; `@cloudflare/worker-bundler` does it at runtime with esbuild. Cloudflare recommends JavaScript for one-off AI code because Python Workers are much slower to start - **Locality**: a one-off Dynamic Worker usually runs on the same machine (often the same thread) as the Worker that created it, in every Cloudflare location. No round trip to find a warm sandbox somewhere ## Security Model Isolation is capability-based: a Dynamic Worker can only touch what you explicitly hand it. - **Nothing inherited**: it doesn't get the parent Worker's bindings, credentials or data - **Network**: `globalOutbound: null` cuts it off completely (`fetch()` and `connect()` throw). Careful: if you omit the option, it inherits the parent's network access, which usually means the full Internet. You can also point `globalOutbound` at a gateway class in the loader Worker that inspects, rewrites, blocks or logs every outbound request - **Credential injection**: the gateway attaches the token on the way out, so the generated code never sees the secret and can't leak it - **Custom bindings**: you write a `WorkerEntrypoint` class in the loader Worker and pass a stub through `env`. Each call is an RPC back into your code over Cap'n Web. Stubs have no global identifier and can't be forged, and `ctx.props` lets one class serve many tenants with a per-tenant scope the sandbox never sees. Cloudflare compares this to Android's Binder and Chrome's Mojo - **Resource caps**: per-invocation `cpuMs` and `subRequests` limits; the Dynamic Worker throws as soon as it hits one - **Platform layers**: the V8 sandbox, a process-level sandbox around it, V8 security patches shipped to production within hours, hardware memory protection keys, Spectre mitigations and risk-based cordoning of tenants Cloudflare is upfront that isolates are a more complicated attack surface than hardware VMs, and that V8 security bugs are more common than hypervisor bugs. That's why all those extra layers exist. When you want a kernel boundary instead, [[Cloudflare Containers]] run in a [[Firecracker]] [[microVM]]. The sandbox also doesn't make [[Prompt injection]] go away. It limits what injected code can reach, so the API surface you expose is the actual security boundary. Keep it narrow. ## Building Blocks Added in 2026 - **Durable Object Facets** (beta, April 13): a supervisor [[Cloudflare Durable Objects|Durable Object]] loads AI-written code that `extends DurableObject` and runs it as a "facet" with its own SQLite database. The facet can't read the supervisor's database. `abort()` swaps code versions while keeping the data; `delete()` drops it - **Dynamic Workflows** (May 1): the `@cloudflare/dynamic-workflows` library runs a [[Cloudflare Workflows|Workflow]] inside a Dynamic Worker. Durable steps (`step.do()`, `step.sleep()`, `step.waitForEvent()`) survive the isolate being recycled, because the engine reloads the right code from metadata such as a tenant ID - **Static assets**: a generated full-stack app serves its HTML, JS and images from [[Cloudflare KV|KV]] or [[Cloudflare R2|R2]] through an asset binding you write (helpers in `@cloudflare/worker-bundler`) - **Observability**: logs are discarded by default. Attach Tail Workers through `tails` and write to Workers Logs - **Helper libraries**: `@cloudflare/codemode` (`DynamicWorkerExecutor`, plus `codeMcpServer` and `openApiMcpServer` to put Code Mode in front of an MCP server or an OpenAPI spec), `@cloudflare/worker-bundler`, and `@cloudflare/shell` (a virtual filesystem backed by SQLite and R2) ## Pricing and Limits - **Workers Paid plan only** - **Three billing dimensions**: unique Dynamic Workers created per day, requests and CPU time. The pricing page lists 1,000 unique Dynamic Workers included per month, then $0.002 per Dynamic Worker per day. Requests and CPU time use standard Workers rates and count toward your Workers usage (10 million requests and 30 million CPU ms included, then $0.30 per million requests and $0.02 per million CPU ms) - **What counts as one**: Worker ID plus code. Same ID and same code invoked a hundred times is one; `load()` or no ID is one per invocation. Anything reused should go through `get()` with a stable ID - **Creation fee**: waived at the open beta launch. The pricing page says it's billed since May 26, 2026. The count shows on the Workers overview page and in GraphQL (`distinctDynamicWorkerCount`) since June 11, with data back to June 1 - **For Code Mode**, that's $0.002 per execution plus CPU, which is noise next to the inference cost of generating the code - **Concurrency**: at most 4 distinct Dynamic Workers with in-flight requests per Worker request, and 10 per Durable Object (raised from 4 on August 28, 2026). CPU time and subrequests follow your Workers plan limits unless you set lower ones - **No global cap** on the number of sandboxes or the creation rate, according to Cloudflare, unlike many container sandbox providers ## How It Compares - **[[Cloudflare Workers]]**: regular Workers are deployed ahead of time through the API and run everywhere. Dynamic Workers are created by your own code at request time and never deployed - **Workers for Platforms**: $25/month, built for persistent multi-tenant code. You upload customer Workers into a dispatch namespace through the API, and a "dynamic dispatch Worker" routes requests to them, with custom domains, tags and per-customer limits. The naming is confusing: "dynamic dispatch" routes to Workers that are already deployed, while Dynamic Workers load code that never gets deployed. Use Workers for Platforms to host customer apps for the long term, and Dynamic Workers for ephemeral or generated code - **[[Cloudflare Sandbox SDK|Sandboxes]] and [[Cloudflare Containers|Containers]]**: the Sandboxes docs present Containers and Dynamic Workers as the two sandbox environments. A Container is a Linux microVM: any language, child processes, native binaries, package managers, `npm test`, about 650 ms median startup since the September 30, 2026 rework. A Dynamic Worker runs JavaScript, Python or Wasm that calls methods you provide, and starts in milliseconds. The docs' rule: a Container when the code expects Linux, a Dynamic Worker when it calls known methods. They combine well (answer questions about a repository through scoped methods in a Dynamic Worker, then run its test suite in a Container) - **`@cloudflare/computer`** (preview, August 3, 2026): an agent runtime that picks between an isolate backend (Dynamic Workers plus just-bash) and a container backend, over a shared SQLite-backed filesystem - **[[Cloudflare Agents SDK]]**: the SDK's Code Mode (`createCodemodeRuntime`, durable execution log, actions that pause for human approval and then resume) runs generated code in Dynamic Workers. Code Mode itself is still marked experimental in the docs ## Who Uses It - **Cloudflare's MCP server**: the whole Cloudflare API behind two tools - **Zite**: an app builder where the LLM writes TypeScript behind a chat UI; every automation runs in its own Dynamic Worker. Its CTO reported millions of execution requests per day at launch - **EmDash** (April 1, 2026): Cloudflare's TypeScript CMS, pitched as the successor to WordPress. Each plugin runs in a Dynamic Worker and can only use the capabilities declared in its manifest - **[[KiteSurf]]**: Cloudflare's agent-first browser gives every page its own isolate through Dynamic Workers, and uses them to gate network access - **MCP server portals**: Code Mode for portals (March 26, 2026), and admins can turn it on by default (July 30) ## Status (October 2026) - **September 26, 2025**: the Worker Loader API was announced alongside Code Mode. Closed beta in production, fully usable locally with Wrangler and the open source `workerd` runtime - **March 24, 2026**: open beta for all Workers Paid users, renamed Dynamic Workers, with its own docs section - **Still beta, as far as I can tell**: I found no general availability announcement or changelog entry up to October 4, 2026 ## Reactions - **Hacker News**: the launch thread ("Sandboxing AI agents, 100x faster", 52 points) was small but useful. Kenton Varda (Cloudflare) clarified two things: Dynamic Workers have no built-in filesystem, so you give them an RPC interface instead (for example, data loaded into a Durable Object's SQLite database next to them), and the agent loop runs in a regular Worker while only the generated code goes into the Dynamic Worker. In the same thread, someone's "safe" Python `eval` trick was broken twice within hours, which is a good reminder of why you don't sandbox with string filtering - **Recurring complaints**: Workers Paid is required (it came up again in August 2026 when a project needed Dynamic Workers to run on Cloudflare), and the model is JavaScript-first - **X**: when the Worker Loader API first shipped, Kenton Varda described it as a feature he had been working on for a while, with sandboxes "much lighter than containers" - **Press**: VentureBeat and InfoQ covered the open beta mostly through the "100x faster than containers" angle ## My Take The 100x startup number gets the headlines, but I think the capability model is the real story. Most sandboxes start with full network access and then try to filter it. Dynamic Workers start with nothing, and you add exactly the methods the code is allowed to call, with secrets staying on your side of the boundary. That's the right default for agent-generated code. If you build on it: always set `globalOutbound` explicitly (the default inherits the Internet), give the model a small TypeScript API rather than raw HTTP, and use `get()` with stable IDs for anything you call twice, or you'll pay the creation fee on every request. The trade-off is lock-in. Outside local development with `workerd`, this only runs on Cloudflare, and it's still a beta. ## References - Documentation: https://developers.cloudflare.com/dynamic-workers/ - Getting started: https://developers.cloudflare.com/dynamic-workers/getting-started/ - API reference (Worker Loader binding, `WorkerCode`): https://developers.cloudflare.com/dynamic-workers/api-reference/ - Bindings and capability-based sandboxing: https://developers.cloudflare.com/dynamic-workers/usage/bindings/ - Egress control: https://developers.cloudflare.com/dynamic-workers/usage/egress-control/ - Durable Object Facets: https://developers.cloudflare.com/dynamic-workers/usage/durable-object-facets/ - Dynamic Workflows: https://developers.cloudflare.com/dynamic-workers/usage/dynamic-workflows/ - Pricing: https://developers.cloudflare.com/dynamic-workers/pricing/ - Limits: https://developers.cloudflare.com/dynamic-workers/platform/limits/ - Custom resource limits: https://developers.cloudflare.com/dynamic-workers/usage/limits/ - Choose a sandbox environment (Containers vs Dynamic Workers): https://developers.cloudflare.com/sandbox/concepts/ - Workers for Platforms: https://developers.cloudflare.com/cloudflare-for-platforms/workers-for-platforms/ - Code Mode docs: https://developers.cloudflare.com/agents/tools/codemode/ - Blog, Code Mode and the Worker Loader API (2025-09-26): https://blog.cloudflare.com/code-mode/ - Blog, Sandboxing AI agents, 100x faster (2026-03-24): https://blog.cloudflare.com/dynamic-workers/ - Blog, Durable Objects in Dynamic Workers (2026-04-13): https://blog.cloudflare.com/durable-object-facets-dynamic-workers/ - Blog, Cloudflare Containers rebuilt to scale agent sandboxes (2026-09-30): https://blog.cloudflare.com/faster-agent-sandboxes/ - Changelog, @cloudflare/codemode rewrite with DynamicWorkerExecutor (2026-02-20): https://developers.cloudflare.com/changelog/post/2026-02-20-codemode-sdk-rewrite/ - Changelog, @cloudflare/codemode v0.2.1 (2026-03-17): https://developers.cloudflare.com/changelog/post/2026-03-17-codemode-sdk-v0.2.1/ - Changelog, Dynamic Workers open beta (2026-03-24): https://developers.cloudflare.com/changelog/post/2026-03-24-dynamic-workers-open-beta/ - Changelog, Dynamic Workflows (2026-05-01): https://developers.cloudflare.com/changelog/post/2026-05-01-dynamic-workflows/ - Changelog, Dynamic Workers usage count (2026-06-11): https://developers.cloudflare.com/changelog/post/2026-06-11-dynamic-workers-count/ - Changelog, @cloudflare/computer preview (2026-08-03): https://developers.cloudflare.com/changelog/post/2026-08-03-cloudflare-computer/ - Changelog, ten Dynamic Workers per Durable Object (2026-08-28): https://developers.cloudflare.com/changelog/post/2026-08-28-durable-objects-dynamic-workers-limit/ - Hacker News, launch thread: https://news.ycombinator.com/item?id=47502448 - Hacker News, Kenton Varda on capabilities: https://news.ycombinator.com/item?id=47556408 - X, Kenton Varda on Dynamic Worker Loading (2025-09-26): https://x.com/KentonVarda/status/1971564021846548963 - X, EmDash announcement (2026-04-01): https://x.com/CloudflareDev/status/2039375772159189336 - InfoQ, open beta coverage: https://www.infoq.com/news/2026/04/cloudflare-dynamic-workers-beta/ - VentureBeat, open beta coverage: https://venturebeat.com/infrastructure/cloudflares-new-dynamic-workers-ditch-containers-to-run-ai-agent-code-100x ## Related - [[Cloudflare]] - [[Cloudflare Workers]] - [[Cloudflare Durable Objects]] - [[Cloudflare Sandbox SDK]] - [[Cloudflare Containers]] - [[Cloudflare Agents SDK]] - [[Cloudflare Workflows]] - [[Cloudflare KV]] - [[Cloudflare R2]] - [[KiteSurf]] - [[Code Mode MCP Pattern]] - [[Model Context Protocol (MCP)]] - [[AI Agents]] - [[Vibe Coding]] - [[Prompt injection]] - [[Firecracker]] - [[microVM]] - [[Docker Sandboxes]] - [[Vercel Sandboxes]] - [[Wrangler]] - [[JavaScript]] - [[TypeScript]] - [[Python]] - [[Web Assembly (WASM)]]