Why microsandbox
- Hardware isolation. Each sandbox is a VM, not a container namespace on the host kernel.
- Local runtime. The SDK starts the sandbox process directly. No daemon, remote service, or infrastructure setup.
- Fast startup. Sandboxes are lightweight enough to create from application code.
- OCI images. Use familiar images from Docker Hub, GHCR, ECR, GCR, or another OCI-compatible registry.
- Programmable controls. Configure resources, volumes, secrets, networking, and lifecycle from the CLI or SDK.
- Multi-language SDKs. Rust, TypeScript, Python, and Go expose the same core model.
What makes it different
Secrets stay on the host
Instead of putting real credentials inside the VM, microsandbox injects placeholders and swaps them for real values only when traffic goes to an allowed host. Code inside the sandbox can run freely without ever receiving the secret value itself.Network policy is host-controlled
All sandbox traffic flows through a host-side network stack. You can allow public internet access, block private networks, publish ports, deny by default, pin DNS behavior, or inspect TLS traffic without relying on guest cooperation.Filesystems are disposable or persistent by choice
Use OCI images for disposable roots, bind mounts for host data, named volumes for persistent state, tmpfs for scratch space, and snapshots when you want to reuse prepared sandbox state.Minimal example
Next steps
Quickstart
Install microsandbox and run your first sandbox.
Sandbox overview
Learn the core configuration model.
CLI overview
Manage sandboxes from the terminal.
SDK reference
Choose a language and look up the API surface.