CubeSandbox

CubeSandbox is an open-source sandbox service purpose-built to give AI agents secure, disposable compute at scale. Each sandbox boots as a dedicated MicroVM with its own Linux kernel on top of KVM, isolating agent-executed code at the hardware level rather than sharing a host kernel the way container-based sandboxes do. Cold starts average under 60ms and steady-state overhead per sandbox is under 5MB, so a single node can host thousands of concurrent, hardware-isolated environments — a density and speed profile aimed squarely at agent workloads that spin up and tear down sandboxes constantly.

Under the hood, CubeSandbox splits into a stateless control plane and a node-local data plane. CubeAPI (Rust/Axum) and CubeMaster (Go) handle scheduling and API traffic with all coordination state held in Redis, so either service scales out horizontally with no local state to reconcile. On each compute node, Cubelet drives the sandbox lifecycle through CubeShim, a containerd Shim v2 implementation that hands off to CubeHypervisor — a lightweight VMM built on RustVMM. Snapshotting and cloning go through CubeCoW, a Rust storage engine that uses the kernel’s FICLONE ioctl for O(1), zero-copy snapshots, enabling hundred-millisecond-granularity checkpoint/rollback/fork of running sandboxes.

The project ships an E2B-compatible REST API, so existing E2B SDK code (Python, JS) can point at a self-hosted CubeSandbox cluster by changing only the API URL and key — no client-side rewrite. Security is handled at the network layer: all sandbox egress routes through CubeEgress, an OpenResty-based L7 proxy enforcing per-domain/path/method allowlists with automatic credential injection, so secrets used to call external APIs never enter the sandbox itself. CubeVS adds eBPF-based inter-sandbox isolation and SNAT egress at the kernel level.

Beyond the core runtime, CubeSandbox includes auto-pause/auto-resume for idle sandboxes, a pluggable Volume framework for custom storage backends, a WebUI/CLI for operators, and deployment tooling for single-node, Terraform-based Tencent Cloud clusters, and Kubernetes. Client SDKs are published for Python (PyPI), Go, and Node, and the project is maintained by Tencent Cloud with an active, CNCF-landscape-listed open-source community.

What You Get

• Hardware-isolated MicroVMs - every sandbox runs its own Linux kernel under KVM via the RustVMM-based CubeHypervisor, with a seccomp-hardened, minimal syscall surface.
• Sub-60ms cold starts - resource pooling and snapshot cloning skip cold-start overhead, with under 5MB memory overhead per sandbox for high-density deployment.
• E2B API compatibility - CubeAPI (Rust/Axum) implements the E2B REST surface, so existing E2B SDK code switches over by changing only the API URL and key.
• CubeCoW snapshot engine - a Rust library using the kernel FICLONE ioctl for O(1) copy-on-write snapshots, clones, and hundred-millisecond-granularity rollback.
• Zero-trust egress proxy - CubeEgress (OpenResty/Lua) enforces per-domain/path/method allowlists and injects credentials for outbound API calls so secrets never reach sandbox code.
• Multi-language SDKs - official Python (PyPI cubesandbox), Go, and Node client libraries, plus a WebUI and CLI for operators.

Common Use Cases

• AI coding agents - give autonomous coding agents a disposable, hardware-isolated environment to execute and test generated code.
• Migrating off E2B Cloud - self-host the same E2B-compatible API to cut cloud sandbox costs or meet data-residency requirements, without touching client SDK code.
• High-concurrency agent platforms - run thousands of short-lived sandboxes per node for SaaS products that spin up a sandbox per user session or per task.
• Stateful long-running agents - snapshot, pause, resume, and roll back persistent dev environments or agent-hosted services via CubeCoW’s checkpointing.
• Untrusted code execution with controlled egress - execute LLM-generated code where outbound network calls must be restricted to an explicit domain/path allowlist.

Under The Hood

Architecture CubeSandbox splits cleanly into a stateless control plane and a node-local data plane. CubeAPI (Rust/Axum) and CubeMaster (Go) accept sandbox lifecycle requests and coordinate scheduling entirely through Redis, so any number of API/scheduler replicas can serve any request with no local state to reconcile — horizontal scale-out requires no leader election or sticky routing. On each compute node, Cubelet owns the full sandbox lifecycle (create, run, pause, resume, snapshot, destroy) and delegates the actual VM operations to CubeShim, which implements the containerd Shim v2 interface and hands off to CubeHypervisor for vCPU, memory, and virtio device management. Storage is decoupled into CubeCoW, a standalone Rust library exposed through a generic Engine trait so its FICLONE-based reflink backend can later be swapped for others without touching callers. Request routing and idle-sandbox lifecycle are similarly separated: CubeProxy handles host/path-based routing while the standalone cube-lifecycle-manager watches Redis lifecycle events to drive auto-pause/resume, discovering live CubeProxy replicas dynamically rather than through static configuration. This is a genuinely modular, service-oriented architecture with clear boundaries between scheduling, VM execution, storage, and networking — changing the hypervisor or storage backend would touch CubeShim/CubeCoW without requiring changes to CubeMaster’s scheduling logic.

Tech Stack The core is a Rust/Go split by responsibility: Rust for latency-critical, close-to-the-kernel components (CubeAPI on Axum, CubeHypervisor on RustVMM, CubeShim as a containerd Shim v2, CubeCoW’s reflink engine), and Go for cluster-level orchestration and node agents (CubeMaster using gin-gonic and containerd’s client, Cubelet, CubeDB, cube-lifecycle-manager, network-agent). Redis is the shared coordination store for the stateless control plane; CubeDB layers a migration-managed SQL store (a MySQL driver plus an embedded sqlite path) on top for durable metadata. Networking and egress security run on OpenResty/nginx with Lua (CubeProxy, CubeEgress) plus eBPF-based enforcement in CubeNet/CubeVS. Deployment tooling spans Docker images, Terraform (one-click Tencent Cloud cluster provisioning), and Kubernetes charts, with CI covering build, unit tests, formatting, migration checks, and Terraform validation across the whole monorepo. Client SDKs are published to PyPI, npm, and as a Go module.

Code Quality The monorepo carries extensive Go and Python test coverage alongside a smaller set of Rust tests, with Go tests using testify-style assertions and mocking helpers. CI is comprehensive: dedicated unit-test, build, formatting, DCO, migration-check, Kubernetes-chart, and Terraform-validate workflows all gate changes per-component via path filters, so a change to CubeProxy doesn’t need to pass CubeHypervisor’s pipeline and vice versa. Error handling in the Rust components follows typed, Result-based propagation rather than silent failure, and Go components follow conventional explicit error returns. Naming is consistent and domain-specific (Cubelet, CubeShim, CubeCoW) rather than generic. Inline comment density is moderate — the project leans on extensive external documentation (a large docs/ tree, per-component READMEs, and a public changelog) more than dense in-code comments.

What Makes It Unique CubeSandbox’s differentiation is in the combination, not any single primitive: hardware-level MicroVM isolation (KVM + RustVMM) with sub-60ms cold starts and under-5MB overhead per sandbox, achieved through resource pooling and CubeCoW’s FICLONE-based zero-copy snapshotting rather than traditional block-device or filesystem-layer snapshotting. Layering an E2B-compatible REST API on top means it can be adopted as a drop-in, self-hosted replacement for E2B Cloud with no client-side changes. Its built-in CubeEgress security proxy goes further than typical sandbox network policies by injecting credentials for allowlisted outbound calls at the proxy layer, so API secrets never enter the sandbox’s execution environment at all — a meaningfully different trust boundary than simply handing the sandbox an environment variable with the key.

Self-Hosting

Licensing Model Apache-2.0 licensed — all CubeSandbox components (CubeAPI, CubeMaster, Cubelet, CubeShim, CubeHypervisor, CubeCoW, CubeProxy, CubeEgress, and the client SDKs) are available under Apache-2.0 with no license keys or feature gating in self-hosted deployments.

Self-Hosting Restrictions None found. Every component in this repository — scheduling, the E2B-compatible API, snapshotting, networking, and the security proxy — is available to self-hosted deployments.

Enterprise Features No separate enterprise tier. The project provides a Terraform-based one-click deployer and Kubernetes charts for running production clusters on Tencent Cloud, but these are deployment conveniences rather than gated features — the underlying compute/network resources they provision are billed by Tencent Cloud itself, not by CubeSandbox.

Cloud vs Self-Hosted CubeSandbox has no separate hosted SaaS offering; cubesandbox.com is the project’s documentation site. All usage is self-hosted, whether on a single node, a Terraform-provisioned Tencent Cloud cluster, or Kubernetes.

License Key Required No.