The Sandbox War: Cloudflare and Vercel Both Solved the Same Infrastructure Blind Spot

Here's a sentence that would have been unthinkable a year ago: on June 24, 2025, Cloudflare launched its Containers public beta alongside a new Sandbox library for running untrusted code. On June 25, 2025, Vercel shipped its own Sandbox SDK . Two platforms. Same unsolved problem. Two approaches that reveal genuine architectural and philosophical differences.

If you're building anything that accepts AI-generated code, user uploads, or third-party scripts, this is the most consequential infrastructure debate of the past year. I've dug deep into both offerings, and here's what I found.

The Problem That Finally Got a Solution

For the past two years, a question has been obvious and uncomfortable: where does AI-generated code actually run? LLMs can write Python scripts, bash one-liners, and full Node.js applications, but the moment you execute that output in production you face a hard wall. Traditional sandboxing is either too weak (shared kernel isolation), too slow (full VMs), or absent from serverless platforms entirely.

Both Cloudflare and Vercel identified this as the same bottleneck — and their announcements make the target clear. Cloudflare's blog post frames Sandboxes around AI-generated and user-submitted code. Vercel's changelog explicitly calls out "code generated by AI agents" as the primary use case. Simon Willison connected both launches within hours, noting the convergence was hard to ignore.

But the similarity ends at the use case.

Cloudflare Containers + Sandbox: Container-Native, Edge-First

Cloudflare's approach is built on top of its new Containers infrastructure, which launched the same day. You define a container in your wrangler.jsonc — either pointing to a Dockerfile or an image URL — and deploy it alongside your Worker. The newly released Cloudflare sandbox npm package gives you an API that looks like this:

import { getSandbox } from "@cloudflare/sandbox";

const sandbox = getSandbox(env.Sandbox, "my-sandbox");
const result = await sandbox.exec("python3", ["-c", "print(2 + 2)"]);

Each sandbox is a container — not a full VM. Cloudflare's Sandbox changelog describes them as "secure, container-based environments" sharing a host kernel but isolated via kernel namespaces and cgroups. This is Docker-level isolation, not VM-level isolation.

The advantages are real. Start-up times are fast — measured in seconds, not milliseconds — because Cloudflare pre-provisions containers across its global network and routes requests to the nearest available instance. You can set sleepAfter: '5m' to let the container scale to zero between requests. Pricing is transparent and granular: $0.0000025 per GiB-second for memory, $0.000020 per vCPU-second, with three instance tiers from dev (256 MiB) to standard (4 GiB).

The Sandbox SDK adds features like file operations, git checkout, and a clever tunnels feature that gives you zero-config *.trycloudflare.com URLs via sandbox.tunnels.get(port). You can expose a service running inside a sandbox without any DNS setup — cloudflared opens a QUIC connection and Cloudflare hands back a hostname.

Vercel Sandbox: MicroVM Isolation with Firecracker

Vercel took a different bet. Each sandbox runs in its own Firecracker microVM — a lightweight virtual machine with a dedicated kernel. The Vercel Sandbox docs are explicit: "Unlike Docker containers, each sandbox runs in its own Firecracker microVM with a dedicated kernel."

The API surface is similar in spirit but different in shape:

import { Sandbox } from "@vercel/sandbox";

const sandbox = await Sandbox.create();
await sandbox.writeFiles([
  { path: "script.js", stream: Buffer.from(code) },
]);
await sandbox.runCommand({
  cmd: "node",
  args: ["script.js"],
  stdout: process.stdout,
});

But the execution model is different. Vercel sandboxes are persistent by default — the filesystem is automatically snapshotted on stop and restored on resume. You get full sudo access. The default base image is Amazon Linux 2023 with multiple Node and Python runtimes pre-installed ( node26, node24, node22, python3.13 ). Maximum execution time is 45 minutes.

Vercel charges based on Active CPU time through its Fluid compute model, meaning you pay only when code is actually consuming CPU — I/O wait and network latency are free.

Containers vs. MicroVMs: The Real Trade-Off

Let me be direct about what each approach gives up.

Cloudflare's container model is weaker on isolation — container escapes are a documented attack surface. For truly untrusted third-party code in a multi-tenant environment, Vercel's microVM boundary is stronger. A kernel exploit in one sandbox doesn't compromise the host.

Vercel's model is weaker on distribution. Each sandbox provisions in a single region (iad1 currently). If your user is in Sydney, their sandbox boot happens in Virginia. Cloudflare's containers spin up at the edge, close to the user.

Cloudflare wins on operational simplicity. The sandbox is just another binding in your wrangler.jsonc. Adding a container alongside Workers is a configuration change, not an architectural decision.

Vercel wins on portability. The Sandbox SDK is standalone — it runs from any environment, including non-Vercel platforms. Call Sandbox.create() from an AWS Lambda function, a local script, or a CI pipeline. It's sandbox as a primitive, not a feature.

The Third Signal: Temporary Accounts for AI Agents

On June 19, 2026: Cloudflare released Temporary Accounts for AI Agents . This lets any agent run wrangler deploy --temporary and get a live Worker in seconds, no sign-up required. The deployment stays live for 60 minutes and can be claimed by a human.

This completes a picture that started a year ago. Cloudflare isn't just giving you a place to run untrusted code — it's giving AI agents a frictionless path from code generation to live deployment. Sid Chatterjee put it plainly: "The moment an agent needs to deploy something, it slams face-first into a wall built for humans." Temporary Accounts removes that wall.

What This Signals About Infrastructure

Two platforms shipping competing sandboxes within 48 hours was no coincidence. It was the industry admitting that the serverless function was never the right primitive for untrusted code. Workers and Vercel Functions are optimized for trusted code paths — shared resources, ambient access to environment variables and platform APIs, designed for low-latency request/response cycles.

AI-generated code needs something different:

• Stronger isolation (it might try to read your environment variables)
• Longer execution (agents don't finish in 10 seconds)
• Ephemeral filesystems (the code itself is disposable)
• Programmatic creation (no dashboard clicks, no API key setup)

Both recognized that sandboxing is a new compute primitive, not an add-on. The platform that wins the "safe execution" war will own the next generation of AI-augmented applications.

The Takeaway

The choice depends on what you're optimizing for:

• Maximum security? Vercel's microVM model raises the bar. The dedicated kernel is the right call for AI code interpreters or plugin systems.
• Global scale with low latency? Cloudflare's edge-native containers are unmatched. Per-user sandboxes shouldn't require a round-trip to Virginia.
• Portability across platforms? Vercel's standalone SDK works from anywhere — AWS Lambda, local scripts, CI pipelines.
• Deep platform integration? Cloudflare wins. The sandbox shares observability, routing, and auth with your Worker stack.

The infrastructure industry just served notice: sandboxed code execution is the new battleground. Choose your isolation boundary carefully — you'll be building on top of it for the next five years.

Further Reading

1. Cloudflare Containers Public Beta announcement — The primary source for container architecture, pricing tiers, and the sandboxing example that anchors Cloudflare's approach.
2. Vercel Sandbox changelog announcement — The primary source for Vercel's Sandbox SDK, including the API example and explicit positioning around AI-generated code.
3. Vercel Sandbox Concepts — Isolation Architecture — The documentation that confirms Firecracker microVMs with dedicated kernels, including the direct comparison table against Docker containers.
4. Cloudflare Temporary Accounts for AI agents — The latest signal in Cloudflare's sandbox trajectory, removing the sign-up barrier for AI agents a year after Containers launched.
5. Simon Willison's coverage connecting both launches — The timely analysis that called attention to the convergence of these launches within the same news cycle.
6. Cloudflare Sandbox npm package — The SDK package page including API reference, tunnel documentation, and the full feature set.