CubeSandbox: a KVM-backed sandbox service for AI agents that speaks the E2B API

The problem CubeSandbox addresses: untrusted agent code needs a boundary

An agent that writes and runs code is an agent that runs code you did not write. The usual first answer is a container, and the usual second answer is a container that shares a kernel with everything else on the host. CubeSandbox takes the position that agent workloads deserve a hardware boundary instead. The README describes it as a secure sandbox service built on RustVMM and KVM, with hardware-level isolation as the headline property, and it states that a sandbox can be created in under 60ms with less than 5MB of memory overhead. Those are the project's own figures, published in the README; treat them as claims to reproduce on your hardware rather than as measurements.

The audience is narrower than "anyone running agents". You need to be running code on behalf of a model, you need that code to be isolated from your own infrastructure, and you need the isolation to be cheap enough that you can spin a fresh environment per task rather than reusing a long-lived one. If your agent only calls APIs and never executes generated code, a sandbox service is an extra component you do not need.

RustVMM, KVM and the component split visible in the repository

The architecture is not a single binary. The top level of the repository separates concerns into named directories: CubeAPI, CubeMaster, CubeOps, Cubelet, CubeProxy, CubeNet, CubeEgress, CubeShim, CubeTemplateCenter, CubeS3lvol, cubecow, hypervisor, guest-init, and a web directory for the dashboard. The README's v0.7.0 notes describe a control plane and operations separation, where node management moves into CubeOps with multi-replica deployment and a cubeopscli. Read together, that is a control plane that schedules and manages nodes, a per-node agent that runs sandboxes, a networking and egress layer, and a template service that holds the images sandboxes boot from.

The isolation itself comes from the hypervisor directory and the kernel image built from configs/kernel-oc9.<arch>.config, per the Makefile comments. Sandboxes boot a guest kernel rather than joining the host kernel namespace. That is the mechanism behind the isolation claim, and it is also the reason the host requirements are what they are.

Two mechanisms are worth calling out because they shape what you can build. The first is CubeCoW, the copy-on-write snapshot engine introduced in v0.3.0, which the changelog describes as enabling event-level snapshots, instant cloning, and rollback to a saved state. The second is the credential vault from v0.4.0: agents call external APIs as usual, and the README states that keys never enter the sandbox. That second one is a design decision with real consequences. It means secrets live in a proxy outside the guest, so a compromised sandbox cannot read them, but it also means the outbound call path is mediated and anything that does not fit the proxy's model has to be handled differently.

Installing CubeSandbox and running a first sandbox

There is no single install command in the README. The repository ships a Makefile whose comments describe a unified builder image, and the build targets expect a Linux host with KVM available. The README points at docs/guide/quickstart.md for the quick start and at docs/guide/kubernetes/ for the Kubernetes path, so those two documents are where the real install steps live. What follows is the shape of the build, not a substitute for the quick start.

The Makefile exposes the builder image as a variable, so the first thing to know is that compilation happens inside a container rather than directly on your host. The defaults show the expected values.

Where CubeSandbox is the wrong tool

The most concrete limitation is the host. KVM is a Linux kernel facility, and the README describes a service built on RustVMM and KVM. A search for "cube sandbox macos" has no answer in this material: there is no macOS path documented in the README, and the Makefile's architecture handling covers x86_64 and aarch64 Linux builds. If your developers run agents on Macs, the sandbox is something they reach over the network, not something they run locally.

The second limitation is operational surface. Counting the top-level directories, this is a multi-service system with a control plane, a node agent, a template center, a networking layer, an egress layer, and a web dashboard. The README's v0.5.0 notes mention a Terraform one-click cluster deploy and the v0.6.0 notes mention Kubernetes deployment, so the project has invested in making deployment repeatable, but repeatable is not the same as small. Running CubeSandbox for a single developer's side project means running a distributed system to isolate one process.

The third is version maturity. The releases listed are v0.7.0 and its release candidates, with v0.7.1-rc1 as the most recent. The 0.x version number and the presence of release candidates at the head of the list are worth weighing if you need a stable API contract. The README also flags cross-node sandbox creation from snapshots as a preview in the v0.7.0 notes, so that particular capability is explicitly not finished.

CubeSandbox compared with E2B and with container-based sandboxes

The comparison the project invites is with E2B, and the README makes the relationship explicit: CubeSandbox is compatible with the E2B SDK. That compatibility is the adoption argument. If your agent code already calls an E2B client, the sandbox backend can change without rewriting the agent. The difference is in who operates the isolation. E2B is a hosted sandbox service; CubeSandbox is software you deploy on hosts you control, which is what makes the E2B-compatible API surface valuable rather than redundant. You get a migration path without a rewrite.

The comparison with container-based sandboxes is a different axis. A container shares the host kernel, so a kernel vulnerability is a boundary failure. CubeSandbox boots a guest kernel under KVM, so the boundary is the hypervisor. The cost is that you need KVM, a guest kernel image, and the machinery to manage both. The README's examples directory includes an e2b-dev-sidecar example, which suggests the project expects to sit alongside existing E2B-based tooling rather than replace it wholesale.

Among the related searches, OpenSandbox and Microsandbox appear as adjacent names. Neither project's internals are described in the CubeSandbox README, so the honest statement is that they occupy the same problem space, and choosing between them means evaluating each on its own documentation rather than on this one.

Licence, upgrade cost and what the release cadence implies

The repository metadata reports the licence as NOASSERTION, which means the automated classifier could not resolve it. At the same time, the README badge reads Apache 2.0, the LICENSE file is linked from the badge, and the Makefile carries an SPDX-License-Identifier: Apache-2.0 header with a Tencent copyright line. Those are strong signals that the intent is Apache 2.0, but the discrepancy between the metadata and the files is the kind of thing that blocks a corporate legal review until someone resolves it. Check the LICENSE file directly and get your own answer; this is not legal advice.

Upgrade cost is visible in the changelog structure. The project publishes a per-version changelog under docs/changelog/, and the v0.4.0 notes mention a dashboard that shows a version matrix and template health checks, specifically so you can see whether templates need rebuilding after an upgrade. That is a direct acknowledgement that upgrades touch templates, not just binaries. If you build custom templates, budget for rebuilding them across minor versions. The v0.3.0 snapshot engine, the v0.4.0 credential vault, the v0.5.0 AutoPause and network policy work, the v0.6.0 volume framework and template aliases, and the v0.7.0 cross-node pause/resume all landed within roughly three months, which is a fast-moving surface for anything you pin in production.

Editorial conclusion

Adopt CubeSandbox if you already write agents against the E2B SDK and want the execution tier on your own KVM-capable Linux hosts, with the option to scale from one node to a cluster later. Do not adopt it if your developers work on macOS laptops or you want a managed service with no host to run, because the README describes a deployment you operate yourself and the repository ships a Makefile and deploy scripts rather than a hosted endpoint. Verify two things before committing: that the licence file resolves to a licence you accept, since the repository metadata reports NOASSERTION while the README badge and Makefile headers point at Apache 2.0, and that the E2B API surface you depend on is actually implemented in the version you pin, because a compatible SDK is not the same as a complete one.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TencentCloud/CubeSandbox on GitHub