Skip to main content
We benchmarked Podflare against E2B, Daytona, and Blaxel end-to-end — same SDK machine, same wall-clock window, same workload — so the numbers below are directly comparable. No selective sampling, no apples-to-oranges network paths. Reproduce with scripts/bench-cold-start.py and scripts/bench-http-outbound.py from our repo.

​
TL;DR — 30-iteration distribution

The 5-iteration version of this bench gave misleading results (notably, my early E2B numbers were thrown off by sample noise). All numbers below are from 30 sequential cold-start iterations per platform, run on the same machine in the same window. Reproduce: scripts/bench-reliability.py. Each run takes 20–30 s wall-clock per platform, runs 30 sequential Sandbox.create() → exec("echo ready") → close() cycles, and reports the full distribution.

​
Cold-start distribution — head-to-head

The metric customers actually feel: time from Sandbox.create() until the first echo ready returns. Each row below is 30 sequential iterations per platform — enough samples that the tail percentiles mean something.
Distribution (30 iterations per platform): Two findings worth highlighting:
  1. Podflare wins every percentile. p50 is 3.0× faster than E2B (the next-best), p95 is 4.4×, p99 is 3.6×, max is bounded under 270 ms while E2B’s max is 888 ms and Blaxel’s is 4 s. The previous version of this bench, with SDK 0.0.17, showed a 1,741 ms p99 for Podflare — caused by the SDK’s own connect=0.8s + retries=2 compounding on slow TLS handshakes (three chained ConnectTimeouts add up to ~2.9 s). SDK 0.0.19 widened connect to 2.5 s and dropped retries to 1, killing that self-inflicted tail. SDK 0.0.20 then defaulted to api.podflare.ai (Cloudflare-edge-routed), which is faster than direct-to-origin from most residential callers because the CF edge PoP is closer than any single region.
  2. All four platforms had 0 errors across 30 iterations. The differentiator is latency distribution, not reliability in the traditional uptime sense.

​
Pick the metric that matters to your workload

Different production agents care about different parts of the distribution. The “best” platform depends on which tail kills you faster.

​
Why Podflare’s first_exec is 2–48× faster

The first exec() after create() looks identical from the SDK side, but the underlying paths are different: All three competitors run a normal HTTP server inside each sandbox. Convenient (the SDK can talk plain HTTP), but every exec pays for TCP + TLS + HTTP framing inside the guest. We use vsock — a direct host↔guest socket with no TCP overhead — and a binary line protocol. Round-trip from a hot connection is ~3 ms server-side; the rest is network between you and the region.

​
HTTP outbound — what your agent actually feels

Inside-the-sandbox curl against two reliable targets, 5 runs each. (Earlier benches included httpbin.org but kept getting 10-second outliers from all four platforms — that’s httpbin’s per-source-IP rate limit, not platform speed.) Two takeaways:
  • GitHub-flavored workloads (the long tail of agent traffic — pip install, npm install, GitHub API, Hugging Face, etc.) all land within ~70 ms of each other. Geography is the whole story; pick a region close to GitHub’s Azure us-east peering.
  • Cloudflare trace shows raw network speed. Daytona’s 21 ms is fastest because their colo happens to be one hop from Cloudflare’s Ashburn PoP. Differences here are small absolute numbers.

​
Out-of-the-box experience

Blaxel’s bare-Alpine choice is interesting: smaller image, faster boot, smaller attack surface. But every workload needs apk add for basics like curl, python, git before doing real work — every fresh sandbox pays for that bootstrap.

​
Forking and persistent state

Cold-start isn’t the whole story. AI-agent workloads also fork (try N branches in parallel) and persist (resume a working session later). This is where the gap widens. fork() is the genuinely differentiated primitive. Most LLM-agent patterns (tree-of-thought, multi-attempt code synthesis) want N children that all start from the parent’s exact mid-flight state. On container platforms you’d docker commit (~seconds) and docker run N (~seconds × N). On Podflare that’s parent.fork(n=5) — a copy-on-write diff snapshot + N parallel microVM spawns in 80 ms p50, total. See Performance for the breakdown of what fork() does in those 80 ms.

​
Architecture comparison

​
License

If you’re building on top of one of these and might fork it later, license matters. Daytona’s AGPL is genuinely restrictive for commercial use; E2B’s Apache-2.0 is permissive; Blaxel and Podflare are proprietary.

​
Free-tier limits

Honest comparison: Podflare’s free tier is more conservative on per-sandbox limits. Tradeoff: lower abuse risk (1 GB ceiling makes crypto mining unprofitable without separate detection), at the cost of less headroom for free-tier experimentation. Pro tier opens up to 4 GB per sandbox, 50 concurrent, 8-hour lifetime.

​
Production-choice ranking — by axis (30-iter)

​
When each one wins

  • Latency-sensitive interactive agents (default case) → Podflare. Wins p50 (153 ms), p95 (170 ms), p99 (236 ms), and max (263 ms) — the only platform under 300 ms at every percentile. Native fork() for tree-of-thought patterns. Persistent Spaces survive full VM memory across restarts. Requires SDK ≥ 0.0.20 — 0.0.17 through 0.0.18 have a ~1.7 s p99 tail caused by the SDK’s own tight-connect + retries=2 compounding (fixed in 0.0.19); 0.0.20 then defaulted to api.podflare.ai for edge-routed latency.
  • GitHub-heavy workloads where outbound to Azure us-east matters → E2B. Their us-east colo wins HTTP outbound to GitHub at 25 ms (vs ours/others at 85–93 ms). Apache-2.0 lets you self-host for compliance.
  • Self-hosted on existing Docker/k8s infrastructure → Daytona. Pay the AGPL toll only if you’ll never fork the runtime; the Docker/Sysbox isolation is meaningfully weaker than a microVM if your threat model includes adversarial guest code.
  • Minimum-image, minimum-RAM workloads with your own bootstrap → Blaxel. Alpine base + 627 ms p50 is fine if your workload pre-warms with its own deps. Smallest attack surface.

​
Reproduce these numbers

All bench scripts are in our repo. They take an SDK API key for each platform and run identical workloads.
Each bench-reliability.py run does 30 sequential Sandbox.create() → exec("echo ready") → close() cycles per platform and prints the full distribution (min / p50 / p90 / p95 / p99 / max / mean / spread). No special flags, no warmup-and-discard tricks. If your numbers differ meaningfully from ours, send us the bench output and the SDK version you ran — we treat regression reports as P0. Our job is for these numbers to stay honest, not for our marketing to claim things the bench can’t reproduce.

​
Methodology

  • Date: April 2026
  • Client: macOS laptop on residential wifi, west-coast US
  • Podflare endpoint: api.podflare.ai with SDK 0.0.20 (Cloudflare-edge-routed — haversine-picks the nearest origin server-side per-request; from this machine that’s us-west)
  • E2B endpoint: e2b_code_interpreter SDK default (single GCP/AWS region, likely us-east4)
  • Daytona endpoint: daytona SDK default (single region per account; ours landed near IAD)
  • Blaxel endpoint: blaxel SDK with BL_REGION=us-pdx-1 and image=blaxel/base-image:latest
  • Sandbox spec: each platform’s default — 1 GB / 1 vCPU on all four
  • Bench iterations: 30 cold starts per platform, sequential, no parallelism. Each iteration is a complete Sandbox.create() → exec("echo ready") → close()/kill()/delete() cycle. We report the full distribution because the 5-iteration version of this bench gave misleadingly noisy results — particularly for E2B, whose median moved from 2,504 ms (5 samples) to 442 ms (30 samples). Sample size matters.
Run-to-run variance: the p50 numbers shift by ~10–30 ms either way between sessions. p95 / p99 are noisier — depend on whatever upstream network jitter happens that minute. The rank order on every percentile is stable across multiple bench sessions: Podflare wins p50 through max.