Providers
Overview
Compare Sandbox SDK providers by runtime, persistence, previews, and snapshots.
Every provider supports files, foreground commands, background processes, streaming, and cleanup. Choose based on the optional behavior your workload needs.
| Provider | Best for | Runtime | Persistence | Preview | Snapshot |
|---|---|---|---|---|---|
| Local | Development, CI, self-hosting | AgentOS VM | Process-scoped | Private bridge | Filesystem + restore |
| E2B | Hosted coding agents | Linux sandbox | Ephemeral | Authenticated | Template |
| Daytona | Persistent workspaces, GPUs | Linux workspace | Persistent | Public or authenticated | Native API |
| Vercel Sandbox | Vercel workloads and previews | Linux sandbox | Optional | Public | Filesystem |
| Upstash Box | Durable serverless boxes | Linux container | Persistent | Public or bearer token | Filesystem |
Optional semantics differ. Check the generated compatibility matrix before depending on stdin, restore, resume, networking, GPUs, or a custom image.
Switch with one import
import { withSandbox } from "@opencoredev/sandbox-sdk";
import { e2b } from "@opencoredev/sandbox-sdk/e2b";
await withSandbox({ provider: e2b() }, async (sandbox) => {
console.log((await sandbox.run("node --version")).stdout);
});Only provider creation changes. The sandbox calls stay the same, and the provider object can also be passed to AI SDK, Eve, or Mastra.