“We are actually the team behind the CubeSandbox project. Over the past few months, as we scaled our internal AI Agents, we hit quite a few bottlenecks... — qinglin968 on Hacker News (https://news.ycombinator.com/item?id=47863430)”
You know that feeling when you let an AI agent execute code and you're not fully sure what it can actually reach on the host machine? Docker containers share the host kernel, so a container escape hands an attacker a much bigger blast radius than most people realize. CubeSandbox addresses this by giving every sandbox its own guest kernel via KVM microVMs, plus an egress gateway (CubeEgress) that injects API credentials into outbound calls so the sandbox — and the model's own context or logs — never sees your API keys directly.
You send a request to CubeAPI, a Rust-based REST gateway built to be compatible with the E2B protocol, which routes it to CubeMaster, the Go-based cluster orchestrator. CubeMaster picks a node and hands off to that node's Cubelet, which spins up a hardware-isolated microVM via CubeHypervisor — a dedicated guest kernel, not a shared one like Docker uses. Network traffic in and out of that microVM passes through CubeVS, an eBPF-based virtual switch that the architecture doc says handles all SNAT/DNAT and connection tracking without iptables or Linux bridges, and any outbound API call routes through CubeEgress, which injects your stored credentials at the edge so the sandbox never holds them directly. For fast snapshots and clones, CubeCoW uses the kernel's FICLONE ioctl so a rollback is a metadata operation, not a full disk copy.
If you're already building agent infrastructure on E2B and running enough volume that per-execution hosted pricing or data residency matters, this gives you a self-hostable drop-in speaking the same protocol. It's also relevant if you're evaluating microVM-based isolation for AI code execution and want the full orchestration stack (scheduler, networking, egress) instead of assembling one yourself on raw Firecracker or Cloud Hypervisor. It's not for you if you don't have a bare-metal or KVM-capable cloud VM available — there's no laptop or CI-runner trial path, and the README explicitly marks ...
It looks like an actively developed, early but serious project: Tencent says it ran internally before open-sourcing, it shipped v0.5.0 four days before this research with real feature additions, and the open issues (#790, #799) are edge-case bugs in new features rather than signs of a broken core. It's not yet stable by its own signals — ARM64/live-migration support is explicitly partial, there's no Node.js/TypeScript SDK, and independent discussion outside Tencent's own channels is thin (largest non-Tencent HN thread: 7 points). Treat it as beta-stage: worth a pilot if you're already deep in E2B-style sandboxing, not yet worth betting a production stack on without your own testing.
Deep-dive insight, Easy and Pro modes, plus action playbooks — the full breakdown is one tap away.