There's a Rust repo on GitHub that racked up 10,800 stars in just over three months, backed by Tencent Cloud. It doesn't train models, build editors, or ship an agent framework. It does exactly one thing: give AI agents a secure, isolated environment to run code. This is TencentCloud/CubeSandbox. As of August 1, 2026, the repo has 10,818 stars, 996 forks, primary language Rust, created April 10, 2026, last pushed August 1. The README positions it in one line: "Instant, Concurrent, Secure & Lightweight Sandbox Service for AI Agents." It's already listed in the CNCF Landscape, and there's an official PyPI package, cubesandbox 0.3.0.
A license caveat worth stating upfront: the README badge and LICENSE file both say Apache 2.0, but GitHub's API returns NOASSERTION in the SPDX field (not auto-detected). The actual license is Apache 2.0 -- the NOASSERTION just means GitHub's license detector failed to match it automatically and doesn't affect your right to use it under Apache 2.0. If you write automated compliance scripts that read the license field, don't get tripped up by this NOASSERTION; cross-check against the LICENSE file and README badge.
What Problem It Solves: Agents Can't Run Code on the Host
AI agents write code and need to run it -- that's table stakes. But letting agent-generated code execute directly on your host is an obvious risk: a prompt-injected snippet could rm -rf your directories, exfiltrate secrets from environment variables, scan your internal network, or turn your machine into a pivot point. Docker containers are the common isolation layer, but they share the host kernel -- isolation is weak, and a kernel vulnerability or misconfiguration can lead to escape. Traditional VMs isolate well enough, but they boot in seconds and consume hundreds of megabytes of memory apiece, which doesn't hold up under the high-frequency, high-concurrency code execution that agents demand.
CubeSandbox resolves this tension: hardware-level isolation security, millisecond boot times, single-digit-MB memory overhead, and density in the thousands of sandboxes per node. It's not a general-purpose virtualization platform; it's a MicroVM sandbox service purpose-built for AI agent code execution.
Core Mechanism: RustVMM + KVM Hardware Isolation, 60ms to Boot a Sandbox
CubeSandbox is built on RustVMM and KVM. Each sandbox is an independent MicroVM running its own dedicated OS kernel -- hardware-level isolation, not container namespace isolation. The README's benchmarks:
Cold start (bare-metal): 60ms at single concurrency; under 50 concurrent creations, average 67ms, P95 90ms, P99 137ms -- consistently under 150ms. Memory overhead: less than 5MB base overhead per sandbox (measured with sandbox specs up to 32GB; larger configs may see a marginal increase). Through kernel sharing and copy-on-write (CoW), a single node can run thousands of sandbox instances.
E2B SDK compatibility is a key selling point: the interface is E2B-compatible, and migrating from E2B Cloud takes a single environment variable change with zero client code changes. E2B is a mainstream AI agent sandbox cloud service, and CubeSandbox effectively gives you a self-hostable E2B alternative -- your data never leaves your infrastructure.
High density comes from two mechanisms: resource pooling plus snapshot cloning that skips cold-start overhead; and AutoPause/AutoResume introduced in v0.5 -- idle sandboxes auto-suspend and wake on the next request, further cutting resident memory and improving density and cost efficiency.
Architecture: Seven Components, Each With a Job
The README's architecture diagram breaks CubeSandbox into seven core components:
CubeAPI: a high-concurrency REST API gateway written in Rust, E2B-compatible. Swap the URL for seamless migration.
CubeMaster: the cluster orchestrator. It receives API requests and dispatches them to the corresponding Cubelets, managing resource scheduling and cluster state.
CubeProxy: a reverse proxy, E2B-protocol-compatible, routing requests to the appropriate sandbox instances.
Cubelet: the compute node's local scheduling component, managing the full lifecycle of every sandbox instance on the node.
CubeVS: an eBPF-based virtual switch providing kernel-level network isolation and security policy enforcement. This is the extra layer over a plain MicroVM -- inter-sandbox traffic is isolated at the kernel level by eBPF.
CubeEgress: an OpenResty-based egress security gateway doing L7 domain filtering, credential injection, and access auditing. Paired with CubeVS's kernel policies, sandbox traffic can't bypass inspection.
CubeHypervisor and CubeShim: the virtualization layer. CubeHypervisor manages KVM MicroVMs; CubeShim implements the containerd Shim v2 API to integrate sandboxes into the container runtime.
The architecture's logic: use KVM MicroVMs for hardware isolation, eBPF for kernel-level network isolation, containerd Shim to plug into the existing container ecosystem, and E2B-compatible APIs to plug into the AI agent ecosystem. Four layers, each handling one concern.
Version History: Six Releases in Four Months
CubeSandbox's open-source pace is fast -- six releases from April to July:
v0.1 (2026-04-20): Initial open-source release. Millisecond boot, hardware-level isolation, E2B-compatible sandbox for AI agents.
v0.3 (2026-06-02): Introduced the CubeCoW copy-on-write snapshot engine, supporting event-level snapshots, instant cloning, and rollback to any saved state. Snapshot and rollback granularity down to the hundred-millisecond level -- you can checkpoint a running sandbox, roll back at any time, or fork from a specific state to explore in parallel.
v0.4 (2026-06-14): Credential Vault (agents call external APIs but keys never enter the sandbox) and Dashboard (version matrix plus template health checks, so you can see at a glance whether templates need rebuilding after an upgrade).
v0.5 (2026-07-03): Three highlights. AutoPause/AutoResume, where idle sandboxes auto-suspend and wake on the next request; Terraform one-click cluster deployment; ARM64 native full-stack support; plus network policy hardening -- per-sandbox traffic tokens and policy-routed egress.
v0.6 (2026-07-24): Three highlights. K8s deployment, deploying Cube control-plane components and compute nodes on Kubernetes; Volume framework, E2B-compatible with pluggable custom backend storage, where volumes have an independent lifecycle and can be shared across sandboxes; template aliases, letting you set an alias when creating a template and create sandboxes by specifying that alias.
The release cadence reveals the direction: core isolation and boot performance first, then state management (snapshot/clone/rollback), then security (credential vault/network hardening), then production deployment (Terraform/K8s) and ecosystem compatibility (Volume/E2B). The v0.6 K8s deployment is still maturing -- the roadmap states the next step is evolving from Helm-based deployment toward CRD- and Operator-centric native management.
Deployment: Three Paths, Single Node to K8s Cluster
CubeSandbox requires x86_64 Linux with KVM support. Three deployment paths:
PVM Cloud VM (recommended): runs on ordinary cloud VMs without bare metal or nested virtualization. Tencent Cloud PVM servers have official deployment docs.
Bare Metal: deploy directly on physical hardware for the best performance.
Dev Environment (QEMU VM): when you have no KVM access, run CubeSandbox inside a disposable OpenCloudOS 9 VM. The README explicitly marks this "not recommended -- poor performance," for development only.
After deployment, open http://<control-node IP>:12088 in your browser for the WebUI console -- check node status, install templates, create sandboxes, and stream live logs. Production deployment supports two options: one-click Terraform cluster on Tencent Cloud, and standard Kubernetes cluster deployment (introduced in v0.6, currently in preview).
Comparison: vs E2B, vs Docker, vs Firecracker
These three are the mainstream approaches to isolation for AI agent code execution, with clearly different positioning.
vs E2B: E2B is a managed sandbox cloud service -- you call its SDK and sandboxes run on E2B's infrastructure. CubeSandbox is E2B SDK-compatible, so migrating from E2B Cloud takes one environment variable change with zero client code changes. The difference is the deployment model: E2B is SaaS; CubeSandbox is self-hosted -- your data stays in your infrastructure, costs are controllable, but you handle operations yourself. The roadmap shows CubeSandbox is still closing remaining gaps with the E2B spec for full drop-in compatibility.
vs Docker containers: Docker's isolation level is low (shared kernel namespaces), but the ecosystem is mature, images are plentiful, and boot is reasonably fast (the README's benchmark table puts it around the 200ms mark). CubeSandbox's isolation is stronger (dedicated kernel plus eBPF -- the README labels it "Extreme"), boot is faster (<60ms vs ~200ms), memory overhead is lower (<5MB), and per-node density is higher (thousands vs high). The trade-off: CubeSandbox needs KVM, so it won't run on just any machine; Docker runs almost anywhere. If you're running trusted code for CI, Docker is fine; if you're running untrusted, agent-generated code that could be prompt-injected, hardware-level isolation is safer.
vs Firecracker: Firecracker is AWS's open-source Rust-based KVM MicroVM, used in Lambda and Fargate, built for multi-tenant serverless compute isolation. The two share a similar technical approach (both Rust + KVM MicroVM), but the positioning differs: Firecracker is general-purpose compute isolation infrastructure, while CubeSandbox is purpose-built for AI agent code execution -- with E2B SDK compatibility, copy-on-write snapshots, AutoPause, credential vault, and egress auditing, capabilities that only agent scenarios need. The README doesn't publish a direct benchmark against Firecracker, so this comparison is architectural positioning only. One more detail: CubeSandbox's acknowledgments specifically thank Cloud Hypervisor (another Rust-based VMM) and Kata Containers, meaning its MicroVM implementation stands on these projects' shoulders rather than being built from scratch.
Security Design: Three Layers of Defense
CubeSandbox's security design deserves its own section, because it directly determines whether you dare let an agent run code.
Layer one, hardware isolation: each sandbox runs a dedicated kernel at the MicroVM level. This is the strongest isolation boundary -- even if code inside the sandbox gets root, it stays within its own MicroVM and can't touch the host kernel.
Layer two, network isolation: CubeVS uses eBPF to enforce inter-sandbox network isolation and egress filtering at the kernel level. CubeEgress applies L7 policies at the domain/path/method level, and paired with CubeVS's kernel policies, sandbox traffic can't bypass inspection.
Layer three, credential isolation: v0.4's Credential Vault lets agents call external APIs with keys that never enter the sandbox -- secrets are injected at the gateway layer, and the code inside the sandbox never sees them. This closes the most common exfiltration path: "ask the agent to print the keys from environment variables."
Stacked together, even if an agent gets prompt-injected into running malicious code, it can't get out (network isolation), can't see secrets (credential isolation), and can't escape the sandbox (hardware isolation).
Use Cases and Pitfalls
Suited for: teams building AI agent code-execution platforms (code interpreters, data analysis, agent workflows); enterprises with strict data-compliance requirements that can't ship code to a third-party hosted sandbox; teams migrating from E2B who want to self-host; and RL training scenarios (SWE-Bench-style) that need large numbers of short-lived sandboxes -- the README's demos include RL training and snapshot/clone/rollback walkthroughs.
Four pitfalls to watch. First, KVM is a hard prerequisite -- cloud VMs without nested virtualization won't work (use PVM or bare metal). Second, v0.6's K8s deployment is still in preview; for production, start with Terraform single-node or Tencent Cloud deployment, and wait for the roadmap's CRD/Operator to mature before relying on K8s. Third, E2B compatibility is still being filled in (the roadmap explicitly lists "Close remaining gaps"), so some advanced E2B features may not be covered yet -- run through the APIs you depend on before migrating. Fourth, the license-field NOASSERTION gotcha: don't trust only GitHub's API SPDX field in automated compliance scans; cross-check with the LICENSE file and README badge -- the actual license is Apache 2.0.
One more thing worth noting on community: the Cube 100 Program is looking for the first 100 teams running AI agents in production with Cube, limited to 100 seats. If you're deploying agent code execution, this is a direct line to the maintainers.
CubeSandbox isn't complicated -- it doesn't touch models; it just gives agents a hardware-isolated box to run code in. What it does is compress MicroVM boot to 60ms, memory to 5MB, and per-node density to thousands, then bolt on an E2B-compatible API so you can drop it into your existing agent stack. Behind those 10,800 stars is the recognition that AI agents moving from "can write code" to "can safely run code" is a step worth taking seriously.
References
- CubeSandbox GitHub repo (10,818 stars / 996 forks, Rust, Apache 2.0): https://github.com/TencentCloud/CubeSandbox
- README (positioning, benchmarks, architecture, versions): https://github.com/TencentCloud/CubeSandbox/blob/main/README.md
- Core operations performance benchmark report (bare metal): https://github.com/TencentCloud/CubeSandbox/blob/main/docs/blog/posts/2026-06-01-cubesandbox-perf-benchmark.md
- PVM cloud server benchmark report: https://github.com/TencentCloud/CubeSandbox/blob/main/docs/blog/posts/2026-06-03-cubesandbox-perf-benchmark-pvm.md
- PyPI package cubesandbox 0.3.0: https://pypi.org/project/cubesandbox/
- CNCF Landscape listing: https://landscape.cncf.io/