Home
AI
Blog

Dynamic Workers CF: Run Untrusted Code Fast (Without Containers)

basanta sapkota

A sandbox that wakes up in a few milliseconds and barely sips memory sounds like a fairy tale if you’ve spent your life staring at container cold starts. I’ve been there. You deploy, you wait, you tweak warm pools, you wait again… and you start wondering if your “isolated execution” plan is secretly just “make everyone wait forever.”

That’s basically the pitch behind dynamic workers cf. You can spin up Workers at runtime and run code you don’t fully trust, without hauling out a fresh Linux container for every tiny job.

Building AI agents? Letting users upload little scripts? Anything where random logic shows up at runtime? Dynamic Workers is Cloudflare’s answer to the classic “I need isolation, and I need it yesterday” problem.

Key Takeaways

  • dynamic workers cf also called Dynamic Workers or the Dynamic Worker Loader lets a host Worker instantiate new Workers at runtime using code provided as strings or modules.
  • It runs on V8 isolates, the same foundation as Cloudflare Workers. Cloudflare says startup can be about 100× faster and 10× to 100× more memory efficient than typical containers.
  • You decide what the sandbox can touch. Bindings, network egress, and observability such as logs and Tail Workers can be configured per dynamic Worker.
  • Two main ways to run code. Use load() for one-shot execution.Yet get to reuse a warm isolate across requests.
  • Paid plan pricing includes 1,000 unique Dynamic Workers per month, then usage-based pricing like $0.30 per million requests and $0.02 per million CPU ms, plus $0.002 per unique worker per day. Cloudflare community notes say the per-day line item is not yet billed during beta.

What is dynamic workers cf?

Cloudflare describes Dynamic Workers as a way to “spin up an unlimited number of Workers to execute arbitrary code specified at runtime” in a secure, sandboxed environment.

Plain English version. Your normal Worker becomes the host. Then it can create child Workers on demand, using code that did not exist when you deployed.

Source
https://developers.cloudflare.com/dynamic-workers/

Under the hood, nothing magical changed. It’s still the Workers model. Isolates, not VMs, not containers. That’s the whole trick.

Cloudflare says an isolate can start in a few milliseconds and use a few megabytes of memory, which is why they claim about 100× faster startup and 10× to 100× better memory efficiency than a typical container.

Source
https://blog.cloudflare.com/dynamic-workers/

dynamic workers cf vs containers: why isolates change the math

Containers are fine… until you need a brand-new sandbox per request, or per user, or per agent run. Then you start paying for the boring stuff:

  • boot time, often hundreds of milliseconds
  • memory overhead, often hundreds of MB
  • orchestration headaches like warm pools, eviction, noisy neighbors and the rest of the circus

Dynamic workers cf flips the pain. Isolates are cheap, so you can create sandboxes on demand, toss them when you’re done, and not feel like you’re burning money every time someone runs a 20-line script. For AI-generated code, that disposable vibe is exactly what you want.

Why dynamic workers cf matters for AI agents and “Code Mode”

Cloudflare’s stance is refreshingly blunt. Don’t eval() AI-generated code inside your app. Prompt injection is real. Even “well-behaved” code can do something dumb at 2 a.m. You want hard boundaries.

Dynamic workers cf fits nicely with Cloudflare’s “Code Mode” idea. Instead of an agent chewing through tokens with endless tool calls, you give it a small API surface. Then you let it write code that calls that API.

Cloudflare has published that converting an MCP server to a TypeScript API cut token usage by 81% in their experiments. Their docs also talk about savings of up to around 80% by letting code process data instead of pushing everything through the model.

Sources
https://blog.cloudflare.com/dynamic-workers/
https://developers.cloudflare.com/dynamic-workers/

What this looks like in real life:

  • define a tight RPC API, basically the agent’s allowed moves
  • run agent-written logic in a dynamic Worker
  • block outbound network by default, or intercept it if you need to allow a little
  • log everything, because you’ll want receipts later

How to use dynamic workers cf: Worker Loader basics

To create dynamic Workers, your host Worker needs a Worker Loader binding. In wrangler.jsonc or TOML, you’ll use worker_loaders.

{
  "name". "dynamic-host",
  "main". "src/index.js",
  "compatibility_date". "2026-03-01",
  "worker_loaders": [
    { "binding": "LOADER" }
  ]
}

Then inside your host Worker, you create a sandbox with env.LOADER.load() and forward a request into it.

Example: load() a one-shot sandbox and block the Internet

export default {
  async fetch {
    const worker = env.LOADER.load {
              return new Response.
            }
          }.
        `,
      },
      // No outbound network access from the dynamic Worker. GlobalOutbound: null,
    }). Const entrypoint = worker.getEntrypoint(). Return entrypoint.fetch;
  },
}.

This is straight out of Cloudflare’s Getting started docs.

Source
https://developers.cloudflare.com/dynamic-workers/getting-started/

When to use get(id, ...) for warm reuse

If you’re going to run the same code repeatedly, reuse is your friend. Say user project abc123 gets hit all day long. You probably don’t want to rebuild the world each request.

const worker = env.LOADER.get("project-abc123", async () => {
  const code = await env.MY_CODE_STORAGE.get("project-abc123"). Return {
    compatibilityDate. "2026-03-01",
    mainModule. "index.js",
    modules. { "index.js": code },
    globalOutbound: null,
  };
});

Cloudflare describes it like this:

  • load() gives you a fresh Worker and is great for one-time execution. It effectively behaves like no ID was provided.
  • get(id, callback) reuses a cached isolate if it’s still warm. The callback only runs when the system needs to load it.

Source
https://developers.cloudflare.com/dynamic-workers/getting-started/

Security controls: bindings, network, logs

The security story here isn’t “just trust us.” It’s “you choose the capabilities.” Big difference.

With dynamic workers cf you can do a few core things:

Limit bindings. Only pass the APIs or data the sandbox actually needs using env: { ... }.

Clamp network access. Set globalOutbound: null to block outbound requests, or intercept and selectively allow. This is a big deal for stopping data exfil.

Add observability. Cloudflare calls out attaching Tail Workers and capturing logs per run.

Source
https://developers.cloudflare.com/dynamic-workers/

If you’ve ever had to untangle an “agent went rogue” mess, you already know why egress rules plus logs are non-negotiable.

Pricing and limits: what you’ll actually pay

Dynamic Workers are only available on the Workers Paid plan.

Sources
https://developers.cloudflare.com/dynamic-workers/pricing/
https://developers.cloudflare.com/workers/platform/pricing/

Pricing breaks down into three chunks:

Unique Dynamic Workers created. It includes 1,000 unique per month, then $0.002 per Dynamic Worker per day.

Requests. $0.30 per million requests, the Workers Standard rate.

CPU time. It includes 30 million CPU ms per month, then $0.02 per million CPU ms.

Two details worth keeping in mind.

First, Dynamic Workers bill CPU for startup time plus execution time. Startup includes isolate init and parsing your code.
Source: https://developers.cloudflare.com/dynamic-workers/pricing/

Second, Cloudflare’s community announcement says the “created daily” charge is not yet active during beta, and they shared it so you can estimate future costs.
Source: https://community.cloudflare.com/t/workers-dynamic-workers-now-in-open-beta/910188

And yeah, the usual Workers limits still apply. CPU time is bounded. Paid can go up to 5 minutes per request. Memory has a ceiling per isolate, commonly 128 MB.
Source: https://developers.cloudflare.com/workers/platform/limits/

Where dynamic workers cf fits in real projects

If I were building “users write automation scripts” or “an agent generates a data transform,” I’d set it up something like this:

  1. The host Worker authenticates the user.
  2. The host Worker compiles or bundles code if needed. Cloudflare suggests @cloudflare/worker-bundler for npm and TypeScript workflows.
  3. The host Worker runs the code in a dynamic Worker with outbound locked down using globalOutbound: null, and only the bindings it truly needs.
  4. Timeouts, quotas, and logs on every run. No exceptions. Future you will be grateful.

If you’re already thinking about agentic coding, you might also like this internal read: Top 10 agentic coding tools in 2026 (dev).

Wrap-up

Dynamic workers cf is basically Workers that can create more Workers. But the real win is practical: fast, disposable sandboxes for untrusted or AI-generated code, without dragging containers into every request.

Use load() for one-offs.Now get(id) when you want warm reuse. Keep bindings stingy. Treat outbound network like a loaded weapon.

And if you try this in an agent workflow, I’m genuinely curious what bites first. Bundling pain? Pricing surprises? Or the moment you realize your “tiny API surface” is actually a barn door.

Sources

  • Cloudflare Docs . Dynamic Workers overview. Https.//developers.cloudflare.com/dynamic-workers/
  • Cloudflare Docs , Getting started, loader binding, load/get examples. Https.//developers.cloudflare.com/dynamic-workers/getting-started/
  • Cloudflare Docs . Dynamic Workers pricing. Https.//developers.cloudflare.com/dynamic-workers/pricing/
  • Cloudflare Blog , “Sandboxing AI agents, 100x faster” performance claims and Code Mode token reduction. Https.//blog.cloudflare.com/dynamic-workers/
  • Cloudflare Community — Open beta announcement and pricing note. Https.//community.cloudflare.com/t/workers-dynamic-workers-now-in-open-beta/910188
  • Cloudflare Docs — Workers pricing context. Https.//developers.cloudflare.com/workers/platform/pricing/
  • Cloudflare Docs — Workers limits. Https.//developers.cloudflare.com/workers/platform/limits/
  • InfoWorld — Coverage and enterprise angle: https://www.infoworld.com/article/4149869/cloudflare-launches-dynamic-workers-for-ai-agent-execution.html

Post a Comment