Skip to content

SYSTEM Cited by 5 sources

Dynamic Workers

Dynamic Workers is Cloudflare's per-request isolate-spawning variant of Workers: a fresh V8 isolate minted at runtime, in milliseconds, with a few megabytes of memory, used once, and thrown away. Cloudflare's canonical substrate for running LLM-generated code safely. Introduced in the Dynamic Workers blog post and productised in the 2026-04-15 Project Think launch as Tier 1 of the execution ladder.

Properties

Dimension Container Dynamic Worker
Startup seconds milliseconds
Memory hundreds of MB min a few MB
Lifecycle managed by user one-shot per request
Ambient authority full network / FS by default globalOutbound: null; none

"That's roughly 100× faster and up to 100× more memory-efficient than a container. You can start a new one for every single request, run a snippet of code, and throw it away." (Source: Project Think.)

Capability model — no ambient authority

The load-bearing design choice:

"Dynamic Workers begin with almost no ambient authority (globalOutbound: null, no network access) and the developer grants capabilities explicitly, resource by resource, through bindings. We go from asking 'how do we stop this thing from doing too much?' to 'what exactly do we want this thing to be able to do?'"

This is concepts/capability-based-sandbox in a serverless isolate — capabilities are the default-deny baseline; the developer adds them resource by resource (a specific R2 bucket, a specific fetch origin, a specific DO namespace) rather than configuring a deny-list on a general-purpose machine.

Role in Project Think's execution ladder

Dynamic Workers occupy Tier 1 of Project Think's five-tier execution ladder:

Tier Capability Substrate
0 Durable virtual filesystem DO SQLite + R2
1 LLM-generated JavaScript, no network Dynamic Workers
2 + npm at runtime Dynamic Workers + @cloudflare/worker-bundler
3 + headless browser Dynamic Workers + Browser Rendering
4 + full OS sandbox Cloudflare Sandbox

Tiers 2 and 3 are still Dynamic Workers with additional capabilities granted — an npm binding and a Browser Rendering binding, respectively. Tier 4 transitions to the container-based Sandbox for full toolchains (git, cargo, test runners).

Role in Code Mode

systems/code-mode is the consumption-side pattern; Dynamic Workers are the execution-side substrate. When a model writes TypeScript against a typed MCP API, the code is dispatched to a Dynamic Worker for execution — one isolate per code-run, discarded after returning the result. Cloudflare's API MCP server demonstrates this at scale: two tools (search() / execute()) covering ~3,000 operations in ~1,000 tokens vs ~1.17M for the naive schema-per-endpoint baseline (99.9% reduction).

Role in self-authored extensions

When a Project Think agent writes its own tool at runtime, the generated TypeScript runs in a Dynamic Worker bundled by @cloudflare/worker-bundler. The extension manifest declares permissions ({network: ["api.github.com"], workspace: "read-write"}) — the Dynamic Worker's capability-model posture is what makes the manifest enforceable rather than advisory. See concepts/self-authored-extension.

Contrast with Cloudflare Containers / Sandbox SDK

  • Workers: long-lived isolate per script; the Worker's lifetime spans many requests; warm- isolate routing.
  • Dynamic Workers: one isolate per run; torn down after.
  • Containers + Sandbox SDK: full Linux container lifecycle with filesystem + long-running processes + full toolchains.

The three compose: Think's Tier 0 filesystem uses DO+R2; Tiers 1-3 use Dynamic Workers; Tier 4 uses Sandbox containers — the agent escalates only as needed.

Relationship to Facets

Facets is Cloudflare's primitive for child DOs that can host Dynamic Workers; Project Think's sub-agent abstraction is built on top (each sub-agent is a co-located child DO with its own SQLite and a function-call-latency RPC surface). Facets is the hybrid — DO + Dynamic Worker — that makes "agent writes + runs its own tool" one substrate move rather than two orchestrations.

Role as dispatch substrate for Dynamic Workflows (2026-05-01)

@cloudflare/dynamic-workflows uses Dynamic Workers as its dispatch substrate — the Worker Loader loads each tenant's WorkflowEntrypoint class as a Dynamic Worker, and when the Workflows engine wakes the workflow seconds / hours / days later, the Worker Loader re-loads the tenant's code into a Dynamic Worker to run the next step.

The economics are load-bearing: "A Dynamic Worker boots in single-digit milliseconds using a few megabytes of memory, so the dispatch overhead is essentially free. You can have a million tenants, each with their own distinct workflow code, each spun up lazily on the step boundary where it's needed, and none of them cost anything while idle." (Source: Dynamic Workflows.)

Dynamic Workflows' three-layer topology:

Workflows engine (platform)
        ↕
Worker Loader (dispatcher; Dynamic Worker container)
        ↕
Tenant code (per-tenant Dynamic Worker)

Canonicalises Dynamic Workers as the execution substrate for the third instance of Cloudflare's dynamic-binding pattern — alongside:

The CI/CD showcase (patterns/ci-pipeline-as-customer-authored-durable-workflow) is the canonical end-to-end realisation: per-repo CIPipeline extends WorkflowEntrypoint class, dispatched as a Dynamic Worker per step, durable via Dynamic Workflows, with heavy corners escalated to Sandbox SDK and checkout via Artifacts + ArtifactFS.

Seen in

Last updated · 542 distilled / 1,571 read