Cloudflare's Dynamic Workers Promise Speed. At

Cloudflare claims its new Dynamic Workers can spawn a million sandboxes per second. That's the kind of number that makes you check if someone added extra zeros by mistake. They didn't.

Dynamic Workers represent Cloudflare's latest attempt to solve a problem that's been around since the first time someone needed to run untrusted code: how do you execute it safely, quickly, and cheaply? The traditional answer has been containers—Linux boxes that spin up, do their work, and shut down. They work. They're also relatively slow and memory-hungry, which matters when you're trying to run thousands of them simultaneously.

Cloudflare's approach trades the flexibility of full containers for speed. Dynamic Workers run on V8 isolates, the same technology that powers Chrome's tabs. Each isolate is a separate execution environment that shares the same JavaScript engine. The result, according to Cloudflare, is something "100 times faster and more memory efficient than a traditional container."

The Better Stack team tested this claim by building a system that programmatically spawns workers—essentially sandboxes that create other sandboxes. Their setup uses a "loader" binding that allows a parent worker to create and control child workers. Each child runs its own code, maintains its own state, and can be reused or discarded as needed.

The demonstration starts simple: a worker that responds with "hello world from the sandbox." But the architecture allows for considerably more complex operations. They showed workers with custom bindings, npm dependencies like Hono bundled in, and even the ability to intercept outbound requests for credential injection.

The AI Angle

The real use case Cloudflare seems to be targeting is AI /article/cloudflare-just-ai-cloned-nextjs-and-open-source-is-shook-generated code execution. This makes sense given the trajectory of tools like Cursor, Replit Agent, and various coding assistants that need to run code snippets safely before presenting results to users.

The Better Stack demonstration adapted code from the E2B cookbook—E2B being an existing sandbox solution—to run on Dynamic Workers instead. The test involved using Anthropic's Claude Sonnet to calculate pi using the Monte Carlo method and generate a visualization.

Here's where the constraints become visible. E2B's version runs in a Jupyter notebook with full filesystem access. It can create images, save them locally, and hand them back to the user. Dynamic Workers can't do this. They have no filesystem.

The workaround involves Cloudflare's R2 storage service—their answer to Amazon S3. The worker generates an SVG visualization and saves it to R2 instead of a local filesystem. It works, but it's a reminder that "100 times faster" comes with tradeoffs.

The JavaScript-Only Problem

Dynamic Workers only execute JavaScript. This is both their strength and their limitation. The V8 engine is extraordinarily good at running JavaScript quickly. It's not good at running Python, Ruby, Go, or any of the other languages developers actually use.

Cloudflare offers a different product—Cloudflare Sandboxes—for scenarios requiring full OS containers. As the video notes, these are "perfect if you want a full OS container with a file system and the ability to run almost any language and any binary." But they're not as fast. The architecture matters.

For AI code execution, this creates an interesting constraint. Most AI coding assistants today generate Python more readily than JavaScript. The ecosystem of data science, machine learning, and scientific computing libraries lives primarily in Python. Forcing everything through a JavaScript interface adds friction.

The demonstration shows this can work—Claude generated Python code that executed successfully within the JavaScript sandbox. But it's an additional translation layer that wouldn't exist with a more traditional container approach.

Scale Testing

The viral hook of "1 million workers per second" deserves scrutiny. The Better Stack team tested with 10,000 simultaneous workers, which they deployed to Cloudflare's infrastructure rather than running locally. The result: near-instantaneous creation of all 10,000 workers, each with its own ID, each capable of independent communication.

That's legitimately impressive. It's also not a million. Extrapolating from 10,000 to 1,000,000 assumes linear scaling, which distributed systems rarely provide. But even if the actual ceiling is lower, the demonstrated capability suggests Dynamic Workers can handle workloads that would be impractical with traditional containers.

The Free Tier Asterisk

There's a line in the video worth dwelling on: "While they're free now, they won't be free forever. So, even though you can run a million dynamic workers per second, you may want to hold off unless you have deep pockets."

This is standard practice for infrastructure companies. Offer generous free tiers during the launch phase, gather adoption and developer mindshare, then introduce pricing once the technology proves essential to enough workloads. It's not deceptive—it's just the model.

What matters is whether the eventual pricing makes sense for the use case. Running 10,000 concurrent sandboxes might be free today. What does it cost in six months? Cloudflare hasn't said, which means early adopters are building on pricing uncertainty.

Companies like Cloudflare (who already use this for their own Code Mode product) and Zite (for running LLM-generated apps) have presumably negotiated terms. Individual developers experimenting with AI agents may find themselves with an unexpected bill.

What This Actually Enables

Strip away the impressive numbers and the core capability is straightforward: programmatically creating isolated execution environments quickly enough that latency stops being a constraint.

This matters for development preview environments where you want each pull request to spin up its own sandbox automatically. It matters for multi-tenant applications where customer code needs isolation but can't justify dedicated containers. It matters for AI coding tools that need to run generated code without trusting it.

The JavaScript limitation constrains the applicability, but doesn't eliminate it. Many automation tasks, API interactions, and web-focused operations live comfortably within JavaScript's capabilities. The question is whether the 100x performance improvement justifies working within those constraints instead of reaching for a slower but more flexible container.

Dynamic Workers are already in production use. The technology works. The unanswered questions are about pricing, long-term scaling characteristics, and whether the JavaScript-only constraint proves more limiting than Cloudflare expects. History suggests the first two will follow predictable patterns. The third depends on what developers actually build.

—Bob Reynolds