Why local Docker still beats cloud sandboxes for agentic coding runs

An analysis of Nicholas A. Sutton's benchmark comparing nine developer execution environments against a local laptop, highlighting the trade-offs between isolation, startup latency, and raw execution speed.

The verdict up front

For developers building AI coding agents, the choice of execution environment dictates both iteration speed and system security. If you are developing and testing agents locally, local Docker is the best choice. It provides a necessary boundary against destructive commands while avoiding the network latency of cloud sandboxes. If you are running production agents that execute untrusted user code, you must use a dedicated cloud sandbox like E2B or Daytona. Running untrusted agent code directly on your local laptop host is a critical security risk that should be avoided entirely.

Methodology and scope

This v0 review draws on the published analysis by Nicholas A. Sutton (nasutton12) at his Notion resource, comparing nine coding harnesses against a local laptop setup. Independent benchmarks by our team are pending.

The analysis covers nine distinct execution environments:

1. Local Host (the baseline laptop)
2. Local Docker Container
3. E2B Sandbox
4. Daytona
5. Fly.io Machines
6. AWS Lambda
7. AWS ECS
8. GitHub Codespaces
9. Gitpod

This review evaluates these environments across three primary vectors: startup latency, execution overhead, and security isolation. It does not cover long-term pricing fluctuations, custom enterprise VPC configurations, or performance under extreme multi-tenant load.

How the environments compare

The nine environments fall into three distinct architectural categories, each with clear performance profiles.

Local execution environments

The local host and local Docker container represent the low-latency baseline. Local host execution is near-instantaneous, but it offers zero isolation. A rogue agent could delete your home directory or access sensitive environment variables. Local Docker introduces a minor startup penalty but provides a robust file system boundary on your local machine.

Dedicated agent sandboxes

E2B and Daytona are built specifically for agentic workflows. They offer secure, ephemeral micro-VMs designed to start quickly and execute code safely. The author highlights that these platforms simplify state management and provide clean APIs for running code blocks, though they introduce network-bound latency for every command executed from a local control loop.

General-purpose cloud environments

Fly.io, AWS (Lambda and ECS), GitHub Codespaces, and Gitpod represent general-purpose cloud infrastructure. While highly secure and scalable, these environments suffer from higher cold-start latencies and more complex orchestration APIs when repurposed as ephemeral agent sandboxes.

The security vs latency trade-off

The core tension in agent execution is security versus latency. Nicholas A. Sutton's comparison highlights that while running code directly on a local laptop host is the fastest option, it is fundamentally unsafe for agentic workflows.

What is interesting about this comparison is how clearly it exposes the hidden tax of cloud sandboxes. When an agent runs an iterative edit-test loop (such as running a test suite, modifying code, and re-running the test), every single step requires a round-trip network call to the cloud sandbox. If your agent requires fifty steps to solve a problem, even a small network and execution overhead per step adds significant idle time to a single run.

What is missing from the general marketing of cloud sandboxes is a realistic path for hybrid development. Developers need a way to run identical agent code locally inside a fast Docker container during development, then seamlessly swap the execution provider to E2B or Daytona in production without rewriting their tool-calling logic.

Pricing snapshot

Pricing is current as of September 2026:

• Local Host & Local Docker: Free.
• E2B: Free tier available with rate limits; pay-as-you-go pricing based on active sandbox hours.
• Daytona: Open-source and free for self-hosted setups; custom enterprise pricing for managed cloud.
• AWS & Fly.io: Standard utility pricing based on compute seconds and memory consumption.

Verdict

Do not run untrusted agent code directly on your local host. For local development and benchmarking, use local Docker containers. They offer the best balance of safety and low latency. For production deployments where you must execute untrusted user code, use E2B or Daytona to guarantee secure isolation at the cost of network latency.

What we would test next

In our next benchmark iteration, we plan to measure the exact file system write speeds across all nine environments during a standard SWE-bench run. We also want to test network egress restrictions and their impact on package installation speeds (npm and pip) within the sandboxes, as slow package resolution frequently bottlenecks agent execution.

The investor read

The shift toward agentic workflows is driving a massive infrastructure transition from static cloud VMs to ephemeral, ultra-low-latency sandboxes. While local Docker remains the developer's choice for zero-cost, low-latency testing, enterprise adoption of AI agents requires secure, multi-tenant execution environments. Startups like E2B and Daytona are positioning themselves as the secure runtime layer for the agentic era. For investors, the investability of these platforms hinges on their ability to minimize cold-start latency and network overhead while maintaining strict security isolation. The winner in this category will become the default execution backend for every LLM-orchestration framework, capturing a significant portion of the developer tooling spend currently allocated to traditional cloud VMs.

Pull quote: “Running untrusted agent code directly on your local laptop host is a critical security risk that should be avoided entirely.”