E2B Sustains 1,550 Sandboxes on One NVIDIA Vera Server

E2B squeezed 1,400 to 1,550 loaded sandboxes onto a single dual-socket NVIDIA Vera server in pre-production tests published November 9, 2026, and its microbenchmarks clocked higher processor and memory throughput than an AMD EPYC 9B45 reference system. Four tuned runs delivered the capacity numbers. E2B is careful about what they mean: this is not a production deployment, and the company says the charts do not establish equivalent end-to-end agent speedups or a fleet-capacity advantage over AMD.

E2B supplies isolated microVMs through an SDK. Agents execute commands, work with files and return to a preserved running state, with each sandbox resuming from a snapshot and memory loaded as needed. Much of that session work runs on the CPU even when the model itself executes elsewhere — which is why E2B tested both individual operations and large numbers of concurrent environments.

How big are the raw performance gaps?

The Vera tests ran October 9–13, 2026, on one pre-production dual-socket server with 176 physical cores and 1,479 GiB of RAM. AMD reference measurements date from August 2026.

• Single-thread compute: 7,759 events per second on Vera versus 5,131 on the AMD EPYC 9B45 — 1.51x the reference throughput, using the median of at least three runs. Compute testing used Vera's 64K-page kernel.
• Memory throughput: 62.8 GB/s for Vera versus 17.4 GB/s for AMD — 3.61x. The test populated a 2 GiB region using 4K kernels and 2 MiB huge pages, the same huge-page backing E2B's sandboxes use.

The memory number matters more than it looks. It measures memory population, not full sandbox startup, but a runtime that repeatedly restores snapshot-backed environments leans on exactly that operation. E2B also cautions that gains for individual tools and applications will vary.

What did the full-stack fleet test show?

For capacity work, E2B used E2B Embed — its single-machine packaging of the open-source E2B Runtime and dashboard — running directly on the host, with Firecracker microVM isolation and Python and JavaScript SDK support. The evaluation covered creation, command execution, snapshot restore, capacity, and repeated creation and teardown.

• Latency at low load: 50 ms warm, sequential sandbox starts and 3.8 ms command round trips, each from separate Vera bare-metal tests, not fleet-load measurements.
• Reliability: a churn campaign completed 22,145 create-and-destroy cycles with zero errors.
• Mixed capacity: each sandbox repeatedly performed a CPU burst, a 10 MiB disk write and a pause, while one in 10 ran continuously. At the top of the range, 95th-percentile command latency hit 255 ms. When every sandbox ran continuously, a separate test sustained 550 sandboxes.

The capacity runs reserved 512 MiB per sandbox and carried guardrails: 95th-percentile latency had to stay within 5x each run's warmed burst baseline, with a 1% error limit per step. So the headline number describes capacity under specified responsiveness and reliability targets, not an absolute loading limit.

Why does host tuning matter so much?

Host configuration was a major constraint. Default settings supported just 320 sandboxes. Network-neighbor tuning raised that to 1,000 while leaving a 1,024-device limit in place. Full tuning was required to reach the main 1,400–1,550 result. E2B describes that progression as a same-server configuration comparison — not a Vera-versus-x86 speedup.

What's still unresolved?

The pre-production status leaves gaps. E2B found that x86 reference systems still completed some restore operations more quickly. Nested virtualization needs additional work. And no cost or power measurements were taken, leaving operating economics outside the evaluation entirely.

E2B's next steps are concrete: a multi-node Vera cluster, cold resumes backed by object storage, and an x86 comparison using the same E2B packaging and host tuning. The deployment case rests on those follow-ups — whether the full-stack results hold against a comparably packaged and tuned x86 system, and whether single-server capacity extends across a cluster.