Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.microsandbox.dev/llms.txt

Use this file to discover all available pages before exploring further.

AI agents run with whatever privileges you give them, and most of the time that’s too many. They can see host environment variables, reach the network freely, and modify files wherever the process is allowed to write. A prompt injection turns those privileges into attack surface. microsandbox gives each workload its own local microVM: a real Linux kernel, isolated filesystem, and host-controlled network stack. It keeps the developer loop simple while moving untrusted code out of the host process.
Boot a microVM in one command.
npx microsandbox run debian

​
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

use microsandbox::Sandbox;

let sb = Sandbox::builder("hello")
    .image("python")
    .create()
    .await?;

let output = sb.exec("python", ["-c", "print('Hello from a microVM!')"]).await?;
println!("{}", output.stdout()?);

sb.stop().await?;

​
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.