Sandbox Plugins

Isolate code execution with E2B, Daytona, nsjail, sidecar, and Vercel sandbox plugins.

Sandbox plugins provide isolation backends for the explore tool. They run user-initiated commands (file listing, grep, cat) in restricted environments to prevent unauthorized filesystem or network access. Each plugin implements the AtlasSandboxPlugin interface from @useatlas/plugin-sdk.

All five plugins follow the same pattern: validate config via a Zod schema, create an isolated environment, upload semantic layer files, execute commands, and clean up. The differences are in the isolation technology and where the sandbox runs.

Available Sandbox Plugins

Vercel Sandbox

Firecracker microVM on Vercel infrastructure (priority 100)

E2B

Managed Firecracker microVM via E2B cloud (priority 90)

Daytona

Managed cloud sandbox via Daytona SDK (priority 85)

nsjail

Linux namespace sandbox on same host (priority 75)

Sidecar

HTTP-isolated container alongside API (priority 50)

Priority Order

When multiple sandbox backends are available, Atlas selects the highest-priority one. Higher priority means stronger isolation guarantees.

Plugin	Priority	Isolation Type	Runs on
Vercel	100	Firecracker microVM	Vercel infrastructure
E2B	90	Firecracker microVM (managed)	E2B cloud
Daytona	85	Managed cloud sandbox	Daytona cloud
nsjail	75	Linux namespace sandbox	Same host (Linux only)
Plugin default	60	`SANDBOX_DEFAULT_PRIORITY`	--
Sidecar	50	HTTP-isolated container	Separate container
just-bash (built-in)	0	OverlayFs (dev fallback)	Same host

The built-in just-bash backend (priority 0) is a development-only fallback. It uses OverlayFs for read-only filesystem protection but provides no network isolation. Never use it in production.

Choosing a Sandbox

Use this decision tree to pick the right sandbox for your deployment:

Deploying on Vercel? Use Vercel Sandbox -- it is auto-selected as the highest-priority backend and requires no configuration.
Want managed cloud isolation with no infrastructure? Use E2B or Daytona. Both provide ephemeral VMs/sandboxes via a managed API.
Self-hosting on Linux with root access? Use nsjail -- strong namespace isolation with no external dependencies beyond the nsjail binary.
Self-hosting on Docker/Railway without root? Use Sidecar -- deploy the sidecar container alongside the API. No special kernel capabilities needed.
Local development? bun run db:up starts a sidecar container alongside Postgres -- no plugin needed.

Combining Multiple Sandboxes

You can register multiple sandbox plugins. Atlas picks the highest-priority one that is available at runtime:

// atlas.config.ts
import { defineConfig } from "@atlas/api/lib/config";
import { nsjailSandboxPlugin } from "@useatlas/nsjail";
import { sidecarSandboxPlugin } from "@useatlas/sidecar";

export default defineConfig({
  plugins: [
    // nsjail (priority 75) is preferred when available
    nsjailSandboxPlugin({ timeLimitSec: 15 }),
    // Sidecar (priority 50) is the fallback
    sidecarSandboxPlugin({
      url: process.env.ATLAS_SANDBOX_URL ?? "http://sandbox-sidecar:8080",
    }),
  ],
});