CubeSandbox

CubeSandbox addresses the environment in which code runs. Your agent, model, application logic and authorization policy remain separate decisions. An SDK compatibility claim does not mean every feature of an existing application has been migration-tested. Project overview.

Evaluate it when you need controlled disposable execution for agent-generated work and can operate the host infrastructure. If you only want an agent to explain a file, you may not need a sandbox service at all. Start with a single-node trial before taking on a cluster or public endpoint.

The README quick-start path names an x86_64 Linux environment with KVM. Other parts of the repository describe ARM64 support, so treat the requirements of your chosen deployment guide as decisive rather than assuming one architecture statement covers every path.

Choose the official cloud-VM path or bare-metal path. These involve real host and network configuration; this page does not collapse them into an unverified one-line installer. Prepare a nonproduction host and follow the matching instructions.

After deployment

The console guide and README describe this sequence:

1. Open Overview and check that nodes are Ready.
2. Prepare an official preset through Template Store, or use an existing READY template.
3. Open Sandboxes → New sandbox and choose that template.
4. Inspect the sandbox details and execution logs.

The documented console URL uses the control-node address and port 12088. Confirm your deployment’s actual address and access controls instead of exposing that port broadly. A visible console is only the control-plane check; template readiness and sandbox execution are separate checks.

Use this editorial acceptance brief with the operator or agent that is authorized to manage your trial deployment:

Use only the designated nonproduction CubeSandbox deployment.
Confirm one node and one template are ready.
Create a disposable sandbox with the approved limits.
Run a trivial command that prints a unique test marker.
Return the sandbox ID, command output and actual exit status.
End the sandbox using the documented lifecycle operation.
Report its final state and any storage or other resources retained.
Do not provision paid hosts, expose new ports or access production data.

Match the returned marker to the command output, and check the sandbox ID against the console. Verify the final lifecycle state independently. If logs are absent or the sandbox remains active, the test is incomplete even if the agent reports success.

Only after that basic path works should you test the particular limits your application needs, such as timeouts or network policy. Record the actual deployment, template and workload when comparing results.

The project documents network policies, state management and a security proxy. Those are capabilities to configure and test for your workload; their presence does not establish that your current deployment blocks every unwanted action. Review security-proxy guidance.

Do not use headline startup benchmarks as a capacity plan. Host configuration, template state, concurrency and workload affect the result. This guide has not measured throughput, startup latency, memory overhead or escape resistance.

Snapshots and persistent volumes can outlive an individual run. Before calling a trial cleaned up, inspect retained resources under the lifecycle rules of the chosen deployment. Keep customer data and production credentials outside the first evaluation.