LIFEHUBBER
Theme

AI Resources

CubeSandbox

GitHub stars: 12.1K GitHub forks: 1.1K Last pushed September 11, 2026: Pushed today
Stats from GitHub

CubeSandbox is TencentCloud sandbox infrastructure for AI agents, built around KVM MicroVMs, E2B-compatible code execution, templates, snapshots, and self-hosted runtime management.

The August 2026 v0.7.0 release adds preview S3-backed cross-node pause and resume, component version tracking for templates and snapshots, a networking refactor intended to reduce provisioning work, and a separate operations layer for node management. It builds on v0.6.0's E2B-compatible Volume framework and preview Kubernetes deployment. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.

What it is

A sandbox service for agent execution

CubeSandbox is presented as runtime infrastructure where agents can run code in Linux sandboxes through an E2B-compatible API, rather than as a ready-made assistant product.

Why it stands out

Runtime lifecycle, not only launch speed

CubeSandbox combines KVM MicroVMs, prebuilt templates, snapshot and clone workflows, egress controls, and lifecycle management. Current releases extend that design with an E2B-compatible Volume framework, preview Kubernetes deployment, component-aware upgrades, and preview S3-backed cross-node pause and resume.

Availability

Public repo with self-hosted deployment path

The official repo and docs include releases, quick-start instructions, architecture notes, examples, WebUI materials, Python, Node.js, and Go SDKs, plus standalone, Tencent Cloud, and preview Kubernetes deployment paths. The quick start remains a technical server setup with root access, Linux/KVM or PVM, XFS storage, and disk requirements to review.

Why it matters

What makes it useful

If an agent can run code, install packages, expose services, or call outside APIs, the runtime becomes part of the trust boundary. CubeSandbox shows one concrete design intended to separate agent execution from the host while still supporting templates, snapshots, lifecycle controls, and E2B-compatible code-interpreter workflows.

Notable points

What stands out

CubeSandbox reports that v0.7.0 separates node operations from the control plane, tracks component versions so older templates and snapshots can survive upgrades, and refactors networking to reduce provisioning work and prevent stale rules. Cross-node pause and resume currently depends on an S3 backend and remains a preview feature, so readers should test upgrade, recovery, storage, and network behavior in their own environment.

Before using

What to review

The server requirements in the official quick start, including root access, Linux, glibc support, KVM or PVM path, XFS-backed storage for the /data/cubelet path, disk space, and the correct x86_64 or ARM64 deployment route.

The production and network exposure path before relying on it: authentication, public routes, egress policy, traffic tokens, secrets handling, audit logs, and the project docs around network hardening.

The current compatibility notes for templates, snapshots, component versions, volume backends, Kubernetes nodes, and compute-node rebuilds before upgrading an existing installation.

The project-reported benchmark, isolation, startup, memory, and E2B-compatibility claims on the reader's own hardware or cloud setup.

The TencentCloud Terraform path separately from the core project, because that deployment route may affect cloud fit, operating cost, and provider dependency.

Reader fit

Who may find it relevant

Technical readers building coding agents, code-interpreter services, or automation systems that need a self-hosted place for model-generated code and tool runs.

Infrastructure builders comparing MicroVM-based agent sandboxes against container-only runtimes, hosted code interpreters, or other sandbox platforms.

Teams that need lifecycle controls such as pause, resume, snapshot, clone, rollback, volume workflows, templates, and network egress policy around agent workloads.

Less relevant for readers focused mainly on model releases or consumer-facing assistant products.

Editorial note

Why LifeHubber lists it

Once agents execute code, the practical decision is where that code runs, how it pauses or forks, and what network and secrets boundary surrounds it. CubeSandbox puts those decisions in one public runtime design instead of leaving them as vague sandbox promises.

Source links

Source materials

Reader note

Before relying on this entry

LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.

What to explore next

Compare the sandbox with the wider runtime around it.

CubeSandbox focuses on a MicroVM-based sandbox design and lifecycle controls. These paths help compare a broader agent sandbox surface and environments built for training and evaluation.

Advertisements

Advertisements

For project maintainers

Listed here? You can use the badge.

If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.

See what’s moving