Sandbox SDK: One Interface, Every Cloud Sandbox

AI agents need to run code. Not on your production servers, not with root access on your laptop. They need sandboxes: isolated environments that spin up fast, execute untrusted code safely, and tear down cleanly. The problem is every sandbox provider has a different API. We built Sandbox SDK so you write your agent logic once and swap providers by changing config, not code.

Why Multiple Providers?

No single provider does everything well. Modal is great for GPU workloads. E2B has sub-second cold starts designed for agent workflows. Vercel is fast for lightweight JavaScript. Daytona gives you full dev environments. Locking into one means paying GPU prices for a simple script, or hitting capability walls when you need something your provider does not offer.

Sandbox SDK gives you a single SandboxDriver interface. Create a sandbox, run a process, read/write files, destroy the sandbox. Every provider implements this interface. Advanced features like snapshots and persistent volumes are exposed as optional capabilities that your agent can query at runtime and adapt to.

Built for Production

The SDK is built with Effect-TS, which gives us structured error handling (no silent failures), automatic resource cleanup (no leaked sandboxes), and built-in observability (every operation is traced). It also includes rate limiting so you do not overwhelm providers, retry logic for transient failures, and input validation at the boundary.

For testing, there is a MockDriver that records operations without hitting real providers. Develop locally with Docker, test with mocks, deploy to cloud. Same code, different config.

Seven Providers at Launch

Modal, E2B, Vercel, Daytona, Cloudflare Workers, Blaxel, and Docker. Each is a separate npm package under @ataraxy-labs/sandbox-*.

Get Started

Sandbox SDK is MIT licensed. The repo includes the core SDK, all provider packages, and a reference agent implementation.