The End of Containers for AI Sandboxing? Cloudflare Just Made It 100x Faster.

How Dynamic Workers use V8 isolates to give AI agents a secure, disposable execution environment — without the bloat.

We’ve been building AI agents wrong.

Not the models themselves — those are getting better every quarter. The problem is what happens after the model thinks. When an agent needs to actually do something — execute code, call an API, transform data — we’ve been reaching for the same clunky tool we’ve used for a decade: containers.

And for a while, that was fine. But the era of consumer-scale agents is here, where every end user has an agent (or several), and every agent writes code on the fly. At that scale, spinning up a 200MB container that takes 500 milliseconds to boot for a single code snippet starts to look absurd.

Cloudflare just launched a radically different approach. Their answer? Dynamic Workers — lightweight V8 isolates that start in milliseconds, cost megabytes instead of hundreds of megabytes, and can be created and destroyed per-request without blinking.

Let’s unpack why this matters.

The Problem: Agents Need to Run Code, and Code Needs a Cage

Here’s the fundamental tension in AI agent design.

When you ask an agent to “summarize my last 50 emails and draft a report,” the agent doesn’t just think about it. It needs to execute. It writes a script that hits your email API, filters results, formats output. That script has to run somewhere.

You absolutely cannot eval() AI-generated code inside your application. A cleverly crafted prompt could trick the model into injecting malicious code, exfiltrating data, or wreaking havoc on your backend. The agent's code needs a sandbox — an isolated environment with no access to anything it shouldn't touch.

For most of the industry, that sandbox has been a Linux container. Docker, microVMs, Firecracker — these are all variations of the same idea: spin up a little virtual machine, run the code inside, tear it down.

The problem is that containers were designed for long-running services, not throwaway code snippets. They carry enormous overhead for what agents actually need.

The Container Tax

Let’s put numbers on it.

A typical container takes hundreds of milliseconds to cold-start. It consumes hundreds of megabytes of memory. To avoid latency, you need to keep containers warm, which means paying for idle compute. And if you’re tempted to reuse a warm container across multiple tasks to save costs, you’ve just compromised your security model.

Now multiply that by the scale of consumer AI. If you have a million users, each running an agent that executes a dozen code snippets per session, you’re looking at millions of container boots per hour. The infrastructure costs alone are staggering, and the latency makes the experience feel sluggish.

Container-based sandbox providers know this. That’s why they impose limits on concurrent sandboxes and creation rates. The technology simply doesn’t scale linearly for this use case.

Enter V8 Isolates: The Lightweight Alternative

Cloudflare’s Dynamic Worker Loader takes a fundamentally different path. Instead of containers, it uses V8 isolates — the same JavaScript execution engine that powers Google Chrome and has powered Cloudflare Workers for eight years.

An isolate is not a virtual machine. It doesn’t need its own operating system, filesystem, or network stack. It’s a sandboxed instance of the V8 engine — a bubble where JavaScript runs with no ability to reach outside its boundaries unless you explicitly grant access.

The numbers tell the story:

That’s not a 2x improvement. That’s a 100x improvement in startup time and a 10–100x improvement in memory efficiency.

The implication is profound: you can spin up a fresh isolate for every single user request, run one snippet of AI-generated code, and throw it away — with no warm pools, no reuse, no compromise on security isolation.

How It Works in Practice

Cloudflare’s API is refreshingly simple. From within any Cloudflare Worker, you can dynamically load a new Worker with code specified at runtime:

You define the code your AI generated, specify which APIs the sandbox can access (via typed RPC stubs), optionally block all internet access, and call the sandbox’s exported functions. That’s it. The sandbox runs in its own isolate, fully separated from your application.

The key design decisions are worth noting:

First, the sandbox gets only what you give it. You pass in specific API bindings through the env object. The agent code can call those APIs, but nothing else. You can block all outbound network access entirely with globalOutbound: null, or intercept and filter every HTTP request the sandbox makes.

Second, credential injection is built-in. When the agent’s code makes an HTTP request, your harness can intercept it and add authentication headers on the way out. The agent never sees the secret credentials, so it can’t leak them.

Third, everything happens locally. The dynamic worker runs on the same machine — often the same thread — as the parent Worker. There’s no cross-region hop to find a warm sandbox. This works in every one of Cloudflare’s hundreds of edge locations worldwide.

The TypeScript Advantage: Fewer Tokens, Smarter Agents

Here’s where things get interesting from an AI perspective.

When an agent needs to interact with external services, it needs to understand the API. Traditionally, APIs are described using OpenAPI specs — verbose YAML documents that can run hundreds of lines for even simple interfaces.

Cloudflare argues that for AI-generated code, TypeScript interfaces are the right answer. And the token economics are compelling.

Consider a simple chat room API. A TypeScript interface describes it in about 15 lines: a few method signatures, a type definition, and you’re done. The equivalent OpenAPI spec? Over 70 lines of YAML boilerplate — operation IDs, parameter schemas, response definitions, component references.

For an LLM working within a context window, this difference is enormous. Fewer tokens for the API description means more room for reasoning, more room for the actual task, and lower inference costs. Cloudflare demonstrated that converting an MCP server into a TypeScript API cut token usage by 81%.

But it’s not just about token count. TypeScript interfaces are semantically richer for code generation. When an agent sees a method signature like getHistory(limit: number): Promise<Message[]>, it knows exactly what to write. No need to construct HTTP requests, set headers, parse response bodies, or handle status codes. It just calls the function.

The Workers runtime handles the complexity behind the scenes using Cap’n Web RPC to bridge between the sandbox and the host. From the agent’s perspective, it’s calling a local library. From a security perspective, every call crosses an isolate boundary.

Code Mode: The Bigger Picture

Dynamic Workers are a piece of a larger thesis Cloudflare has been building since September 2025: Code Mode.

The idea is simple but counterintuitive. Instead of having AI agents make tool calls one at a time — call tool A, wait for result, feed it back to the model, call tool B, wait, repeat — you have the agent write a program that chains multiple API calls together, execute it in a sandbox, and return only the final result.

This matters for three reasons.

Latency drops dramatically. Instead of multiple round-trips between the model and tool servers, you have one: generate code, execute, return. The intermediate steps happen at JavaScript speed inside the sandbox.

Token usage plummets. In the traditional tool-call loop, every intermediate result gets fed back into the context window, consuming tokens and potentially confusing the model. With Code Mode, only the final output enters the conversation. Cloudflare’s own MCP server demonstrates this — it exposes the entire Cloudflare API through just two tools (search and execute) in under 1,000 tokens.

Results get better. When the agent writes a coherent program, it can handle conditional logic, error handling, and data transformation in ways that sequential tool calls simply can’t express. The agent can filter, map, reduce, and branch — it’s programming, not just calling functions.

The JavaScript Trade-off (That Isn’t Really a Trade-off)

There’s one obvious limitation: V8 isolates run JavaScript. If your agent needs to execute Python, Rust, or anything else, you still need a container.

But Cloudflare makes a compelling argument for why this barely matters.

We’re not writing code for humans here. We’re writing code for AI. LLMs are fluent in every major programming language, and their JavaScript training data is immense. JavaScript, by its very nature on the web, was designed to be sandboxed. It’s the correct language for isolated code execution.

Workers do technically support Python (via Pyodide) and WebAssembly, but for the kind of small, on-demand code snippets that agents generate, JavaScript loads and runs faster than anything else in the isolate environment.

The pragmatic reality is: if your agent can do the job in JavaScript — and for most API orchestration, data transformation, and business logic tasks, it absolutely can — then containers are unnecessary overhead.

Security: Eight Years of Battle-Hardening

Isolate-based sandboxing isn’t without risk. V8 has a more complex attack surface than hardware virtual machines, and security bugs in V8 appear more frequently than in traditional hypervisors.

Cloudflare addresses this head-on. Their platform has been running untrusted code in isolates since 2017, and they’ve built multiple layers of defense:

Rapid patching. V8 security patches hit Cloudflare’s production faster than they hit Chrome itself — within hours of release.

Second-layer sandboxing. Beyond the V8 isolate, there’s a custom secondary sandbox with dynamic risk-based isolation. If a workload looks suspicious, it gets additional containment automatically.

Hardware-level protections. They’ve extended the V8 sandbox to use Intel Memory Protection Keys (MPK), adding a hardware barrier that’s independent of software bugs.

Spectre mitigations. Cloudflare has partnered with academic researchers to develop novel defenses against speculative execution attacks, one of the trickiest threats to isolate security.

Automated scanning. Code is analyzed for malicious patterns before execution, with automatic blocking or escalated sandboxing.

None of this guarantees perfect security — nothing does. But it’s a defense-in-depth model with nearly a decade of real-world adversarial testing behind it.

Real-World Usage

Dynamic Workers aren’t theoretical. Companies are already building on them.

Zite, for example, is building an app platform where users create CRUD applications, connect to Stripe, Airtable, and Google Calendar — all through a chat interface. The LLM writes TypeScript behind the scenes, and every automation runs in its own Dynamic Worker. According to their CTO, Zite processes millions of execution requests daily using this architecture.

Other developers are using Dynamic Workers to build platforms that generate full applications from AI, spinning up each app on demand and putting it back into cold storage until it’s needed again. The fast startup times make iterative development feel instant.

Pricing and Availability

Dynamic Workers are in open beta, available to all paid Cloudflare Workers users today.

The pricing model is straightforward: $0.002 per unique Worker loaded per day, plus standard CPU time and invocation costs. For one-off AI code execution, that’s $0.002 per sandbox — typically negligible compared to inference costs. During the beta, even that charge is waived.

Cloudflare also ships several helper libraries to smooth the developer experience:

• @cloudflare/codemode — wraps the sandbox lifecycle and integrates with MCP servers
• @cloudflare/worker-bundler — handles npm dependency resolution and bundling at runtime
• @cloudflare/shell — provides a virtual filesystem with persistent storage inside the sandbox

What This Means for the Industry

Cloudflare’s bet is that the future of AI agents is code generation, not tool calls. And if agents are going to write and execute code at consumer scale, the infrastructure needs to be orders of magnitude lighter than what containers offer.

Dynamic Workers aren’t the only player in this space — Deno, Val Town, and others are exploring similar lightweight execution models. But Cloudflare’s combination of global edge presence, battle-tested security, and deep V8 expertise makes this a particularly credible offering.

The broader takeaway is this: the bottleneck for AI agents is shifting from model intelligence to execution infrastructure. The models can already write solid code. The question is whether we can run that code fast enough, cheaply enough, and safely enough to make agents feel instantaneous at scale.

With isolates over containers, Cloudflare is arguing the answer is yes — and the numbers are hard to argue with.

If you’re building AI agents that execute code, Dynamic Workers are worth evaluating. The documentation is at developers.cloudflare.com/dynamic-workers, and there’s a one-click deploy starter on GitHub.

Thanks for reading. Follow for more on AI infrastructure, developer tools, and the systems behind modern AI agents.