CubeSandbox

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

Metric	Docker container	Traditional VM	CubeSandbox
Isolation level	Low (shared kernel namespaces)	High (dedicated kernel)	Extreme (dedicated kernel + eBPF network policy)
Boot speed	~200ms	seconds	<60ms
Memory overhead	low (shared kernel)	high (full OS)	<5MB (aggressively stripped)
Deployment density	high	low	thousands per node
E2B SDK compatible	n/a	n/a	drop-in

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:

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.