Who is CubeSandbox for?

Suits platform and infrastructure engineers building agent products who are comfortable with Linux servers, KVM and virtualization basics.

What can you build with CubeSandbox?

Run code written by an LLM agent in an isolated VM instead of on your own machine. Host a private replacement for E2B Cloud while keeping your existing E2B SDK code. Snapshot a sandbox and fork it to try several agent strategies in parallel. Run many short-lived sandboxes at once for reinforcement learning or SWE-Bench style evaluation. Let agents call external APIs while keeping the API keys outside the sandbox.

TencentCloud /

CubeSandbox

Self-hosted MicroVM sandboxes for running AI agent code, compatible with the E2B SDK

13k stars
228 stars since 3 Oct
Go
Updated yesterday
Advanced
Infrastructure & security

Open on GitHub (opens in a new tab) Website (opens in a new tab)

AI agents often write and run code, and that code needs somewhere safe to run. Docker containers share the host kernel, which is a weaker boundary. Full virtual machines isolate better but start slowly and use a lot of memory. CubeSandbox aims for the middle: a small VM per sandbox that starts quickly.

Each sandbox is a MicroVM with its own OS kernel, built on RustVMM and KVM. The README says resource pooling and snapshot cloning keep cold starts under 60ms on bare metal, with under 5MB of memory overhead per sandbox. eBPF handles isolation between sandboxes and outbound filtering, and a built-in proxy can inject credentials so secrets never appear inside the sandbox.

The obvious alternatives are Docker containers, traditional VMs and the hosted E2B Cloud. CubeSandbox is compatible with the E2B SDK, and the README says you can switch from E2B Cloud by changing one environment variable. It runs on one node or scales to a cluster. The speed and memory figures are the project's own benchmarks.

What it does

MicroVM isolation
Every sandbox runs its own OS kernel in a MicroVM, rather than sharing the host kernel like a container.
Fast, dense startup
The README reports under 60ms cold start and under 5MB memory overhead per sandbox, which allows thousands of sandboxes per server.
Snapshot, clone and rollback
You can checkpoint a running sandbox, roll back to any saved state, or fork from a state to explore options in parallel.
Network and credential controls
eBPF isolates sandboxes from each other and filters outbound traffic. An L7 proxy applies per-domain, path and method policies and injects credentials.
Deployment options
Runs on a single node, bare metal, Kubernetes (preview) or a Tencent Cloud cluster via Terraform, with ARM64 support and auto pause and resume of idle sandboxes.

What you could build

Run code written by an LLM agent in an isolated VM instead of on your own machine.
Host a private replacement for E2B Cloud while keeping your existing E2B SDK code.
Snapshot a sandbox and fork it to try several agent strategies in parallel.
Run many short-lived sandboxes at once for reinforcement learning or SWE-Bench style evaluation.
Let agents call external APIs while keeping the API keys outside the sandbox.

Get started

The README excerpt cut off before its Quick Start commands, so none are listed here. Follow docs/guide/quickstart.md in the repo to deploy on a single node, then point your E2B SDK client at your own server.

Commands are copied from the project's README. Read it on GitHub for the full setup.