CubeSandbox: MicroVM Sandbox for AI Agents
TencentCloud/CubeSandboxCubeSandbox is an open-source, E2B-compatible sandbox for AI agents from Tencent Cloud, written in Rust. It runs each sandbox as a hardware-isolated KVM microVM with its own guest kernel, so LLM-generated code you don't trust executes without sharing a kernel the way Docker containers do.
Reach for CubeSandbox if you're running lots of AI-agent code and want stronger isolation than Docker without the boot latency of a full VM: the README benchmarks a microVM starting in under 60ms with roughly 5MB overhead, and it speaks the E2B SDK, so you can point existing E2B code at it by swapping a URL. Skip it if you're not on x86_64 Linux with KVM, or you only spin up the occasional sandbox where a plain container is simpler.
The problem it solves
Running code an AI agent just wrote is a security problem: you don't know what it does, and a Docker container shares the host kernel, so a kernel escape puts the host at risk. Full VMs isolate better but boot in seconds and eat hundreds of megabytes each, which doesn't scale when an agent platform needs thousands of short-lived sandboxes. CubeSandbox exists to close that gap between container speed and VM-level isolation.
What is it?
CubeSandbox is a secure sandbox runtime for AI agents, built by Tencent Cloud on RustVMM and KVM. Each sandbox is a lightweight microVM with its own guest OS kernel, created in under 60ms with less than 5MB of memory overhead per instance, according to the README's benchmarks. It's API-compatible with the E2B SDK, runs as a single node or scales to a multi-node cluster, and the README lists it under the Apache 2.0 license.
Why it's getting attention
It landed on Trendshift and the CNCF Landscape, and the timing helps: agent platforms suddenly need somewhere safe to run model-generated code at scale, and E2B popularized the sandbox-as-a-service pattern. CubeSandbox is a self-hostable, E2B-compatible take on that from Tencent Cloud, with benchmark numbers — sub-60ms boot, thousands of instances per node — aimed at the cost and density pain of running many agents. Roughly 9.6k stars and a fast release cadence (v0.5 in July 2026) add to the momentum.
Key features
- ✓Hardware-level isolation: each sandbox is a KVM microVM with its own guest kernel, not a shared-kernel container
- ✓Sub-60ms cold start with under 5MB memory overhead per instance, per the README's bare-metal benchmarks
- ✓E2B SDK compatibility — the README says you swap one URL env var to migrate existing E2B code, no business-code changes
- ✓AutoPause/AutoResume: idle sandboxes suspend and wake on the next request to cut cost
- ✓Snapshot, clone and rollback via a copy-on-write engine (CubeCoW) at hundred-millisecond granularity
- ✓CubeEgress security gateway: domain allowlists, a credential vault that keeps API keys out of the sandbox, and egress audit logs
- ✓Web console on port 12088 plus a template system that turns OCI images into sandbox templates
Best use cases
- •Running untrusted, LLM-generated code for an AI agent without exposing the host kernel
- •Hosting a high-density agent platform where one node runs thousands of short-lived sandboxes
- •Migrating off hosted E2B to a self-hosted, API-compatible runtime by changing an endpoint
- •Reinforcement-learning or SWE-bench-style workloads that spin sandboxes up and down constantly (the README shows an RL demo)
- •Snapshotting a running sandbox to fork or roll back agent state mid-task
How to install / try
CubeSandbox needs an x86_64 Linux host with KVM support. The README's quick start walks through provisioning a server, installing, creating a template, and running agent code without a source build. It offers three deployment paths — PVM (an ordinary cloud VM, the README's recommended route), bare metal, and a QEMU-based dev environment (explicitly flagged as low-performance). Exact install commands aren't reproduced in the metadata here; see the project's quickstart and deployment guides.
How to use
After deploying, you open the web console at http://<control-node-ip>:12088 to confirm node health, install a template from the Template Store, then create a sandbox and watch live logs. For code, you use the E2B SDK pointed at your CubeSandbox endpoint — the README's examples cover code execution, browser automation, OpenClaw integration, and RL training. Per-command SDK usage beyond that isn't fully documented in the README.
Strengths
- ✓Stronger isolation than containers (a dedicated guest kernel) without the seconds-long boot of a traditional VM
- ✓E2B compatibility means existing E2B code can move over by changing an endpoint, per the README
- ✓Self-hostable and Apache-2.0 (per the README), so you control where agent code runs and can inspect the stack
- ✓Bundles operational pieces many sandbox setups lack: web console, templates, snapshots, egress control, credential vault
- ✓Benchmark numbers target real cost pain — high instance density plus auto-pause to trim idle spend
Limitations & risks
- △Hard platform requirement: x86_64 Linux with KVM. No macOS or Windows, and the QEMU dev path is explicitly low-performance, so trying it out isn't friction-free
- △Young project (first open-source release April 2026, v0.5 by July 2026); the roadmap still lists Kubernetes-native deploy, volume support, and closing remaining E2B-compatibility gaps as not yet done
- △Operationally heavier than a container — you're running a cluster (CubeMaster, Cubelet, an eBPF virtual switch, an egress gateway), which is more moving parts to deploy and maintain
- △The sub-60ms and <5MB figures come from the project's own bare-metal benchmarks, so real numbers will depend on your hardware, instance size, and concurrency
Alternatives
Who should try it — and who should skip
Teams building an AI-agent platform on x86_64 Linux that need to run untrusted, model-generated code at scale and want VM-grade isolation with container-like startup — especially anyone already using the E2B SDK who wants to self-host. It's overkill if you run the occasional sandbox, can't meet the KVM requirement, or would rather not operate a small cluster.
Frequently asked questions
CubeSandbox is an open-source, E2B-compatible sandbox runtime for AI agents from Tencent Cloud. It runs each workload as a hardware-isolated KVM microVM, booting in under 60ms with under 5MB of overhead per instance (per the README), so untrusted agent-generated code runs without sharing the host kernel.
A Docker container shares the host kernel, so a kernel escape can reach the host. CubeSandbox gives each sandbox its own guest kernel inside a KVM microVM, which the README frames as hardware-level isolation for running untrusted code, while still booting far faster than a traditional VM.
Yes. The README says CubeSandbox is API-compatible with the E2B SDK and that migrating means swapping one URL environment variable, with no business-code changes. The roadmap notes some gaps in full E2B compatibility are still being closed.
An x86_64 Linux host with KVM support. The README recommends deploying on a cloud VM (PVM) or bare metal; a QEMU-based dev environment exists but is flagged as low-performance.
The README states CubeSandbox is released under the Apache 2.0 license and developed by Tencent Cloud. You self-host it on your own x86_64 Linux infrastructure.