CubeSandbox - sub-60ms self-hosted E2B alternative

CubeSandbox is Tencent Cloud's open-source answer to E2B: a high-density, hardware-isolated sandbox runtime built on RustVMM and KVM, with E2B SDK compatibility so you can swap one URL and migrate. The headline numbers - sub-60ms cold starts, less than 5MB memory overhead per instance, thousands of sandboxes per node - are validated against real Tencent Cloud production workloads, not benchmarks fabricated for the README.

The pitch worth understanding before the install steps: this is not "Docker but better." Each sandbox runs with its own Guest OS kernel, which means container-escape attacks don't apply. For executing untrusted LLM-generated code at scale, that distinction is the whole point.

How the numbers compare

Cold start is benchmarked on bare metal - 60ms at single concurrency, P95 90ms / P99 137ms under 50 concurrent creations, consistently sub-150ms. Memory overhead holds below 5MB for sandbox specs up to 32GB.

Architecture

Six components, each with a clear job:

• CubeAPI - Rust REST API gateway, E2B-compatible. Swap one URL to migrate.
• CubeMaster - cluster orchestrator. Routes API requests to Cubelets, manages scheduling.
• CubeProxy - reverse proxy speaking the E2B protocol, routes traffic to the right sandbox.
• Cubelet - per-node component. Manages the lifecycle of every sandbox on the node.
• CubeVS - eBPF-based virtual switch enforcing kernel-level network isolation and egress filtering.
• CubeHypervisor + CubeShim - virtualization layer. Hypervisor manages KVM MicroVMs; Shim implements the containerd v2 API so sandboxes plug into existing container runtimes.

Quick start

The hard prerequisite: a KVM-enabled x86_64 Linux environment. WSL 2 works, a Linux physical machine works, a cloud bare-metal server works. A nested-virt cloud VM might or might not - the README is most confident when KVM is real, not emulated.

git clone https://github.com/tencentcloud/CubeSandbox.git
cd CubeSandbox/dev-env
./prepare_image.sh   # one-off: download and initialize the runtime image
./run_vm.sh          # boot the dev environment; keep this terminal open

In a second terminal, log into the environment:

cd CubeSandbox/dev-env && ./login.sh

That drops you into a disposable Linux env where the rest of the install happens, so your host stays clean.

Inside the env, install the service (one of these depending on location):

# Global users
curl -sL https://github.com/tencentcloud/CubeSandbox/raw/master/deploy/one-click/online-install.sh | bash

# Mainland China mirror
curl -sL https://cnb.cool/CubeSandbox/CubeSandbox/-/git/raw/master/deploy/one-click/online-install.sh | MIRROR=cn bash

Then create a code-interpreter template from the prebuilt image:

cubemastercli tpl create-from-image \
  --image ccr.ccs.tencentyun.com/ags-image/sandbox-code:latest \
  --writable-layer-size 1G \
  --expose-port 49999 \
  --expose-port 49983 \
  --probe 49999

cubemastercli tpl watch --job-id <job_id>

Wait for READY, note the template ID, and run code via the E2B SDK:

import os
from e2b_code_interpreter import Sandbox  # genuinely the E2B SDK

with Sandbox.create(template=os.environ["CUBE_TEMPLATE_ID"]) as sandbox:
    result = sandbox.run_code("print('Hello from Cube Sandbox, safely isolated!')")
    print(result)

Set E2B_API_URL=http://127.0.0.1:3000 and E2B_API_KEY=dummy and the SDK transparently talks to CubeSandbox.

What makes the cold start fast

Two techniques compose:

• Resource pool pre-provisioning - the runtime keeps warm sandboxes ready, so allocating a new one is mostly metadata work.
• Snapshot cloning with CoW memory - guest kernels start from a pre-booted snapshot rather than going through full boot. Memory pages are copy-on-write across instances, which is what makes the per-instance overhead under 5MB.

For RL workflows where you create thousands of sandboxes during training, this is the difference between "feasible" and "would take a week."

Network security

CubeVS enforces inter-sandbox network isolation at the kernel level via eBPF, with fine-grained egress filtering. That's relevant if you're worried about LLM-generated code making outbound calls you didn't sanction. For a code interpreter, this is table stakes; for a Docker-based stack it's an awkward retrofit.

Where to put it in your stack

CubeSandbox is the runtime. You still need an SDK or framework to drive it. Two clean fits:

• E2B users - drop-in replacement, swap one env var.
• AgentBox SDK users - point the e2b provider at a CubeSandbox URL and you get the AgentBox developer experience on a self-hosted runtime.

When to reach for it

• High-density code execution (RL training, agent fleets, mass evaluation) where E2B-style economics don't work.
• Self-hosted requirements driven by data residency or compliance.
• Production workloads where Docker's shared-kernel model is no longer acceptable.

When not to

• Mac- or Windows-native workflows. KVM is the floor; everything else is a workaround.
• Single-node hobbyist setups. CubeSandbox shines at scale; one user with one sandbox is overkill.
• Workflows that don't need real isolation. If you trust the code, Docker is simpler.

Limits worth flagging

The KVM requirement is the real gating constraint. You can't run this on a typical laptop without WSL 2 or a VM that supports nested virt. Plan accordingly.

The "event-level snapshot rollback" feature listed in the README is marked "coming soon" - don't plan around it yet.

The base image build (step 3 in the quick start) downloads and extracts a fairly large image. Be patient, especially on first install.

Apache 2.0 licensed. Built on Cloud Hypervisor, Kata Containers, virtiofsd, containerd-shim-rs, and ttrpc-rust - all upstream credits preserved.