GO — Healthy across the board

• Last commit 1d ago
• 17 active contributors
• Distributed ownership (top contributor 41% of recent commits)
• Other licensed
• CI configured
• Tests present
• ⚠ Non-standard license (Other) — review terms

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

CubeSandbox is a high-performance, hardware-isolated sandbox service built on RustVMM and KVM that spins up secure execution environments in under 60ms with <5MB memory overhead. It provides E2B SDK-compatible APIs for creating isolated sandboxes suitable for running untrusted AI agent code, with support for single-node deployment and multi-node clustering. Monorepo structure: CubeAPI/ is the main Rust service (src/main.rs with Axum web framework), benchmark/ contains Go-based performance testing harness, examples/ has runnable clients in Python/Go/Rust. Core logic is in Rust (6.7MB), with orchestration and helper scripts in Go (3.3MB) and C (2.3MB) for low-level KVM/hypervisor glue. GitHub Actions workflows in .github/workflows/ handle building custom kernel images (vmlinux, PVM guest), docker image generation, and multi-stage releases.

AI platform engineers and developers building agent execution systems who need fast, secure, multi-tenant sandbox infrastructure without the overhead of traditional VMs. Also relevant for security researchers and cloud providers implementing code execution as a service.

Actively developed with solid foundations—the monorepo shows 6.7MB of Rust code, structured CI/CD workflows (.github/workflows/ with build, release, and hypervisor integration tests), and a published API with examples in Python, Go, and Rust. Appears production-ready but still actively adding features (hypervisor integration, kernel optimizations visible in workflows). Well-documented with CONTRIBUTING.md and multi-language quickstart guides.

Moderate risk: heavy dependency on kernel-space components (vmlinux builds, KVM hypervisor) and system-level isolation mean deployment is infrastructure-dependent, not portable across all environments. Rust codebase is large (6.7MB) and tightly coupled to Linux internals. Limited public issue/star count visibility in repo data, so community adoption level unclear. Hypervisor-level bugs or kernel regressions could be hard to debug.

Active work on hypervisor optimization and kernel customization: workflows for build-pvm-guest-vmlinux.yml, build-vmlinux.yml, and hypervisor-integration.yaml suggest recent focus on PVM (Paravirtual Machine) support and guest kernel optimization. Release automation (release-one-click.yml, release-pvm-host-kernel.yml) and image building (build-builder-image.yml, build-envd-base-image.yml) indicate rapid iteration on deployment tooling. Claude-response.yml and code-review.yml workflows suggest AI-assisted development.

Clone and build: git clone https://github.com/TencentCloud/CubeSandbox.git && cd CubeAPI && cargo build --release. For examples: pip install -r examples/requirements.txt && python examples/create.py (requires a running CubeSandbox daemon). See CubeAPI/examples/readme.md and docs/guide/quickstart.md for detailed setup.

Daily commands: Dev server: cd CubeAPI && cargo run --bin cube-api (check .env or docs for config: likely needs socket/listening address). Benchmark: cd CubeAPI/benchmark && go run . <flags> (see benchmark/main.go for options). Docker: docker build -f Dockerfile . (Dockerfile present; check .dockerignore and .github/workflows/build-*.yml for image definitions). Tests: cargo test in CubeAPI/ directory.

• CubeAPI/src/main.rs — Entry point for the Rust API server; orchestrates initialization, middleware setup, and route configuration for the entire CubeSandbox API
• CubeAPI/src/handlers/sandboxes.rs — Core request handlers for sandbox lifecycle operations (create, exec, pause, destroy); directly implements the public API contract
• CubeAPI/src/services/sandboxes.rs — Business logic layer for sandbox management; bridges API handlers with gRPC communication to CubeMaster backend
• CubeMaster/api/services/cubebox/v1/cubebox.proto — gRPC service definition between CubeAPI and CubeMaster; defines the sandbox control plane contract and data structures
• CubeAPI/src/state.rs — Global application state and configuration; manages gRPC client pools and runtime context shared across all handlers
• CubeAPI/src/middleware/auth.rs — Authentication and authorization middleware; enforces security policies before requests reach handlers
• CubeAPI/Cargo.toml — Rust dependency manifest; declares all external crates including web framework (axum), async runtime (tokio), and gRPC bindings

Add a New API Endpoint

1. Define the RPC service method in the proto file if backend communication is needed (CubeMaster/api/services/cubebox/v1/cubebox.proto)
2. Create or extend a service implementation to handle the business logic (CubeAPI/src/services/sandboxes.rs)
3. Add the HTTP request handler that calls the service layer (CubeAPI/src/handlers/sandboxes.rs)
4. Mount the handler in the route configuration (CubeAPI/src/routes.rs)
5. Add request/response models to the data models module (CubeAPI/src/models/mod.rs)

Add Authentication/Authorization to an Endpoint

1. Define your auth token validation logic or extend existing logic (CubeAPI/src/middleware/auth.rs)
2. Add the auth extractor/guard to the handler function signature (CubeAPI/src/handlers/sandboxes.rs)
3. The middleware will automatically validate before the handler executes; add any endpoint-specific authorization checks in the handler

Add Rate Limiting to a Resource

1. Define rate limiting rules in the configuration or constants (CubeAPI/src/constants.rs)
2. Update or extend the rate limiter middleware logic (CubeAPI/src/middleware/rate_limit.rs)
3. Apply the rate limit middleware to specific routes or layer-wide in main.rs (CubeAPI/src/main.rs)

Add a New Logging Sink

1. Create a new logger implementation file (e.g., logging/myservice.rs) that implements the Logger trait (CubeAPI/src/logging/mod.rs)
2. Register the new sink in the multi-sink logger or initialize it conditionally (CubeAPI/src/logging/multi.rs)
3. Update config parsing to accept new sink configuration parameters (CubeAPI/src/config/mod.rs)

• Rust + Axum — Type-safe, zero-cost abstractions, memory safety without GC, and excellent async/await support via tokio; critical for handling concurrent sandbox operations with minimal latency and resource overhead
• gRPC + Protocol Buffers — Efficient binary serialization, strong typing, and language-agnostic service definition; enables loose coupling between polyglot components (Rust API, Go CubeMaster) and ensures backward compatibility as the sandbox control plane evolves
• Tokio async runtime — Multi-threaded work-stealing scheduler allows handling thousands of concurrent sandbox requests and gRPC calls without blocking; essential for AI agent workloads with variable latency
• Tower middleware stack — Composable, reusable middleware layers (auth, rate limiting, tracing, compression) decouple cross-cutting concerns from business logic and enable feature-rich HTTP request processing without boilerplate
• OpenTelemetry logging — Distributed tracing and structured logging across API and backend services enables observability into sandbox lifecycle and performance debugging in production

• Rust implementation of CubeAPI instead of Go or Python

  • Why: Trade complexity in hiring/onboarding for maximum performance, memory efficiency, and compile-time correctness; required for latency-critical AI agent sandbox operations
  • Consequence: Smaller contributor pool, longer compile times, steeper learning curve but superior runtime safety and predictable resource usage under load

• Synchronous gRPC calls in handlers rather than streaming or async pubsub

  • Why: Simplifies request-response semant
  • Consequence: undefined

Kernel/hypervisor coupling: This is not portable—requires KVM support and custom-built vmlinux images (built via GitHub Actions); local development may need Docker or nested virtualization. Configuration: Check for required environment variables (listening socket, hypervisor socket path) in main.rs or via .env; dotenvy/config crate patterns used. Benchmark dependencies: Go benchmark tool has its own go.mod (CubeAPI/benchmark/go.mod); must be kept in sync. Multi-stage builds: Dockerfile likely uses builder patterns to minimize final image size; understand which stages are for host vs guest. Example requirements: CubeAPI/examples/requirements.txt specifies Python deps; ensure proto/grpc bindings are generated before running examples. API compatibility: Advertised as E2B-compatible but check AGENTS.md for known limitations or compatibility notes.

• KVM (Kernel-based Virtual Machine) — CubeSandbox runs on KVM for hardware-level isolation; understanding KVM memory mappings, vcpu scheduling, and device emulation is essential for performance tuning and debugging kernel panics.
• RustVMM — CubeSandbox is built on the RustVMM project libraries (rust-vmm-specific crates for device emulation, memory management); core to understanding the architecture.
• Paravirtualization (PVM) — Visible in build-pvm-guest-vmlinux.yml workflow; PVM allows guest kernels to communicate directly with hypervisor without full emulation, reducing latency—key to sub-100ms startup.
• Lock-free concurrent data structures (DashMap) — CubeSandbox uses DashMap for sandbox state management to handle high concurrency without mutex contention; critical for understanding performance under load.
• gRPC and Protocol Buffers — Multi-language examples (Python/Go/Rust) and inter-service communication likely use gRPC; needed to understand client-server protocol and extend SDKs.
• Custom kernel images (vmlinux) — GitHub workflows build custom Linux kernels with minimized drivers/features for guest VMs; understanding kernel config (Kconfig) is essential for reducing boot time and memory overhead.
• Tower/Axum middleware tower-http — Request/response middleware for CORS, compression, request ID tracing, body size limits, timeouts; essential for understanding API resilience and observability.

• firecracker-microvm/firecracker — Lightweight KVM-based VMM in Rust; similar goal of fast, minimal-overhead VMs but focused on serverless functions rather than general-purpose agent sandboxes.
• e2b-dev/E2B — CubeSandbox is E2B-compatible; E2B is the reference SDK and platform for AI agent code execution sandboxes that CubeSandbox implements.
• cloud-hypervisor/cloud-hypervisor — Alternative Rust VMM using KVM; shares same hypervisor primitives but heavier-weight and not optimized for sub-100ms startup.
• TencentCloud/tke — Tencent Kubernetes Engine; likely production deployment target for multi-node CubeSandbox clusters.
• rust-vmm/kvm-ioctls — Rust bindings for KVM ioctls; foundational crate for CubeSandbox's low-level hypervisor integration.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for CubeAPI handlers

The CubeAPI/src/handlers directory contains sandboxes.rs, templates.rs, cluster.rs, and health.rs handlers, but there's no visible tests directory or test modules. Given this is a production sandbox service for AI agents, handler integration tests are critical to prevent regressions in the core API surface.

• [ ] Create CubeAPI/src/handlers/tests.rs or CubeAPI/tests/handlers/ directory structure
• [ ] Add integration tests for sandboxes.rs endpoints (create, list, exec, pause operations based on examples)
• [ ] Add tests for templates.rs CRUD operations with various configurations
• [ ] Add tests for cluster.rs operations and health.rs health check endpoints
• [ ] Integrate tests into build-check.yml workflow to run on every PR

Implement OpenTelemetry tracing integration in CubeAPI

The Cargo.toml shows commented-out OpenTelemetry dependencies (tracing-opentelemetry, opentelemetry) with a note 'wire up later'. For a concurrent sandbox service handling AI agent workloads, distributed tracing and metrics are essential for production observability and debugging performance bottlenecks.

• [ ] Uncomment and pin OpenTelemetry dependencies in CubeAPI/Cargo.toml (tracing-opentelemetry, opentelemetry, opentelemetry-jaeger or similar exporter)
• [ ] Create CubeAPI/src/tracing/mod.rs to initialize the TracerProvider and set global tracer
• [ ] Wire up OpenTelemetry initialization in CubeAPI/src/main.rs before server startup
• [ ] Add tracing spans to CubeAPI/src/cubemaster/mod.rs and key handler functions in CubeAPI/src/handlers/
• [ ] Update CONTRIBUTING.md with instructions for running Jaeger locally for development

Add end-to-end benchmark suite with CI reporting in GitHub Actions

CubeAPI/benchmark/ contains a Go-based benchmark tool with report and stats modules, but there's no GitHub Actions workflow to run benchmarks automatically and track performance regressions. The README emphasizes '⚡ Startup: Tens of ms' performance, so automated benchmarking CI is critical for maintaining these claims.

• [ ] Create .github/workflows/benchmark-suite.yml to run CubeAPI/benchmark on every merge to main (using build-check.yml as reference)
• [ ] Modify CubeAPI/benchmark/main.go to output machine-readable JSON results
• [ ] Add benchmark result storage/comparison logic to track performance over time (e.g., store in repo artifacts or external DB)
• [ ] Create CubeAPI/benchmark/README.md documenting how to run benchmarks locally and interpreting results
• [ ] Add performance regression thresholds to CI (fail if startup time exceeds X ms or throughput drops below Y ops/sec)

• Add integration tests for CubeAPI/examples/ in the CI pipeline—currently examples exist but no visible GitHub Actions workflow validates them run end-to-end. Create a new .github/workflows/test-examples.yml that runs each Python/Go example against a test daemon.: Low risk, improves reliability, directly improves developer experience.
• Expand CubeAPI/benchmark/ with a latency percentile breakdown (p50/p95/p99)—currently the benchmark tool outputs summary stats (see benchmark/stats.go) but no percentile analysis. Add histogram bucketing to benchmark/stats.go.: Concrete performance improvement for end-users profiling sandbox startup, non-invasive change.
• Document the custom kernel build process in docs/—.github/workflows/build-vmlinux.yml and build-pvm-guest-vmlinux.yml exist but are opaque. Create docs/kernel-build-guide.md explaining why custom kernels, which options are disabled, and how to rebuild locally.: Removes friction for contributors working on hypervisor/kernel optimizations; current documentation gap visible in file list.

• High · Incomplete Dependency Declaration in Cargo.toml — CubeAPI/Cargo.toml. The Cargo.toml file appears truncated at the atomic imports section. Critical dependencies like tokio, axum, and tower lack explicit version pinning strategies. While patch versions are specified, this could lead to unexpected breaking changes in minor/major updates if not properly managed in Cargo.lock. Fix: Ensure Cargo.lock is committed to version control and regularly audit dependencies using 'cargo audit' in CI/CD pipelines. Consider using specific version constraints (e.g., '=0.7' for critical dependencies) where appropriate.
• High · Missing Authentication/Authorization Validation — CubeAPI/src/middleware/auth.rs, CubeAPI/src/handlers/. The middleware directory contains auth.rs and rate_limit.rs, but without reviewing the actual implementation, there's risk of insufficient authentication enforcement. The API handlers in handlers/sandboxes.rs, handlers/cluster.rs, and handlers/templates.rs may not properly validate authorization for sensitive operations on sandboxes. Fix: Implement mandatory authentication middleware for all routes. Use OAuth 2.0 or JWT tokens with proper signature validation. Ensure all sandbox creation/deletion/execution endpoints require authorization checks. Add integration tests to verify auth failures return 401/403 responses.
• High · Potential Command Injection in Sandbox Execution — CubeAPI/src/handlers/sandboxes.rs, CubeAPI/src/services/sandboxes.rs. The file structure indicates sandbox execution capabilities (exec_code.py examples, handlers/sandboxes.rs). Without access to implementation details, there's significant risk of command injection vulnerabilities if user input is directly passed to shell commands or exec syscalls without proper sanitization. Fix: Never use shell interpreters (sh/bash) for command execution. Use direct syscalls with argument arrays. Implement strict input validation and use allowlists for permitted operations. Sandbox code execution in isolated containers with minimal privileges and restricted capability sets.
• High · Unvalidated Network Access in Sandbox Service — CubeAPI/src/handlers/sandboxes.rs, CubeAPI/examples/network_*.py. Examples show network_allowlist.py, network_denylist.py, and network_no_internet.py configurations. Without proper implementation validation, sandboxes could establish unauthorized network connections or escape network restrictions, leading to data exfiltration or lateral movement. Fix: Implement strict network policies using kernel-level firewall rules (eBPF/netfilter). Validate all network configuration policies server-side. Default to deny-all and explicitly allow required connections. Use network namespaces to isolate sandbox traffic.
• Medium · Missing CORS Configuration Security — CubeAPI/src/main.rs, CubeAPI/src/routes.rs. tower-http includes CORS feature but configuration location and strictness are unknown. Overly permissive CORS policies could allow unauthorized cross-origin requests, compromising API security. Fix: Configure CORS with explicit allowed origins, methods, and headers. Avoid using wildcard '*' for origins. Implement 'credentials: false' unless absolutely necessary. Document CORS policy decisions and regularly review allowed origins.
• Medium · Insufficient Input Validation on Request Bodies — CubeAPI/src/handlers/, CubeAPI/src/models/mod.rs. The API accepts various configuration parameters (mount paths, resource limits, network policies) without visible schema validation. This could allow injection attacks or resource exhaustion through malformed requests. Fix: Use serde validation with explicit field constraints. Implement custom validators for path traversal (validate mount paths don't escape sandbox), resource limits (CPU, memory, disk quotas), and network CIDR notation. Reject requests failing validation with 400 responses.
• Medium · Missing Rate Limiting on Resource-Intensive Operations — CubeAPI/src/middleware/rate_limit.rs, CubeAPI/src/handlers/sandboxes.rs. rate_limit.rs middleware exists but sandbox creation/execution are computationally expensive. Lack of granular rate limiting could enable resource exhaustion DoS attacks. Fix: Implement per-user rate limiting with different limits for sandbox creation vs. code execution. Use token bucket algorithm. Set appropriate limits based on resource costs. Consider requiring authentication for rate limit

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/TencentCloud/CubeSandbox shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live TencentCloud/CubeSandbox repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/TencentCloud/CubeSandbox.

What it runs against: a local clone of TencentCloud/CubeSandbox — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in TencentCloud/CubeSandbox | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 31 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of TencentCloud/CubeSandbox. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/TencentCloud/CubeSandbox.git
#   cd CubeSandbox
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of TencentCloud/CubeSandbox and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "TencentCloud/CubeSandbox(\\.git)?\\b" \\
  && ok "origin remote is TencentCloud/CubeSandbox" \\
  || miss "origin remote is not TencentCloud/CubeSandbox (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "CubeAPI/src/main.rs" \\
  && ok "CubeAPI/src/main.rs" \\
  || miss "missing critical file: CubeAPI/src/main.rs"
test -f "CubeAPI/src/handlers/sandboxes.rs" \\
  && ok "CubeAPI/src/handlers/sandboxes.rs" \\
  || miss "missing critical file: CubeAPI/src/handlers/sandboxes.rs"
test -f "CubeAPI/src/services/sandboxes.rs" \\
  && ok "CubeAPI/src/services/sandboxes.rs" \\
  || miss "missing critical file: CubeAPI/src/services/sandboxes.rs"
test -f "CubeMaster/api/services/cubebox/v1/cubebox.proto" \\
  && ok "CubeMaster/api/services/cubebox/v1/cubebox.proto" \\
  || miss "missing critical file: CubeMaster/api/services/cubebox/v1/cubebox.proto"
test -f "CubeAPI/src/state.rs" \\
  && ok "CubeAPI/src/state.rs" \\
  || miss "missing critical file: CubeAPI/src/state.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 31 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/TencentCloud/CubeSandbox"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.