Sandbox Providers

Comparison of code execution environments: Docker, E2B, Daytona, Modal, and local execution. How xCoder isolates untrusted agent operations.

Overview

Sandboxes provide isolated execution environments for agent-generated code. They prevent agents from accidentally or maliciously damaging the host system, leaking secrets, or introducing supply-chain attacks. xCoder uses a tiered sandbox strategy that matches the isolation level to the trust level of the task.

Comparison Matrix

DimensionDockerE2BDaytonaModalLocal
Isolation LevelProcess + FS namespaceMicroVM (Firecracker)Container / VMContainer (cloud)None
Startup Time1-5s~100ms~500msCold: 2-5sInstant
Network AccessConfigurableConfigurableConfigurableConfigurableFull
PersistenceVolume mountsEphemeral (optional persist)Workspace persistenceEphemeralHost filesystem
Cost ModelFree (self-hosted)Usage-based ($/hour)Usage-based ($/hour)Usage-based ($/core-hour)Free
GPU SupportVia NVIDIA runtimeNoYesYes (serverless)Direct
Pre-built TemplatesUser-definedMany (Node, Python, etc.)Workspace presetsCustom imagesN/A
API ComplexityMedium (Docker SDK)Low (REST SDK)MediumMediumN/A
Production UsageUniversalRising (eval platforms)Early adoptersML inference workloadsDevelopment only
xCoder Score8/108/107/106/105/10

Docker

Docker is the default choice for self-hosted sandboxing. It provides strong process isolation, mature tooling, and zero marginal cost. The downside is startup latency (1-5s) and the need to manage images and volumes. We use Docker for long-running autopilot tasks where startup time is amortized over the session duration.

E2B

E2B provides microVM-based sandboxes with ~100ms cold start times. It is ideal for interactive sessions where latency matters. The sandbox is ephemeral by default but supports persistent filesystems. E2B's API is developer-friendly and integrates well with TypeScript. We use E2B for interactive mode and quick evaluations.

Daytona

Daytona (formerly Gitpod) offers workspace-oriented sandboxes with strong IDE integration and persistent storage. It is more "developer environment" than "execution sandbox," making it suitable for agents that need a full dev setup (language servers, debuggers, pre-installed dependencies). Higher cost than E2B but richer environment.

Modal is a serverless compute platform with strong GPU support. While primarily designed for ML inference, it can run arbitrary containers. We evaluated it for GPU-accelerated agent tasks (e.g., large model inference within the sandbox) but found it overkill for general coding agents.

Local

Local execution runs the agent directly on the host filesystem with no isolation. This is the default for trusted interactive mode but is never used for autonomous autopilot or untrusted code evaluation. We keep it as an option for power users who manage their own risk.

xCoder's Decision

Hybrid: Docker + E2B

xCoder uses a tiered approach: E2B for interactive sessions and evaluations (fast startup), Docker for autopilot and long-running tasks (free, persistent), and local for trusted interactive mode only. This policy is configurable per-project in .xcoder/supervisor.yaml.

Integration Notes

  • Provider abstraction packages/containers/ defines a commonSandboxProvider interface implemented by Docker and E2B adapters.
  • Health checks — Each sandbox is probed for responsiveness before agent execution begins.
  • Volume mounting — Repository code is mounted read-write into the sandbox; system directories are read-only.
  • Network policy — Default deny-all egress with allowlisted domains for package registries and APIs.
  • Cleanup — Ephemeral sandboxes are destroyed after session completion; persistent ones are garbage-collected after 24h of inactivity.