Sandbox Reuse
Reuse and persistence strategies across sandbox providers
Quick Summary
| Provider | Reuse Mechanism | Persistence | Best For |
|---|---|---|---|
| E2B | Name-based lookup | Platform-managed FS | Production, short tasks |
| Sandock | In-process cache | No cross-process persistence | Local dev |
| Daytona | Name + volume | Volume-backed | Long-lived projects |
E2B
Provide a stable name. attach() finds and resumes existing sandboxes by name.
const sandbox = new E2BSandbox({ name: "my-project", template: "base" });
const handle = await sandbox.attach();- Works across processes
- Idle sandboxes may be paused and auto-resumed
Sandock
Uses an in-memory cache per process. Reuse works only within the same Node.js process.
const sandbox = new SandockSandbox({ image: "sandockai/sandock-code:latest" });
const handle = await sandbox.attach();- Cache size: 50 instances
- TTL: 30 minutes
- Not shared across processes
Daytona
Provide a stable name. Optional volumeName keeps files across restarts.
const sandbox = new DaytonaSandbox({
name: "my-project",
volumeName: "my-project-volume",
autoStopInterval: 15,
});
const handle = await sandbox.attach();- Volume persists even when sandbox stops
- Suitable for long-lived projects
Naming Strategy
Pick a stable name tied to your use case:
- Template-based:
sandagent-${template} - User session:
user-${userId}-session-${sessionId} - Project:
project-${projectId}
Recommendations
- Production, short tasks → E2B with a stable
name - Long-lived projects → Daytona with
volumeName - Local dev → Sandock cache