msb CLI or an SDK, or run it on microsandbox cloud with an API key. From there, what you do inside the sandbox is up to you.
It keeps the familiar workflow of OCI images and command execution, while moving risky work out of the host process.
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.
- Cloud when you want it. The same SDK and CLI run sandboxes on hosted infrastructure; an API key is the only change.
- Fast startup. Sandboxes are lightweight enough to create from application code.
- Docker-like inputs. Use familiar OCI images from Docker Hub, GHCR, ECR, GCR, or another 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.
Example use cases
- AI agents. Give coding agents and tool-using assistants a dedicated machine for commands, files, package installs, and generated code.
- User code execution. Run submitted scripts, notebooks, plugins, and extensions away from the host.
- CI/CD and builds. Isolate test jobs, compilers, package managers, and build tools.
- Dev environments. Create disposable Linux machines without touching your laptop or host Docker daemon.
- Scrapers and automation. Allow internet access while blocking private networks and metadata services.
- Secure tool execution. Run CLIs and dependencies that should not see host secrets or ambient credentials.
Minimal example
Next steps
Quickstart
Install microsandbox and run your first sandbox.
microsandbox cloud
Run the same sandboxes on hosted infrastructure.
CLI overview
Manage sandboxes from the terminal.
SDK reference
Choose a language and look up the API surface.