Mango

Sandboxes

The self-hosted execution boundary and Docker reference worker.

Edit on GitHub

Mango has one execution mode: self_hosted. The control plane coordinates the agent loop and leases Environment Work; an operator-run worker executes shell and file tools in infrastructure chosen and trusted by that operator.

Mango does not operate a shared cloud sandbox fleet and the control plane does not import provider SDKs. Docker is the OSS reference launcher, not a public Environment type or a control-plane provider setting.

Execution boundary

Mango control plane
  Environment Work + Session events + correlated results
                         |
Mango SDK worker protocol
  Poll -> Ack -> Heartbeat -> execute -> Send result -> Stop
                         |
Operator launcher
  Docker today; another isolated compute service may be added later

The worker owns container credentials, filesystem preparation, workspace retention, egress policy, and cleanup. Mango owns durable Session state, permission decisions, Work lease fencing, result correlation, retries, and recovery.

The first-party Docker launcher creates a named workspace volume per Session by default, or binds an operator-owned directory selected with --workspace-root, and runs each activation in a container. The control-plane API and Temporal worker do not mount the Docker socket.

Tool ownership

CapabilityOwner
bash, read, write, edit, glob, grepEnvironment worker
Skill bundle and Memory Store preparationEnvironment worker through scoped Session APIs
Web Search and Web FetchSupporting model endpoint
Remote MCPMango orchestration worker
Work lease, approvals, event history, result journalMango control plane

File API objects and Git repository declarations are not automatically mounted in a self-hosted workspace. Stage them through the operator's launcher or clone them from inside the sandbox under the operator's network and credential policy. Memory Stores are the supported Session Resource type; immutable Skill pins are also prepared by the worker.

Why provider launchers stay outside the control plane

The public CMA self-hosted cookbook demonstrates Docker and several commercial compute platforms, but the protocol remains the same: operator code launches compute and runs the generic worker there. Mango follows that separation. A future Daytona, Modal, Cloudflare, Vercel, Kubernetes, or sandbox-service example should adapt the launcher, not add a provider enum or provider credentials to Mango's API.

This keeps the self-hosted trust boundary honest and leaves room to add a Mango- hosted product later as a separate backend without preserving the removed pre-release registry.

Run the Docker reference

Follow Self-hosted worker. The supervisor uses a Environment-scoped API key plus its Environment ID to poll Work. Each claimed item yields a short-lived, Session-scoped credential used inside the container; the Environment key is not passed into the Session container.

For lifecycle and recovery details, see Self-hosted workers and Environment Work.

Verify execution before starting a Session

Create an Environment healthcheck with a Workspace key, then let the ordinary supervisor claim it. The reference Docker worker executes a fixed, ten-second process/filesystem probe in an ephemeral workspace and records its result on Work. This requires no Agent, Session, or model credentials. Queue statistics alone only establish polling.

On this page