SYSTEM Cited by 7 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.

Agent Development Lifecycle role (2026-08-04)

The ADLC article identifies Dynamic Workers as the execution substrate beneath Cloudflare's MCP Server in the Maintain and Retire stages. It therefore treats isolated, programmatic action execution as a lifecycle requirement alongside logs, traces, and analytics, rather than only an implementation-time sandbox. (Source: sources/2026-08-04-cloudflare-agent-development-lifecycle)

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 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:

• Compute: Dynamic Workers directly.
• Storage: Durable Object Facets.
• Durable execution: Dynamic Workflows (this section).
• Pre-announced: queues, caches, databases, object stores, AI bindings, MCP servers. See dynamic-binding-over-static-binding.

The CI/CD showcase (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

• sources/2026-05-19-cloudflare-announcing-claude-managed-agents-on-cloudflare — canonical wiki instance of Dynamic Workers as the V8-isolate tier in a per-agent sandbox-substrate choice. The launch post pairs Dynamic Workers + Codemode with Containers (microVM tier) as the two interchangeable backends an operator can pick per agent at setup time. Anthropic / Cloudflare framing: "What if your agent backend booted in a few milliseconds, and you didn't have to pay for the resources of a full VM when running the agent? The industry needs a lightweight primitive for sandboxing as we adopt agents at scale, and we're building just that." The isolate tier handles "bursts of tens of thousands of concurrent agents or more" — a scale envelope "no VM-based solution" matches in the post's framing. Trade-off pinned at concepts/micro-vm-isolation. The agent's hands run in a Dynamic Worker; the operator's outbound Worker proxy (patterns/agent-sandbox-with-gateway-only-egress) is the only outbound path because the isolate starts with globalOutbound: null. Fourth canonical application of Dynamic Workers' capability-sandbox posture (after agent code execution
• plugin hosting + workflow dispatch) — now as the Anthropic- brain-Cloudflare-hands isolate tier of systems/claude-managed-agents.
• sources/2026-04-15-cloudflare-project-think-building-the-next-generation-of-ai-agents — canonical wiki instance. Tier 1 of the Project Think execution ladder; the 100×-faster / 100×-more-memory-efficient-than-a- container claim; globalOutbound: null capability-model posture; substrate for Code Mode execution and self-authored extensions.
• sources/2026-09-28-cloudflare-emdash-10-the-stable-cms-with-a-secure-plugin-registry — EmDash 1.0 plugin hosting via the Worker Loader. On Cloudflare, EmDash 1.0 runs "each plugin as a Dynamic Worker through the Worker Loader" — the per-plugin-isolate deployment of the capability-sandbox posture, now paired with a portable fallback (workerd as a subprocess on Node.js) that uses "the same manifests and capability-gated APIs." Confirms Dynamic Workers as the isolate substrate for third-party CMS-plugin isolation at production 1.0.
• sources/2026-04-20-cloudflare-internal-ai-engineering-stack — referenced as one of the secure code-execution substrates Cloudflare's internal agents use.
• sources/2026-04-01-cloudflare-emdash-wordpress-spiritual-successor — plugin-hosting deployment. EmDash runs each CMS plugin as a Dynamic Worker with a capability manifest; canonical wiki instance of Dynamic Workers as a third-party-plugin runtime (vs. Project Think's LLM-generated-code runtime). Same capability-sandbox posture applied to a new surface: capability-manifest-plugin-isolation + per-request-isolate-per-plugin. Extends the Dynamic Workers use-case catalogue from "LLM agents" to "CMS extensions".
• sources/2026-05-01-cloudflare-introducing-dynamic-workflows-durable-execution-that-follows-the-tenant — dispatch substrate for Dynamic Workflows. Worker Loader loads each tenant's WorkflowEntrypoint class as a Dynamic Worker on each run(event, step) step boundary; isolate cache keyed by tenant ID; eviction + reload is invisible to the durable workflow. Third canonical application of Dynamic Workers' capability-sandbox posture (after agent code execution + plugin hosting) — now to durable per-tenant workflow dispatch. Canonicalises the Workers / Facets / Workflows dynamic-binding triple as a reusable platform-design pattern.

Related

• systems/cloudflare-workers — the long-lived-isolate parent tier Dynamic Workers descends from.
• systems/v8-javascript-engine — the isolate runtime.
• systems/project-think — the SDK that wires Dynamic Workers into Tier 1 of the execution ladder.
• systems/code-mode — consumption pattern whose execution substrate is Dynamic Workers.
• systems/cloudflare-sandbox-sdk — Tier 4 alternative when the workload requires full OS semantics.
• systems/cloudflare-containers — the container substrate under Sandbox SDK.
• concepts/capability-based-sandbox — the no-ambient-authority posture Dynamic Workers enforce.
• execution-ladder — the five-tier escalation this primitive sits inside.
• concepts/micro-vm-isolation — sibling isolation mechanism at the VM tier.
• code-generation-over-tool-calls — the pattern whose safe execution relies on Dynamic Workers' per-request-isolate property.
• capability-manifest-plugin-isolation — the composed primitive pattern EmDash uses; per-plugin Dynamic Worker + capability manifest.
• per-request-isolate-per-plugin — the Dynamic-Workers-specialised plugin-hosting pattern.
• systems/workerd — the open-source runtime that implements the Dynamic Workers isolate model.
• systems/emdash — CMS that hosts plugins as Dynamic Workers.
• capability-manifest — the declarative install-time contract Dynamic-Worker-hosted plugins use.
• systems/cloudflare-dynamic-workflows — the 2026-05-01 library that uses Dynamic Workers as its dispatch substrate for per-tenant durable workflows.
• systems/durable-object-facets — sibling dynamic-binding primitive applied to DO storage; Dynamic Workers is the compute instance, Facets is the storage instance, Dynamic Workflows is the durable-execution instance.
• per-tenant-dynamic-code-dispatch — the general three-layer dispatch shape Dynamic Workers implement at the compute layer.
• envelope-wrap-and-unwrap-metadata-routing — wire-format glue used by Dynamic Workflows to route replays back into the right per-tenant Dynamic Worker.
• dynamic-binding-over-static-binding — the generalising pattern Dynamic Workers anchors at the compute tier.
• ci-pipeline-as-customer-authored-durable-workflow — canonical CI showcase that uses Dynamic Workers as the per-step isolate substrate.
• companies/cloudflare — operator.

Cloudflare OS generated-app runtime (2026-08-05)

Cloudflare OS uses a Dynamic Worker as the server side of every agent-authored app. The app receives only explicitly granted resource bindings; its server runs with global outbound networking disabled, while browser code runs in a sandboxed frame. This is a fifth production role for Dynamic Workers: isolated full-stack app server, distinct from Code Mode execution, plugin hosting, workflow dispatch, and the Claude Managed Agents hands tier. The source does not state startup, concurrency, or resource-limit figures for this deployment. (Source: sources/2026-08-05-cloudflare-os-an-open-platform-for-agents-apps-and-work)