Back to Microsandbox

Introduction

docs/getting-started/introduction.mdx

0.5.43.6 KB
Original Source

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.

<Tip> Boot a microVM in one command.
bash
npx microsandbox run debian
</Tip>

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

<CodeGroup> ```rust Rust 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?;


```typescript TypeScript
import { Sandbox } from "microsandbox";

await using sb = await Sandbox.builder("hello")
    .image("python")
    .create();

const output = await sb.exec("python", ["-c", "print('Hello from a microVM!')"]);
console.log(output.stdout());
python
from microsandbox import Sandbox

sb = await Sandbox.create("hello", image="python")

output = await sb.exec("python", ["-c", "print('Hello from a microVM!')"])
print(output.stdout_text)

await sb.stop()
go
sb, err := m.CreateSandbox(ctx, "hello", m.WithImage("python"))
if err != nil {
    return err
}
defer sb.Stop(ctx)

out, err := sb.Exec(ctx, "python", []string{"-c", "print('Hello from a microVM!')"})
if err != nil {
    return err
}
fmt.Println(out.Stdout())
</CodeGroup>

Next steps

<CardGroup cols={2}> <Card title="Quickstart" icon="bolt" href="/getting-started/quickstart"> Install microsandbox and run your first sandbox. </Card> <Card title="Sandbox overview" icon="box" href="/sandboxes/overview"> Learn the core configuration model. </Card> <Card title="CLI overview" icon="terminal" href="/cli/overview"> Manage sandboxes from the terminal. </Card> <Card title="SDK reference" icon="code" href="/sdk/overview"> Choose a language and look up the API surface. </Card> </CardGroup>