Your Sandbox Is an L2 Guest: What E2B's Nested Firecracker Really Costs vs Bare Metal

Every sandbox you rent from E2B boots inside a virtual machine that is itself running inside another virtual machine. Four layers sit between your agent's code and the silicon: Google's hypervisor, a rented GCP VM, a Firecracker microVM, and finally your sandbox. That nesting works — E2B creates sandboxes in about 150 milliseconds — but it has a price, in latency and in dollars, that never appears on the pricing page.

Here is the short version up front: a typical 2-vCPU/4-GiB agent sandbox costs about $0.166 per sandbox-hour on E2B's metered rates, versus about $0.011 per sandbox-hour running the same Firecracker microVMs on a flat-rate Hetzner box at full tilt — a 15x gap. The honest crossover sits near 300 sandbox-hours a month (roughly 10 sandbox-hours a day): below it, renting wins; above it, you are paying cloud margin twice. The rest of this post proves both numbers and names exactly when each side wins.

Four layers between your code and the silicon​

In February 2026, sandbox fingerprinting work published by Digger (in the diggerhq/sandbox-fingerprinting repo) pinned down what E2B's hosted cloud actually runs on: Firecracker v1.10.1 microVMs on GCP n1-standard-8 VMs with nested virtualization, in The Dalles, Oregon. E2B's own open-source infrastructure repo (e2b-dev/infra) confirms the shape — Firecracker orchestrator nodes that themselves require nested virtualization, with an AWS self-host path defaulting to m8i.4xlarge clients behind Nomad/Consul control servers.

So the full stack is:

1. Google's hypervisor (L0) — the physical host you will never see.
2. A rented n1-standard-8 VM (L1) — 8 vCPUs, 30 GB RAM, at roughly $277/month on-demand in the cheapest regions.
3. A Firecracker microVM (L2 guest) — your sandbox's kernel boundary.
4. Your sandbox — filesystem, network namespace, agent workload.

Orchestration is Nomad plus Consul, driven by a Go orchestrator — not Kubernetes. That choice matters more than it looks, and we will come back to it. First, the performance question: what does the extra virtualization layer actually cost?

The L2 nesting tax, quantified​

Firecracker's design target is a boot in under 125 milliseconds from API call to init, measured on bare metal (m5d.metal, minimal kernel). Nested, that number degrades — how much depends on what you measure:

Two things stand out. First, the raw L2 penalty is real and large on I/O paths: network and disk pay a 4–7x tax versus running the same microVM on bare metal. CPU-bound agent work (running a linter, executing a test suite) barely notices; anything shuffling bytes — cloning repos, installing dependencies, writing build artifacts — runs through two hypervisors' I/O stacks instead of one.

Second, E2B hides most of the boot tax from you. Observed ~150 ms sandbox creation next to multi-hundred-millisecond nested boots means snapshot resume and warm pools are doing heavy lifting: your "fresh" sandbox is typically a resumed snapshot, not a cold boot. That is good engineering, but it is also load-bearing engineering — the nesting tax is paid in E2B's infrastructure complexity (snapshot storage, pool warming, cache management) rather than in your Sandbox.create() latency.

Then there is the neighbor problem. An n1-standard-8 is a shared-tenancy VM: its 8 vCPUs are threads on physical cores Google also sells to other customers, with no dedicated-core guarantee. Your L2 sandbox therefore contends twice — once against other GCP tenants at the L0 hypervisor, once against other E2B sandboxes inside the L1 VM. On owned bare metal, the second contention domain still exists (you pack multiple sandboxes per host), but the first one disappears entirely: every physical core is yours, and noisy-neighbor variance becomes a scheduling problem you control rather than weather you observe.

The dollar math: $0.166 vs$0.011 per sandbox-hour​

E2B's published September 2026 rates meter compute per second: $0.000014 per vCPU-second and $0.0000045 per GiB-second, billed on wall-clock time while the sandbox is alive. Plans sit on top: Hobby is free with a one-time $100 credit, Pro is $150/month plus usage, Enterprise carries a $3,000 monthly minimum.

For the canonical agent sandbox — 2 vCPUs, 4 GiB, one hour (3,600 seconds):

• CPU: 2 × 3,600 × $0.000014 = $0.1008
• Memory: 4 × 3,600 × $0.0000045 = $0.0648
• Total: $0.1656 per sandbox-hour, before any plan fee.

Now the owned-hardware side. A Hetzner AX41-NVMe — Ryzen 5 3600 (6 cores / 12 threads), 64 GB RAM, 2×512 GB NVMe, unlimited 1 Gbit traffic — lists around €45/month (~$49). Fitting 2-vCPU/4-GiB sandboxes onto it is CPU-bound: 12 threads ÷ 2 gives 6 concurrent sandboxes (5 sustained once you reserve headroom for the host and orchestrator), while RAM allows far more. At 6 concurrent × 730 hours, one box delivers ~4,380 sandbox-hours a month for $49 — about $0.011 per sandbox-hour, roughly 15x cheaper than the metered rate.

But per-hour-at-full-tilt flatters the owned side exactly the way headline pricing flatters the rented side. The honest comparison is across utilization:

Three caveats keep this honest. First, E2B bills wall-clock while the sandbox lives, including idle gaps between agent steps — a sandbox that sits open for a 10-minute session but computes for 90 seconds bills for 10 minutes. (Vercel's Sandbox, by contrast, bills active CPU with I/O wait excluded — a meaningfully different meter for bursty agents.) Second, the Hetzner column omits the operator's time: patching, KVM capacity planning, snapshot lifecycle, and 3 a.m. pages are real costs denominated in hours, not dollars. Third, low-volume users on Hobby with the $100 credit may not pay anything for months — per-second billing is genuinely the cheapest way to run 10–20 short executions a day.

Even with those caveats, the shape of the answer is stable: somewhere around 300 sandbox-hours a month, the meter crosses the flat rate, and every hour past that is margin you pay twice — once to GCP for the underlying VM (that $277/month n1-standard-8 versus ~$49 for comparable-or-better owned iron), once to E2B on top.

The orchestration seam: Nomad, not Kubernetes​

There is a second cost that never appears in either column: E2B's stack is not Kubernetes-native, and if you already operate a Kubernetes fleet, that is a seam you will feel.

E2B's control plane is a Go orchestrator on Nomad plus Consul, provisioned by Terraform with Packer-built images, Postgres, and S3-compatible storage. Self-hosting it — which the open e2b-dev/infra repo supports — means standing up that entire assembly: control servers, Firecracker-capable client hosts with nested virtualization, and the GCP-first (or AWS) networking around them. Multiple 2026 build-vs-buy writeups land on the same verdict: it is a full infrastructure project, not a laptop install and not a Helm chart. It cannot drop into a Cluster API fleet you already run; it is a second control plane to operate, monitor, and upgrade alongside the first.

This is the point where the fingerprint quietly reframes the buy decision. If your team already runs Kubernetes on owned machines, the alternative to E2B is not necessarily E2B-self-hosted — it is Firecracker through Kubernetes: Kata Containers with the Firecracker hypervisor (~125 ms boots, K8s-native via RuntimeClass), or a purpose-built snapshot controller modeled on E2B's architecture but reconciled by the control plane you already have. You keep one scheduler, one identity system, and one upgrade runbook, and the sandbox fleet becomes a node pool with a RuntimeClass rather than a parallel universe of Nomad jobs.

None of that is free either — snapshot/resume lifecycle, template builds, and per-tenant network policy are real features E2B ships and you would need to build or borrow. But the comparison to price is not "E2B cloud versus E2B self-hosted." It is "E2B cloud versus the sandbox-shaped hole in the fleet you already operate."

Rent vs own: the decision rule​

Pulling it together, the fingerprint plus the math gives a clean decision rule:

• Rent E2B when monthly sandbox volume is under ~300 sandbox-hours, workloads are bursty or episodic (evals, demos, per-PR agents), you need zero KVM capacity planning, or per-second billing with no floor is worth more than the per-hour rate. Short-lived, spiky usage is what the meter is for.
• Own the microVMs when volume is sustained past the crossover, sessions are long-lived (wall-clock billing punishes idle-open sandboxes), data residency forbids execution transiting someone else's cloud, or noisy-neighbor variance at two contention layers is already showing up in your p99s.
• Watch the plan fee, not just the meter. On Pro, the $150/month floor means owned hardware wins on compute at literally any volume — you are paying for concurrency limits, session length, and support, so make sure you need those, not just the sandboxes.
• If you own a Kubernetes fleet, price the K8s-native path. Kata-on-Firecracker or a snapshot controller inside your existing control plane avoids operating Nomad/Consul as a second universe — the cheapest orchestrator is the one already running.

The deeper pattern is worth naming: L2-nested infrastructure means paying cloud margin twice — the hyperscaler's markup on the VM, then the vendor's markup on the sandbox. Sometimes that is still the right trade (low volume, spiky demand, no ops headcount). But once your agent fleet has steady-state volume, the fingerprint tells you exactly whose hardware bill you are covering, and the crossover math tells you the month it stops being worth it.

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