Tencent Cloud CubeSandbox: MicroVM Sandboxes for AI Agents in 60ms

⬅️ Back to Tools

Tencent Cloud CubeSandbox: MicroVM Sandboxes for AI Agents in 60ms

What it isA self-hosted sandbox service that boots one hardware-isolated MicroVM per agent task, driven through the E2B SDK
PlatformServer: x86_64 Linux with KVM (ARM64 supported); clients: anything speaking the E2B SDK
PriceFree, open source (Apache-2.0); you provide the server
Linkgithub.com/TencentCloud/CubeSandbox · cubesandbox.com

Every agent that runs code needs somewhere to run it. Docker shares the host kernel, so one escape ruins your day. Full VMs isolate properly and boot in seconds, which kills agent throughput. CubeSandbox is Tencent Cloud’s attempt at both: a dedicated kernel per sandbox, created in under 60 milliseconds. I read the README, the quickstart, and the examples end to end. I did not boot a live cluster (no KVM box here), so treat the performance numbers below as project-reported, with the test conditions attached.

  1. Each sandbox gets its own kernel in its own MicroVM. The stack is RustVMM plus KVM, standing on Cloud Hypervisor and Kata Containers lineage. Their comparison table frames it plainly: Docker isolates with shared-kernel namespaces, traditional VMs isolate with a dedicated kernel but boot slowly, Cube pairs the dedicated kernel with eBPF enforcement in CubeVS. That is the security story in one paragraph.
  2. The speed numbers come with footnotes, and I respect that. Single-concurrency cold start averages under 60ms on bare metal; at 50 concurrent creations it reports 67ms average with P95 at 90ms and P99 at 137ms. Resource pooling plus snapshot cloning skips cold-start work entirely. These are vendor benchmarks from June 2026, linked in the README, not independent measurements. Still, sub-150ms under load is the claim, and the methodology is published.
  3. Memory overhead is under 5MB per sandbox for specs up to 32GB, via kernel sharing and copy-on-write. That is what makes thousands of sandboxes per node plausible instead of aspirational. Idle sandboxes auto-pause and wake on the next request, which further stretches density. If your sandboxes are bigger than 32GB, the README admits overhead creeps up.
  4. The E2B compatibility is the reason to care this quarter. Your existing E2B SDK code runs unchanged; only three environment variables move: E2B_API_URL points at your CubeAPI, E2B_API_KEY stays a placeholder, CUBE_TEMPLATE_ID picks the template. I checked this against the quickstart and the OpenAI Agents SDK example. Migrating off E2B Cloud becomes a config change, not a rewrite.
  5. State management goes past pause and resume. CubeCoW gives event-level snapshots with instant clone and rollback to any saved state, and v0.7.0 added cross-node pause and resume backed by S3, so a sandbox suspended on one node wakes on another. Forking one sandbox state to explore options in parallel is the RL use case, and there is a mini-swe-agent training example proving it.
  6. Network security is genuinely layered. CubeVS does eBPF isolation between sandboxes at kernel level, CubeEgress filters L7 traffic with per-domain and per-method policies, and the credential vault injects secrets at the gateway so API keys never enter sandbox code. The examples cover air-gapped, allowlist, and denylist modes, plus per-sandbox tokens for public URLs. This is the part most sandbox projects leave as an exercise.
  7. It ships as a full stack, not a demo. A WebUI console on port 12088, a Template Store with official presets, Terraform one-click cluster deploy, Kubernetes deployment in preview, ARM64 support, a PyPI package, and an OpenAPI spec. Twenty-plus examples include Claude Code Bash redirection, a LangChain execution tool, an OpenClaw skill, headless Chromium over CDP, and an Ubuntu desktop in the browser. At 12.5k stars, this is one of the most watched agent-infra repos on GitHub.
  8. Honest limits. You need an x86_64 Linux host with KVM, which rules out running the server on a MacBook; the QEMU dev-environment exists but the README itself calls its performance poor, so budget a cloud VM. The roadmap admits E2B compatibility still has gaps to close and GPU sandboxes are not here yet. And it moves fast: v0.7.0 landed August 2026 across 964 commits, so pin versions before depending on it.

Install & first run

Deploy with Terraform or a standard cluster, then open the console:

http://<control-node IP>:12088

Overview, install a preset from the Template Store, then Sandboxes, New sandbox, pick a READY template. For code, create a template and point the SDK at your cluster:

cubemastercli tpl create-from-image \
  --image cube-sandbox-int.tencentcloudcr.com/cube-sandbox/sandbox-code:latest \
  --writable-layer-size 1G

export E2B_API_KEY=e2b_000000
export E2B_API_URL=http://<your-node-ip>:3000
export CUBE_TEMPLATE_ID=<template-id>
with Sandbox.create(template=template_id) as sandbox:
    sandbox.run_code("print('hello cube')")

Expected output is hello cube plus the interpreter version, and the sandbox deletes itself when the block exits. The quickstart’s troubleshooting table covers the four failures you will actually hit: missing CA cert, wrong template ID, unreachable CubeAPI on port 3000, and idle TTL. Everything beyond this is in the docs, which are unusually complete, in Chinese and English.

Worth your time if: agents run untrusted code on your behalf at real concurrency and Docker’s shared kernel is the thing keeping you up. Skip it if you need one local sandbox on a laptop, that is not this tool.

Related TMFNK Content

Crepi il lupo! 🐺