Sandbox Providers
Wit supports two sandbox provider modes for running AI agents in isolated environments:- Docker: Self-hosted container-based sandboxes for local development and air-gapped environments
- ComputeSDK: Cloud sandboxes via ComputeSDK - unified access to E2B, Daytona, Modal, CodeSandbox, Vercel, and more
Overview
Sandbox providers enable:- Secure code execution - Isolated environments prevent AI from affecting your local system
- Full development environments - PTY support, file system access, and command execution
- Resource limits - Control CPU, memory, and disk usage
- Network isolation - Optional network restrictions for security
Available Providers
| Provider | Startup Time | Use Case | Self-hosted |
|---|---|---|---|
| Docker | ~2-5s | Local development, self-hosted | Yes |
| ComputeSDK | Varies | Cloud sandboxes, GPU workloads | No |
ComputeSDK Underlying Providers
ComputeSDK provides unified access to multiple cloud providers:| Provider | Via ComputeSDK | Startup | Best For |
|---|---|---|---|
| E2B | ✅ | ~150ms | AI code execution, secure sandboxing |
| Daytona | ✅ | ~2s | Full dev environments, PTY, git |
| Modal | ✅ | ~2s | GPU/ML workloads |
| CodeSandbox | ✅ | ~2s | Collaborative coding |
| Vercel | ✅ | ~1s | Node.js/Python ephemeral compute |
| Blaxel | ✅ | Varies | AI-powered code execution |
Docker Provider
Local container-based sandboxes using Docker. Best for self-hosted deployments.Features
- Full PTY support via
docker exec - Resource limits (CPU, memory, disk)
- Network isolation
- Volume mounting for repository access
- No external dependencies (self-hosted)
Configuration
Environment Variables
Creating a Session
Building the Sandbox Image
ComputeSDK Provider
Unified multi-provider access via ComputeSDK. Provides access to E2B, Daytona, Modal (GPU!), CodeSandbox, Vercel, and more through a single API.Features
- Unified API across all cloud providers
- Zero-config auto-detection from environment variables
- GPU access via Modal for ML workloads
- Collaborative sandboxes via CodeSandbox
- Seamless provider switching without code changes
Configuration
Environment Variables
Auto-Detection Order
ComputeSDK auto-detects the provider based on which credentials are present:- Modal -
MODAL_TOKEN_ID+MODAL_TOKEN_SECRET - E2B -
E2B_API_KEY - Daytona -
DAYTONA_API_KEY - CodeSandbox -
CODESANDBOX_TOKEN
Creating a Session
GPU Workloads with Modal
Quick Start
Using the Manager
The recommended way to use sandboxes is through theSandboxManager:
Environment-Based Configuration
Provider Comparison
When to Use Each Provider
| Scenario | Recommended |
|---|---|
| Local development | Docker |
| Self-hosted / air-gapped | Docker |
| Fast iteration (CI/CD) | ComputeSDK (E2B) |
| Production AI agents | ComputeSDK (E2B or Vercel) |
| Full dev environment | ComputeSDK (Daytona) |
| GPU/ML workloads | ComputeSDK (Modal) |
| Collaborative coding | ComputeSDK (CodeSandbox) |
Feature Comparison
| Feature | Docker | ComputeSDK |
|---|---|---|
| PTY Support | Yes | Yes (varies) |
| File Operations | Yes | Yes |
| Code Interpreter | No | Yes |
| Network Isolation | Yes | Yes |
| GPU Support | No | Yes (Modal) |
| Self-hosted | Yes | No |
| Multi-provider | No | Yes |
Health Checks
All providers implement health checks:Session Management
Listing Sessions
Getting Session Stats
Session Information
Error Handling
Best Practices
- Always clean up sessions - Call
session.stop()when done - Set appropriate timeouts - Prevent runaway sessions
- Use resource limits - Prevent resource exhaustion
- Handle errors gracefully - Sessions can fail unexpectedly
- Monitor session stats - Track resource usage
- Use environment variables - Never hardcode API keys
- Choose the right provider - Docker for self-hosted, ComputeSDK for cloud