CubeSandbox Community Support: Architecture, Contributing, and Getting Help

CubeSandbox community support is available through GitHub Issues, Discord discussions, and the CONTRIBUTING.md guide, while the open-source platform provides sub-60ms AI agent sandboxes using KVM MicroVMs with an E2B-compatible SDK.

CubeSandbox is TencentCloud's open-source sandbox service designed for running AI agents in hardware-isolated environments. As an open-source project under the TencentCloud organization, it offers comprehensive CubeSandbox community support channels for developers who want to deploy, extend, or contribute to the MicroVM-based architecture.

Architecture Overview for Contributors

Understanding the codebase structure is essential before engaging with the CubeSandbox community support channels or submitting contributions.

Control Plane Components

The control plane manages cluster state and scheduling with no local state—Redis serves as the single source of truth for sandbox metadata. CubeAPI (CubeAPI/src/state.rs) functions as the Rust-based REST gateway handling rate limiting and service glue. CubeMaster, implemented in Go, operates as the cluster scheduler and lifecycle event publisher, coordinating node selection across the cluster.

Data Plane Components

The data plane handles VM lifecycle and isolation. Cubelet manages node-local operations, while CubeShim provides the containerd Shim v2 interface that bridges containerd to the MicroVM. The CubeHypervisor leverages RustVMM with KVM to manage vCPU, memory, and virtio devices, running with a minimal seccomp syscall whitelist.

Storage operations use CubeCoW (Cubelet/storage/cubecow_engine.go), which utilizes the Linux FICLONE ioctl on XFS for O(1) copy-on-write snapshots and clones without copying data.

Network and Security Stack

CubeVS implements eBPF-based virtual switching for per-sandbox SNAT/DNAT and policy enforcement, blocking private and link-local ranges by default. CubeEgress (located in CubeProxy/lua/) acts as an L7 MITM proxy built on OpenResty and Lua, enforcing domain allow-lists and injecting credentials via HTTP headers without storing secrets inside sandboxes.

Getting Help: CubeSandbox Community Support Channels

GitHub Issues and Discussions

The primary venue for CubeSandbox community support is the GitHub Issues tracker. Users can file bug reports regarding specific components like Cubelet/storage/pool.go or the CubeProxy Lua scripts, request features, and participate in architectural discussions. The maintainers monitor issues related to the RustVMM integration, storage engine, and network policies.

Real-Time Discord Chat

For immediate assistance, the project maintains an active Discord server where contributors discuss implementation details, troubleshooting, and roadmap planning. This channel is particularly useful for questions about the eBPF networking policies in CubeVS or XFS reflink operations in CubeCoW.

Contributing Code

Contributors should consult the CONTRIBUTING.md file for coding standards and PR procedures. The codebase spans multiple languages: Rust for CubeAPI and CubeShim, Go for CubeMaster and Cubelet storage logic, and Lua/OpenResty for the proxy and egress components. Key files to understand before contributing include CubeAPI/src/state.rs for application state management and CubeProxy/lua/utils.lua for proxy utilities.

Practical Usage Examples

Basic Sandbox Creation with Python

The E2B-compatible Python SDK allows instant sandbox creation against the CubeAPI endpoint:

from cubesandbox import Sandbox
from env import TEMPLATE_ID

# Create a sandbox from a pre-built template

sb = Sandbox.create(template=TEMPLATE_ID)

# Execute code inside the isolated MicroVM

result = sb.run_code("""print('Hello from CubeSandbox!')""")
print(result.logs.stdout[0])

sb.kill()

Snapshot and Clone Operations

The CubeCoW engine supports instant cloning via XFS reflink. This example from examples/snapshot-rollback-clone/clone_demo.py demonstrates memory and disk snapshotting:

from cubesandbox import Sandbox
from env import TEMPLATE_ID

src = Sandbox.create(template=TEMPLATE_ID)
src.run_code("open('/dev/shm/marker','w').write('hello')")  # RAM-only

src.run_code("open('/tmp/marker','w').write('hello')")       # Disk

# Create 3 concurrent clones

clones = src.clone(n=3, concurrency=3)

for i, c in enumerate(clones):
    out = c.run_code("""
        mem = open('/dev/shm/marker').read()
        disk = open('/tmp/marker').read()
        assert mem == 'hello' and disk == 'hello'
        print('clone OK')
    """)
    print(f'clone[{i}] →', out.logs.stdout[0])

src.kill()
for c in clones:
    c.kill()

Direct REST API Access

You can interact directly with the CubeAPI gateway without the SDK:

curl -X POST https://<cubeapi-host>/v1/sandboxes \
     -H "Authorization: Bearer <your-token>" \
     -d '{"template_id":"<TEMPLATE_ID>"}'

Key Source Files for Contributors

Understanding these critical files helps when seeking CubeSandbox community support or submitting patches:

• CubeAPI/src/state.rs: Defines shared application state, rate limiting, and service clients for the REST gateway.
• Cubelet/storage/pool.go: Implements node-local storage pool management and interacts with the CubeCoW engine.
• Cubelet/storage/cubecow_engine.go: Core logic for volume creation, cloning, and snapshotting using XFS reflink.
• Cubelet/storage/cubecow_snapshot_artifacts.go: Handles snapshot artifact management for the Copy-on-Write system.
• CubeProxy/lua/utils.lua: Utility functions for the OpenResty reverse proxy and egress handling.
• CubeProxy/lua/redis_keys.lua: Defines Redis keys used for sandbox metadata and routing tables.
• CubeProxy/lua/proxy_registry.lua: Reverse proxy routing logic using Redis metadata for sandbox traffic.

Summary

• CubeSandbox provides sub-60ms AI agent sandboxes using KVM MicroVMs with hardware-level isolation and E2B SDK compatibility.
• The architecture separates control plane (CubeAPI, CubeMaster) and data plane (Cubelet, CubeShim, CubeHypervisor) components, with Redis as the single source of truth.
• CubeSandbox community support is available via GitHub Issues, Discord chat, and the CONTRIBUTING.md guide for potential contributors.
• The CubeCoW storage engine uses XFS FICLONE for O(1) snapshots, while CubeEgress enforces zero-trust outbound traffic policies via OpenResty and Lua.
• Contributors should familiarize themselves with the Rust (CubeAPI/Shim), Go (CubeMaster), and Lua (Proxy) codebases, with key entry points in CubeAPI/src/state.rs and Cubelet/storage/cubecow_engine.go.

Frequently Asked Questions

How do I get help with CubeSandbox deployment issues?

For deployment troubleshooting, file a GitHub Issue with logs from the specific component (e.g., Cubelet or CubeProxy). For real-time assistance, join the Discord server where maintainers discuss operational issues. Always check the docs/architecture/overview.md file first to understand component interactions between the control plane and data plane.

What programming languages do I need to know to contribute to CubeSandbox?

The project uses Rust for the CubeAPI gateway and CubeShim containerd integration, Go for the CubeMaster scheduler and Cubelet storage logic in Cubelet/storage/pool.go, and Lua for the OpenResty-based CubeProxy and CubeEgress components. Understanding XFS reflink operations and eBPF networking is valuable for data plane contributions involving Cubelet/storage/cubecow_engine.go.

How does CubeSandbox isolation compare to container-based solutions?

CubeSandbox uses KVM MicroVMs running separate Linux kernels, providing hardware-level isolation rather than kernel-namespace isolation. This achieves stronger security boundaries at the cost of only a few megabytes of memory overhead per instance, with boot times under 60 milliseconds via pre-snapshotted templates restored through RustVMM.

Where can I find examples of using the CubeSandbox SDK?

Working examples are available in the examples/ directory, particularly examples/snapshot-rollback-clone/clone_demo.py, which demonstrates the CubeCoW snapshot and clone functionality. The Python SDK is E2B-compatible, allowing migration from other sandbox platforms while leveraging the hardware isolation of KVM MicroVMs.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}