Each sandbox gets a dedicated guest kernel
CubeSandbox runs agent workloads in micro virtual machines built around KVM rather than in ordinary containers that share the host kernel. The external API creates sandboxes, runs commands, moves files, exposes services, and destroys the environment. Templates, cloning, pause and resume, snapshots, and rollback cover the lifecycle expected by coding agents and reinforcement-learning systems that execute many short-lived jobs. The E2B-compatible interface gives existing clients a possible migration path to self-hosted infrastructure.
The architecture is a platform, not one daemon. CubeAPI handles the external REST surface, CubeMaster schedules work, Cubelet manages each compute node, and CubeProxy routes inbound connections. CubeVS applies eBPF network isolation. CubeEgress enforces outbound rules and can inject credentials without placing them in the guest. CubeHypervisor and CubeShim manage microVMs through the container runtime. Each layer narrows a real problem, while every additional state transition creates another failure mode to test.
The first host must provide x86_64 Linux and KVM
The quick start requires an x86_64 Linux environment with KVM support. Documented routes cover a compatible cloud VM, bare metal, and a QEMU development environment that the project labels poor-performing. Installation then checks the web console on port 12088, confirms nodes are ready, obtains or builds a template, and creates the first sandbox. That is guided infrastructure setup, not a local package that works on any developer laptop.
Version 0.6.0 added Kubernetes deployment, an E2B-style volume framework, template aliases, node isolation, and a separate CubeOps service. Kubernetes support is explicitly preview. Alias creation also had SDK limits in that release, and the roadmap still lists remaining E2B compatibility, cross-node pause and resume, cross-node snapshot launch, fault recovery, and richer scheduling. Those are aspirations or active work, not current guarantees.
What happened when we ran it
Our sandbox installed 302 Rust packages in 41 seconds for the project under CubeAPI/. The build completed successfully in 108 seconds. Cargo test then passed all 120 tests in 43 seconds with 0 failures. The run used an unprivileged Debian container with 3 CPUs and 12 GB of RAM, without secrets. It verifies that the measured API component compiled and passed its available unit-level command in that environment.
The full checkout at commit 624e187 contained 3,256 files, roughly 614,804 lines of source, and 55.7 MB before packages. Our scan found 26 CI workflow files, a Dockerfile, and a tests directory. We did not boot KVM guests, create templates, attach volumes, exercise eBPF rules, or run a multi-node control plane. The clean 120-of-120 result should raise confidence in CubeAPI, not be stretched into a claim about a deployed sandbox cluster.
Plaintext credential injection has a concrete exfiltration report
CubeEgress can hold a secret outside the sandbox and add it only to matching outbound requests. That design protects against agent code simply reading an environment variable. Open issue 1410 identifies a dangerous exception: on the plaintext HTTP path, a sandbox can choose an attacker-controlled destination IP and spoof the expected Host header, causing the proxy to inject the operator credential toward that destination. The HTTPS path has certificate checks that change this result.
The report describes the default internet-access posture and traces the relevant proxy decisions. Until a released fix is verified, security-sensitive operators should prevent injected credentials from using plaintext HTTP, restrict destinations independently, and test the exact policy with an attacker-controlled endpoint. Hardware isolation does not help once an authorized proxy sends a secret out of the host. The credential system and microVM boundary solve different parts of the threat model.
E2B compatibility still has SDK edge cases
Issue 1484 reports that commands.run in the Node and Python SDKs forwards non-positive timeout values to the sandbox service. Both 0, which E2B uses for no deadline, and the exported NEVER_TIMEOUT value of -1 can lead to a generic transport timeout. The Go SDK handles those values differently. A team porting E2B code should test command deadlines, long-running jobs, cancellation, PTY sessions, file transfer, and reconnection across every chosen SDK.
A related lifecycle report, issue 1400, says setting a sandbox timeout to -1 calculates an end time in the past instead of representing no expiration. Issue 1521 describes an intermittent paused sandbox that could neither resume nor terminate on v0.6.0. These reports are not evidence that every pause or timeout fails. They identify exactly the operations that need soak tests and administrative recovery procedures before tenants depend on them.
Active maintenance accompanies a young operations surface
GitHub recorded 11,352 stars, 176 combined open issues and pull requests, and a last push on August 26, 2026. Version 0.6.0 shipped on July 24, and recent activity includes storage, networking, API, documentation, and security fixes. The project has moved quickly since its initial public release. That pace is encouraging, while long-term upgrade and recovery evidence is necessarily limited for a young control plane.
CubeSandbox belongs on the shortlist for a team that truly needs to run hostile or unpredictable agent code at scale. Its dedicated kernels, network layer, snapshots, and E2B-facing API address the right problems, and our CubeAPI build plus 120 passing tests give the code review a solid base. Adoption still means becoming a virtualization operator. Start on isolated hosts, pin a release, disable unsafe credential paths, and prove recovery from stuck sandboxes and failed nodes.