OpenSandbox

license

Apache-2.0(OSI)

source

public(Go execd + multi-language SDKs)

runtimes

Docker/Kubernetes

core-gated

ungated

Apache-2.0, fully self-hostable, with no managed or enterprise tier gating the core, which makes it open source rather than open core. Alibaba says it open sourced the sandbox infrastructure it uses internally. The repository has moved from the alibaba org to opensandbox-group, with the old URL redirecting to the new one. The untruncated tree is 2,642 entries with the whole product public - server/, components/, kubernetes/, cli/, sdks/, specs/ - carrying ten LICENSE paths, all Apache-2.0 copies beside per-SDK and per-component roots, and no ee/, enterprise/, commercial/ or proprietary/ path. open-sandbox.ai is a documentation site with no pricing page, no hosted offering and no sign-up, closing with "Released under the Apache 2.0 License", so there is no managed tier to gate against.

• https://github.com/alibaba/OpenSandbox recorded 2026-06-04

  Apache-2.0 license; general-purpose AI-agent sandbox; Docker/K8s runtimes; multi-language SDKs; self-host

• https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/main/LICENSE recorded 2026-08-13

  The verbatim Apache License 2.0, complete and with no appended notices, exceptions or additional terms.

• https://api.github.com/repos/opensandbox-group/OpenSandbox/git/trees/main?recursive=1 recorded 2026-08-13

  Untruncated recursive tree, 2,642 entries. Ten LICENSE paths, all Apache-2.0 copies of the root placed beside the CLI, the server and each SDK. The whole product is public - server/, components/, kubernetes/, cli/, sdks/, specs/, sandboxes/ - and there is no ee/, enterprise/, commercial/ or proprietary/ path.

• https://api.github.com/repos/opensandbox-group/OpenSandbox recorded 2026-08-13

  Repo metadata - license spdx_id Apache-2.0, default branch main, not archived, pushed 2026-08-13, homepage open-sandbox.ai. The repository now lives under the opensandbox-group org; the alibaba/OpenSandbox path redirects here and returns an identical body.

• https://open-sandbox.ai recorded 2026-08-13

  The project site is documentation only - getting started, guides, SDK and API references, specs, CLI, components, Kubernetes and migration guides. It offers no hosted service, pricing page, sign-up or enterprise edition, and its footer reads "Released under the Apache 2.0 License."

12,522 stars and 1,056 forks on the one declared repo, which falls in the >10K star band - the highest level a star-based reading can reach, since a star is not a download. The project is only months old and no download or named-deployment figure has surfaced, so stars are the only signal: rapid early accumulation (3,845 within 72h of launch) with no usage volume behind it yet. A star count moves daily, so the figure is a snapshot; the band depends only on its order of magnitude. One gap is worth naming: a Python SDK is now published on PyPI as `opensandbox`, so a countable channel exists that this record does not yet measure.

• https://github.com/alibaba/OpenSandbox recorded 2026-06-04

  11.3k GitHub stars; released Mar 2026; no usage/download figures

• https://api.github.com/repos/opensandbox-group/OpenSandbox recorded 2026-08-13

  Repo metadata - 12,522 stars, 1,056 forks, 51 watchers, pushed 2026-08-13. Bands at >10K stars, level 3 on the stars scale in signal_routing.yaml.

Secure runtime support is shipped rather than proposed, which is what puts this at 4 rather than at container-only isolation: the server’s runtime resolver holds a Docker map (gvisor to runsc, kata to kata-runtime) and a Kubernetes RuntimeClass map (gvisor to gvisor, kata to kata-qemu, firecracker to kata-fc), plus startup validation, under OSEP-0004 "Pluggable Secure Container Runtime Support" at status implementing. A gVisor end-to-end suite with its own RuntimeClass fixtures, and an AKS plus Kata deployment walkthrough with a matching example directory, corroborate that the code is real rather than planned. Two things keep it from going higher. OpenSandbox explicitly does not install the runtimes - an OSEP non-goal - so the microVM tier depends on operator-supplied infrastructure, and one server supports exactly one runtime at a time. And there is no independent latency measurement: the only figures are the OSEP’s own planning estimates (~550ms for gVisor, ~625ms for Kata and Firecracker). That leaves it level with daytona-sandbox, which scores 4 on the same shape - container by default, VM classes opt-in - on a weaker openness story.

• https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/main/server/opensandbox_server/services/runtime_resolver.py recorded 2026-08-14

  SecureRuntimeResolver as shipped code: Docker runtime map (gvisor -> runsc, kata -> kata-runtime) and Kubernetes RuntimeClass map (gvisor, kata-qemu, kata-fc), with startup validation - the VM/microVM tier.