E2B Grew 375x to 15M Sandbox Runs a Month. Here's What the Sub-500ms Bar Actually Costs to Clear Yourself

E2B went from 40,000 sandbox runs a month in March 2024 to roughly 15 million a year later — a 375x jump in twelve months. That's not a platform getting more popular; it's a signal that "spin up an isolated VM, run untrusted code, tear it down" stopped being a rare operation and became something an AI agent does per turn, sometimes dozens of times in a single conversation. Every one of those spin-ups has to clear a latency bar most infrastructure was never built for: under 500 milliseconds, or the agent — and the human waiting on it — notices.

That bar is the actual engineering story, and it's answerable with real numbers, not vibes. Here's what "sub-500ms" decomposes into once you look past the headline, and whether a team running its own Kubernetes fleet can clear it without rebuilding E2B's control plane from scratch.

The 500ms Bar, Decomposed​

"Sub-500ms boot" sounds like one number. It's actually four different numbers depending on which layer does the work and whether the VM is booting cold or resuming from a snapshot:

Two things fall out of that table immediately. First, the raw Firecracker number (~125ms) and E2B's own real-world p50 (~410ms) aren't the same thing — the gap is everything E2B built on top: request routing, auth, image resolution, network setup, the parts of "a sandbox" that aren't just "a kernel boots." Second, sub-500ms isn't E2B's secret — it's Firecracker's baseline, and Firecracker has been Apache-2.0 licensed and installable on your own hardware since AWS open-sourced it in 2018. The 375x growth curve proves agents want this primitive at volume. The boot-time table proves the primitive itself was never locked behind E2B's API.

The number the title's "dozens of sandboxes in a single conversation turn" framing actually stresses, though, isn't boot latency — it's concurrent density. Firecracker's per-instance overhead is under 5MB of RAM and a stripped-down device model with no BIOS, no legacy emulation. Microsandbox reports 5-10MB per instance for the same reason. Put a number on that: a Hetzner AX102 dedicated box — 128GB RAM, 16 cores, roughly the mid-tier bare-metal SKU a CAPH-managed fleet would already be running tenant workloads on — has headroom for well over a thousand idle or warm Firecracker microVMs before RAM is the constraint, even after reserving half the box for the tenant apps already scheduled there. An agent bursting to a few dozen concurrent sandboxes on one conversation turn is nowhere near that ceiling.

What does bite at that concurrency is CPU scheduling and I/O contention during simultaneous cold boots — twenty kernels booting on the same core count at once will queue, even at 125ms each. That's why pre-warmed pools, not raw capacity, are what every production sandbox provider — E2B included — actually optimizes for: keep a standing pool of already-booted, already-snapshotted VMs per node, and an incoming request restores from snapshot (the ~5-30ms row in the table above) instead of booting cold. A self-hosted fleet gets the same lever for free, because pool management is a scheduling policy on top of Kata/Firecracker, not a feature either project has to ship for you to use it.

Can a Kubernetes-Native Fleet Hit This Without Becoming E2B?​

The honest engineering answer is yes, and the reason is that Firecracker was never the part worth reinventing — the orchestration around it was. E2B's real work was building a control plane that manages Firecracker VMs directly: custom scheduling, snapshot pooling, a bespoke API. That's a multi-year investment most platform teams shouldn't try to match line-for-line.

The shortcut is Kata Containers, a CNCF project that's been CRI-compatible since before most of the current AI-sandbox wave existed. Register it as a Kubernetes RuntimeClass and any pod that opts in runs inside a lightweight VM — its own kernel, its own isolation boundary — instead of a shared-kernel container, while still looking like an ordinary pod to the rest of the cluster: same scheduler, same kubectl, same YAML shape every other workload already uses. A cluster running Cluster API Provider Hetzner (CAPH) — declarative, self-healing Kubernetes on Hetzner cloud instances or bare-metal Robot servers — gets sandbox isolation as an additional RuntimeClass on nodes it already manages, not a parallel fleet with its own lifecycle:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc
overhead:
  podFixed:
    memory: "10Mi"
    cpu: "50m"

Once that RuntimeClass exists, any pod opts into VM-grade isolation by naming it — no other change to how the cluster schedules or exposes the workload:

apiVersion: v1
kind: Pod
metadata:
  name: agent-sandbox
spec:
  runtimeClassName: kata-fc
  containers:
    - name: sandbox
      image: agent-sandbox:latest

That's the answer to the title's specific question — whether sub-second boot is reachable "without adopting Firecracker specifically." It is, because Kata is the integration seam, not Firecracker. Kata supports Cloud Hypervisor (its default, tuned for cloud workloads), Firecracker (minimal device model, the fastest boot), or QEMU (broadest hardware compatibility) as interchangeable VMMs underneath the same RuntimeClass. Pick Firecracker under Kata and you land in the ~150-300ms range from the table above — comfortably under the 500ms bar — without writing a custom scheduler, a bespoke snapshot pool manager, or a parallel control plane. Swap the handler field, not the cluster architecture, if a future workload needs QEMU's broader hardware support instead.

This is also why the comparison to E2B isn't apples-to-apples on effort. E2B's engineering team built and operates the scheduler, the snapshot-pool manager, and the API surface that turns "a VM can boot fast" into "a customer gets a sandbox URL in milliseconds." A team adopting Kata on an existing CAPH-managed cluster inherits the scheduler for free — it's the same one already placing tenant-app pods — and only has to build the pooling and image-resolution layer on top, which is a much smaller surface than E2B's full stack. The isolation primitive was never the hard part; the request-to-ready-sandbox pipeline around it is, and that pipeline is exactly as buildable on owned infrastructure as it was on E2B's.

Where E2B's Hosted-Only Model Leaves a Gap​

None of this means E2B did something wrong — it means E2B made a specific bet, and the market has rewarded it: a $21M Series A in July 2025, on the back of that 375x growth curve, to keep building the orchestration layer as a metered API rather than a self-hostable artifact. That bet leaves three gaps a Kubernetes-native alternative doesn't have:

• Metering at scale. 15 million runs a month is 15 million line items on someone else's invoice. A self-hosted fleet on owned or leased bare metal converts that into flat capacity cost — the same shift this list has already tracked in PaaS pricing more broadly (per-seat to flat-fee, metered compute to owned nodes).
• Data residency. Agent-generated code and its output run inside E2B's infrastructure by construction. A regulated team, or one that simply doesn't want a third party in the path between an agent and its execution environment, has no self-hosted equivalent from E2B itself.
• No path to "run it yourself." E2B doesn't ship an on-prem build. Teams wanting the exact Firecracker-microVM isolation model on their own machines have to assemble it — Kata, Microsandbox, or a custom Firecracker orchestrator — rather than deploy E2B's own stack behind their firewall.

Microsandbox and Kata both close that gap from the open-source side, but neither is a drop-in platform the way E2B is a drop-in API — someone still has to operate the cluster, the RuntimeClass, and the image pipeline. That operational layer is exactly what a Cluster-API-managed fleet already exists to provide for tenant apps; extending it to agent sandboxes is additive scope, not a new platform.

What This Sets as the Bar​

The 375x growth curve says agent sandboxing is now a volume workload, not a novelty. The boot-time table says the latency bar it demands — sub-500ms, ideally sub-200ms warm — is already clearable with Apache-2.0 tooling on owned hardware: Kata Containers as the RuntimeClass abstraction, Firecracker or Cloud Hypervisor as the VMM underneath, running on the same CAPH-managed nodes that already schedule tenant workloads. The part worth taking seriously from E2B isn't the hypervisor choice — it's the reminder that boot latency alone doesn't make a sandbox product; snapshot pooling, image resolution, and warm-pool scheduling are where the remaining milliseconds and the real engineering effort actually go. That's the gap between "Kata is installed" and "an agent gets a sandbox in 150ms every time," and it's the next thing worth building, not the hypervisor underneath it.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, managed by Cluster API on infrastructure you control. Star the repo on GitHub or deploy your first app today.