TL;DR

CubeSandbox is Tencent Cloud’s open-source microVM sandbox for AI agents, released April 2026 and now up to ~9.9K GitHub stars with roughly 2,500 gained this past week. It is pitched as a drop-in replacement for E2B — same SDK, self-hosted, one URL swap. Key facts:

  • Sub-60ms cold start at single concurrency; P95 90ms, P99 137ms under 50 concurrent creates on bare metal.
  • <5MB memory overhead per sandbox instance — Tencent claims thousands of concurrent sandboxes per node.
  • RustVMM + KVM microVMs, same architectural family as Firecracker but a separate VMM implementation.
  • E2B SDK-compatible — swap one E2B_API_URL env var, existing E2B code runs unchanged.
  • Hardware-level isolation — each sandbox gets its own guest kernel, unlike Docker’s shared-kernel model.
  • Apache 2.0 license, CNCF Landscape listed under AI-native workload runtimes.
  • Rust codebase, x86_64 + ARM64 support as of v0.5 (July 2026).
  • Ships with a WebUI on port 12088, egress firewall (CubeEgress), credential vault, and eBPF-based virtual switch.

If you have been paying E2B’s hosted bills for your agent code-execution and wanted a self-hosted alternative that is not another Firecracker orchestrator you have to glue together yourself, CubeSandbox is the most interesting entrant this quarter.

Quick Reference

FieldValue
RepoTencentCloud/CubeSandbox
Stars~9,888 (2,490 this week)
LicenseApache 2.0
LanguageRust
Latest releasev0.5.0 (July 2026)
First open sourceApril 21, 2026
VMMRustVMM on KVM
Boot latency<60ms cold, P95 90ms
Memory overhead<5MB per sandbox
Host requirementx86_64 or ARM64 Linux with KVM
SDK protocolE2B-compatible
CNCFListed in Landscape (AI-Native Infra)
Web consolehttp://<node>:12088
PyPIcubesandbox

What CubeSandbox Actually Is

CubeSandbox is not a container runtime. It is a microVM orchestrator that hands each AI agent its own hardware-isolated Linux virtual machine, spun up in less time than a Docker container takes to start.

The thing agents do — and the reason sandboxes exist as a product category — is execute untrusted code that a language model just wrote. That code might do the right thing. It might also run rm -rf /, exfiltrate environment variables, or try to escape into your host. Docker’s shared-kernel model has a long history of container escapes when the workload is adversarial. The industry consensus for LLM-generated code execution has settled on microVMs (Firecracker, Cloud Hypervisor, Kata Containers) — full guest kernel isolation with boot times fast enough that “one VM per code cell” is economically viable.

CubeSandbox is Tencent’s take on that pattern: their own RustVMM-based hypervisor (CubeHypervisor), their own containerd shim (CubeShim), an eBPF virtual switch (CubeVS) for network isolation, and an OpenResty-based egress gateway (CubeEgress) that intercepts every outbound HTTP request before it leaves the guest.

The pitch is credible on paper — sub-60ms boot is faster than what E2B publishes, and <5MB overhead per instance is genuinely low. Whether it holds up outside Tencent’s bare-metal testbed is the question we cannot answer from a README.

Three things landed at once in early July:

  1. v0.5 shipped with AutoPause/AutoResume (idle sandboxes hibernate, wake on request — the missing feature people were asking for since v0.1), Terraform one-click deploy, and ARM64 support.
  2. CNCF Landscape inclusion got picked up on cloud-native newsletters, giving it the “not just some Tencent side project” credibility marker.
  3. E2B’s pricing pressure — E2B recently retooled their hosted pricing, and self-hosted alternatives became a hotter topic on r/LocalLLaMA and HN. CubeSandbox is the highest-star E2B alternative that is not a build-it-yourself Firecracker deployment.

The star velocity is the tell. 2,490 stars this week on a repo that was already sitting at ~7.4K means it is broadly being shared, not just discovered by CNCF followers.

Architecture: How It Works

The system is deliberately split into small services, each with one job:

ComponentResponsibility
CubeAPIREST gateway; speaks the E2B protocol so existing SDK code works unchanged
CubeMasterCluster orchestrator; schedules sandboxes across nodes
CubeProxyReverse proxy that routes requests to the right sandbox
CubeletPer-node agent; manages sandbox lifecycle on that host
CubeVSeBPF-based virtual switch; kernel-level network isolation and policy enforcement
CubeEgressEgress firewall (L7 domain filtering, credential injection, audit logs)
CubeHypervisorRustVMM-based KVM hypervisor; runs the guest kernels
CubeShimImplements containerd Shim v2 API so sandboxes plug into the container runtime

The most interesting design choice is not the 60ms cold start. It is the E2B SDK compatibility. E2B’s from e2b_code_interpreter import Sandbox interface is the closest thing this category has to a de facto standard, and by mirroring it exactly, CubeSandbox sidesteps the problem most “alternatives” have — nobody wants to learn a new SDK just to change hosting providers.

The second-most-interesting choice is CubeEgress. Most sandbox projects treat network policy as an afterthought (or leave it to your infra team’s iptables rules). CubeSandbox makes egress a first-class concern with a credential vault that injects API keys at the proxy layer, so keys never enter the sandbox VM, the model context, or the sandbox logs. This matters more than the raw perf numbers if you are shipping agents to production.

Getting Started

CubeSandbox requires x86_64 or ARM64 Linux with KVM support. macOS and Windows are not host options — you can run the client SDK there, but the daemon needs a real Linux with /dev/kvm. Bare metal is best; cloud VMs work if they support nested virtualization (AWS .metal, Tencent PVM, GCP nested-virt-enabled instances).

Install (single node, quick start)

# On the Linux host with KVM
curl -fsSL https://github.com/TencentCloud/CubeSandbox/releases/latest/download/install.sh | sudo bash
sudo cube-sandbox start

After the daemon starts, the WebUI is at http://<host-ip>:12088. Confirm the node is Ready, install an official template from Template Store (Python, Node, or a generic Ubuntu base), then create your first sandbox from the UI to sanity-check.

Run agent code (E2B-compatible Python SDK)

The whole reason CubeSandbox exists in this exact shape is so this works:

from e2b_code_interpreter import Sandbox

# Point the SDK at your self-hosted CubeSandbox instead of E2B's hosted service.
# One env var change — E2B_API_URL — and no code changes.
import os
os.environ["E2B_API_URL"] = "http://your-cube-host:12088"
os.environ["E2B_API_KEY"] = "your-cube-api-key"

with Sandbox(template="python-base") as sbx:
    execution = sbx.run_code("""
        import numpy as np
        arr = np.random.rand(10)
        print(arr.mean())
    """)
    print(execution.text)  # prints the sandbox's stdout

If you already have E2B code, that is the entire migration. This is the single biggest reason CubeSandbox is picking up stars — the switching cost is measured in minutes.

Run agent code (direct REST)

For non-Python stacks or when you want to see what is on the wire:

# Create a sandbox
SBX=$(curl -sX POST "http://cube-host:12088/sandboxes" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"template":"python-base","timeoutMs":300000}' | jq -r '.sandboxId')

# Run code
curl -X POST "http://cube-host:12088/sandboxes/$SBX/exec" \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"language":"python","code":"print(2+2)"}'

# Destroy
curl -X DELETE "http://cube-host:12088/sandboxes/$SBX" \
  -H "Authorization: Bearer $API_KEY"

Snapshot, clone, rollback

The v0.3 CubeCoW copy-on-write engine gives you sub-second checkpoints on running sandboxes:

with Sandbox(template="python-base") as sbx:
    sbx.run_code("import pandas as pd; df = pd.read_csv('big.csv')")
    snap = sbx.snapshot()          # ~100ms
    sbx.run_code("df = df.head(0)")  # oops, dropped the data
    sbx.restore(snap)               # ~100ms, df is back

This is genuinely useful for agent workflows where you want to fork state before letting an LLM try something risky, then roll back if it goes wrong.

First Impressions from the Community

The reaction has been enthusiastic-with-caveats — which is a healthier signal than pure hype for infra.

  • r/tech_x (24 days ago, ~140-comment thread): “TENCENT JUST DROPPED THE BOMB for everyone, making AI Agents (Self-hosted, open-source, and FREE).” Top skeptical comment: “It’s just E2B?” — which is the point. Another: “Apparently this is just an orchestration engine for Firecracker VMs, which it uses as the actual sandboxing technology” — actually incorrect; CubeSandbox has its own RustVMM-based hypervisor rather than wrapping Firecracker, though the family resemblance is fair.
  • WaveSpeed blog analysis: “Practically: it’s a microVM sandbox in the same architectural family as Firecracker, but a separate VMM implementation. Whether the implementation quality holds up outside Tencent’s bare-metal testbed is the open question.” This is the honest technical read.
  • DEV.to walkthrough by the CubeSandbox team walked through the perf benchmarks in detail — the numbers reproduce on bare metal but expected degradation on nested-virt cloud instances (30-40% slower cold starts on a Tencent PVM vs bare metal, per their own PVM benchmark report).
  • On HN, the recurring theme is: “Great that Tencent open-sourced it, but who is going to run it in production outside Tencent Cloud?” Fair concern. That question will get answered over the next 6-12 months.

When To Pick CubeSandbox vs Alternatives

Use caseBest choice
Self-hosted E2B replacement, minimum migration effortCubeSandbox
Fully managed sandbox with SLA and supportE2B (hosted)
Building your own orchestrator on top of primitivesFirecracker + your own control plane
Kubernetes-native sandboxing todayKata Containers
Serverless functions (not agents)Firecracker via Fly.io / AWS Lambda
macOS/Windows dev boxesE2B (hosted) or Docker + gVisor
Ultra-low overhead for thousands of sandboxes per nodeCubeSandbox (per their claims)

Honest note on the “vs Firecracker” comparison. Firecracker is a hypervisor library; you build your own control plane on top of it (which is what E2B, Fly.io, and Modal Labs all did). CubeSandbox is a full stack — VMM + orchestrator + network + WebUI — that ships out of the box. If your team’s job is “run agent code,” CubeSandbox is drastically less integration work. If your team’s job is “build a sandbox platform,” Firecracker + your own control plane gives you more control.

Honest Limitations

  • Linux + KVM required. No macOS host support (the client SDK is fine everywhere). If your team runs on Mac dev boxes, you need a Linux VM or cloud host for the daemon.
  • Cloud VM performance is worse than the headline numbers. The <60ms figure is bare-metal. On Tencent PVM (their own cloud) it is 30-40% slower per their published PVM benchmark; on AWS .metal or GCP nested-virt it will likely be similar. Nested virtualization is not free.
  • v0.x maturity. v0.5 shipped July 2026. This is a fast-moving project, not a battle-tested one. The public API is E2B-compatible so the risk is contained, but if you need K8s-native deployment or cross-node pause/resume, those are still on the roadmap.
  • China-based maintainer. Some organizations have policies against production infrastructure from Chinese vendors. Apache 2.0 lets you fork, but the primary code review happens in Shenzhen timezone.
  • Templating is OCI-based but the template catalog is small compared to E2B’s shipped presets. You will build most of your own templates.
  • No hosted service. If you want CubeSandbox-as-a-service, there is not one — you run the daemon yourself. Tencent Cloud is presumably preparing to offer this on TKE (Tencent Kubernetes Engine), but it is not GA.
  • Docs are bilingual EN/中文 but some deeper design docs land in Chinese first. Not a blocker, but occasional context is missing from the English side.
  • Volumes support is on the roadmap, not yet shipped. If your sandboxes need persistent shared storage, you will wait.

FAQ

Is CubeSandbox actually a drop-in replacement for E2B?

For the code-interpreter surface — creating sandboxes, executing code, streaming stdout/stderr — yes. The E2B SDK works by swapping the E2B_API_URL and API key. Filesystem and command-execution APIs are covered. Some E2B features like the hosted templates catalog and the E2B dashboard are E2B-only; you get CubeSandbox’s WebUI at port 12088 instead. If you use only the code-interpreter core of E2B, migration is one env-var change. If you rely on E2B’s hosted template gallery or their team dashboards, you will build your own.

How does CubeSandbox compare to Firecracker?

They are in the same architectural family — RustVMM-based microVMs on KVM — but CubeSandbox has its own VMM implementation (CubeHypervisor) rather than wrapping Firecracker. More importantly, CubeSandbox ships a full stack: orchestrator, network, egress firewall, credential vault, WebUI. Firecracker gives you the primitive; you build the control plane. If you are choosing between “run this Rust daemon” and “build your own orchestrator on Firecracker over 3-6 months,” CubeSandbox is the faster path.

Can I run CubeSandbox on macOS?

No. The daemon requires Linux with KVM. The client SDK (Python E2B SDK pointed at your CubeSandbox host) works fine from macOS. For local dev without a Linux host, you can run CubeSandbox inside a Linux VM with nested virtualization enabled — Tencent publishes an OpenCloudOS 9 dev environment guide for exactly this.

Is CubeSandbox actually secure enough for untrusted LLM-generated code?

The threat model — running attacker-controlled code — is exactly what microVM sandboxes are designed for, and CubeSandbox’s architecture (dedicated guest kernel + eBPF network isolation + egress firewall + credential vault) is the current best practice. That said, “designed for” and “battle-tested against real adversaries at scale” are different things. E2B has run more agent code in production than any self-hosted alternative. If you are shipping a public-facing product, defense-in-depth (network egress restrictions + rate limits + audit logs + a review pass on your prompt engineering) matters more than which sandbox VMM you picked.

What is the license and can I use it commercially?

Apache 2.0 on the entire codebase. You can fork, self-host, embed it in commercial products, and modify it. Standard Apache 2.0 obligations apply (preserve copyright notices, disclose modifications if you distribute a fork). No CLA required for contributions per their CONTRIBUTING guide.

How does it compare to Kata Containers?

Kata Containers is the closest peer — also microVM-based, also OCI-compatible via containerd shim. Kata has a much longer track record (5+ years, production-hardened at Ant Group, IBM, and others) and much better Kubernetes integration. CubeSandbox is optimized for the AI-agent use case specifically: E2B protocol compat, snapshot/clone/rollback tuned for LLM workflows, credential vault. If you want Kubernetes-native production sandboxing today, Kata. If you want the E2B SDK protocol with self-hosted VMs, CubeSandbox.

Sources