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

# Quickstart

> Get a sandbox running in under 5 minutes

<Note>
  microsandbox requires **Linux with KVM**, **macOS with Apple Silicon** (M-series chip), or **Windows 10 or later with Windows Hypervisor Platform** enabled. All local backends use hardware virtualization.
</Note>

<Tip>
  Boot a microVM in one command.

  ```bash theme={null}
  npx microsandbox run debian
  ```
</Tip>

<Steps>
  <Step title="Install microsandbox">
    Install the SDK for the language you are using, and install the `msb` CLI for terminal workflows such as managing images, volumes, and sandboxes. Both run microsandbox locally; there is no separate server or daemon to set up.

    <CodeGroup>
      ```bash Rust theme={null}
      cargo add microsandbox
      ```

      ```bash TypeScript theme={null}
      npm install microsandbox
      ```

      ```bash Python theme={null}
      pip install microsandbox
      ```

      ```bash Go theme={null}
      go get github.com/superradcompany/microsandbox/sdk/go
      ```

      ```bash CLI theme={null}
      curl -fsSL https://install.microsandbox.dev | sh
      ```
    </CodeGroup>

    The CLI installer creates command links in `~/.local/bin/` and does not edit shell startup files. If `~/.local/bin` is not on your `PATH`, the installer prints the command to add it.

    <Note>
      Windows 10 or later is supported in preview. A Windows MSI or winget package is not published yet; use the hosted PowerShell installer:

      ```powershell theme={null}
      irm https://install.microsandbox.dev/windows | iex
      ```
    </Note>

    On Windows, run the doctor check before starting local sandboxes:

    ```powershell theme={null}
    msb doctor
    ```

    If it reports that Windows Hypervisor Platform is unavailable, let `msb` open the elevated fix prompt:

    ```powershell theme={null}
    msb doctor --fix
    ```

    You can also enable the optional feature manually from an elevated PowerShell:

    ```powershell theme={null}
    Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All -NoRestart
    ```

    Reboot after the command completes. `HypervisorPlatform` exposes the WHP API used by libkrun; it is separate from `VirtualMachinePlatform`, which Docker Desktop and WSL2 commonly enable. See [Windows troubleshooting](/troubleshooting/windows) for the full checklist.
  </Step>

  <Step title="Run code in a sandbox">
    Create a sandbox, execute code inside it, and get the result back.

    <CodeGroup>
      ```rust Rust theme={null}
      use microsandbox::Sandbox;

      #[tokio::main]
      async fn main() -> Result<(), Box<dyn std::error::Error>> {
          let sb = Sandbox::builder("hello")
              .image("python")
              .memory(512)
              .create()
              .await?;

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

          sb.stop().await?;
          Ok(())
      }
      ```

      ```typescript TypeScript theme={null}
      import { Sandbox } from "microsandbox";

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

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

      ```python Python theme={null}
      import asyncio
      from microsandbox import Sandbox

      async def main():
          sb = await Sandbox.create(
              "hello",
              image="python",
              memory=512,
          )

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

          await sb.stop()

      asyncio.run(main())
      ```

      ```go Go theme={null}
      sb, err := m.CreateSandbox(ctx, "hello",
          m.WithImage("python"),
          m.WithMemory(512),
      )
      if err != nil {
          return err
      }
      defer sb.Stop(ctx)

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

      ```bash CLI theme={null}
      msb run python -- python3 -c "print('Hello from a microVM!')"
      ```
    </CodeGroup>
  </Step>
</Steps>

## What just happened?

Here's what happened behind that `Sandbox.builder(...).create()` call:

1. **Pulled the image** from Docker Hub, unless it was already cached.
2. **Assembled a copy-on-write filesystem** so changes inside the sandbox do not modify the base image.
3. **Booted a microVM** as a child process with the resource limits you configured.
4. **Started the guest agent** so the SDK can run commands and move data in and out.

The `exec` call uses the host-guest command channel, not SSH and not the sandbox network.

<Tip>
  Because exec doesn't go through the network, it works even when a sandbox has networking disabled via `.disable_network()` and no network interfaces at all.
</Tip>

## Next steps

* [Understand sandbox configuration](/sandboxes/overview): resources, images, volumes, and lifecycle
* [Troubleshoot Linux setup](/troubleshooting/linux): KVM, `/dev/kvm`, and permissions
* [Troubleshoot macOS setup](/troubleshooting/macos): Apple Silicon and local runtime checks
* [Troubleshoot Windows setup](/troubleshooting/windows): WHP, runtime files, firewall prompts, and source-build toolchains
* [Run commands and stream output](/sandboxes/commands): `exec`, `shell`, `attach`, and streaming
* [Control network access](/networking/overview): policies, DNS interception, and secret protection
* [Manage sandboxes with the CLI](/cli/overview): create, inspect, and manage sandboxes from the terminal