> ## Documentation Index
> Fetch the complete documentation index at: https://nativesandbox.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Sandboxes on any Linux host

> Run untrusted code in isolated sandboxes without a hypervisor. Containers through Podman or Docker — no KVM, no nested virtualisation, no daemon of its own.

Move risky work out of your process. Model-generated code, user submissions, plugins, CI jobs —
anything you would not run inline gets its own sandbox, with its own memory, CPU and process
budget, and a workspace you can read and write directly.

<CodeGroup>
  ```bash Install theme={null}
  npm install -g nativesandbox
  nsbx run "node --version"
  ```

  ```bash No install theme={null}
  npx nativesandbox run "node --version"
  ```
</CodeGroup>

That is the whole install. No binary to download, no runtime to version-match, nothing written
to a dot-directory in your home.

## Why nativesandbox

<CardGroup cols={2}>
  <Card title="Runs where microVMs cannot" icon="server">
    Containers need no nested virtualisation. On the cloud shapes that do not offer it — Oracle's
    Ampere ARM64 free tier among them — a microVM cannot boot at all, and this can.
  </Card>

  <Card title="Nothing to install but the engine" icon="feather">
    Zero dependencies, and no runtime of its own. Podman or Docker is the runtime, and your
    distro already packages it.
  </Card>

  <Card title="The workspace is a directory" icon="folder-open">
    Bind-mounted, not copied through an agent channel. 7× faster to place 200 files and 49×
    faster to read them back than a microVM runtime on the same machine.
  </Card>

  <Card title="Warm caches between commands" icon="rotate">
    Reuse is meet-or-exceed, so a sandbox built large serves a small command. A dependency
    install survives instead of going cold every time.
  </Card>

  <Card title="Hardened by default" icon="shield-halved">
    Every Linux capability dropped, no-new-privileges, cgroup limits, and a network policy per
    sandbox — each verified against a real `npm install`, not assumed.
  </Card>

  <Card title="A fleet that reclaims itself" icon="broom">
    Idle stop and a hard maximum lifetime, recorded on the container so they outlive the process
    that set them. Neither interrupts a command in flight.
  </Card>
</CardGroup>

## What people use it for

* **AI agents that run code.** A tool call that executes whatever the model wrote, in a box.
* **Untrusted user submissions.** Coding exercises, notebook cells, marketplace plugins.
* **Build and test isolation.** A dependency install that cannot reach the rest of the host.
* **Per-tenant workspaces.** One long-lived sandbox per customer, reclaimed when it goes quiet.
* **Anything on a host without `/dev/kvm`.** Which, on the cheap cloud shapes, is most of them.

## A minimal example

<CodeGroup>
  ```ts TypeScript theme={null}
  import { Sandboxes, MiB } from "nativesandbox";

  const sandboxes = new Sandboxes();
  const box = await sandboxes.create("hello", { memory: MiB(512) });

  await box.writeFile("/main.js", "console.log('Hello from a sandbox!')");
  const { stdout } = await box.exec("node main.js");

  console.log(stdout);
  await sandboxes.remove("hello");
  ```

  ```js JavaScript theme={null}
  const { Sandboxes, MiB } = await import("nativesandbox");

  const sandboxes = new Sandboxes();
  const box = await sandboxes.create("hello", { memory: MiB(512) });

  await box.writeFile("/main.js", "console.log('Hello from a sandbox!')");
  const { stdout } = await box.exec("node main.js");

  console.log(stdout);
  await sandboxes.remove("hello");
  ```

  ```bash CLI theme={null}
  nsbx run "node -e \"console.log('Hello from a sandbox!')\""
  ```
</CodeGroup>

```
Hello from a sandbox!
```

## The trade, stated plainly

This is process isolation, not hardware isolation. A sandbox cannot read or write the host, but
the boundary it leans on is the kernel rather than a hypervisor, and that is a weaker boundary.

It is narrowed by running rootless, by dropping every capability, by seccomp, by cgroup limits
and by a per-sandbox network policy — and it can be narrowed much further, at no cost, with
[gVisor](/guides/isolation#gvisor), which still needs no KVM.

**If your host has KVM and you want hardware isolation, use a microVM runtime.** This exists for
the hosts that cannot. If you have seen this, that is you:

```
[BootStart] failed to start "…": sandbox process exited
(signal: 6 (SIGABRT) (core dumped)) before agent relay became available
```

## Next steps

<CardGroup cols={2}>
  <Card title="Quickstart" icon="play" href="/getting-started/quickstart">
    From nothing to a running sandbox, in one command.
  </Card>

  <Card title="Check your host" icon="stethoscope" href="/cli/doctor">
    `nsbx doctor` tells you whether this machine can run sandboxes, and what to fix if not.
  </Card>

  <Card title="Isolation" icon="shield-halved" href="/guides/isolation">
    What is taken away from every sandbox — and what is not defended against.
  </Card>

  <Card title="API reference" icon="terminal" href="/api-reference/sandboxes">
    Every option and method.
  </Card>
</CardGroup>
