Ephemeral devboxes: 10s spin-up (Stripe benchmark)

The 10-second devbox spin-up is the performance target that Stripe's agent infrastructure team set as the benchmark for production-grade agent environments. The full sequence - environment provisioned, codebase present at the correct commit, dependencies installed, MCP tools configured, agent process started and ready to receive the task - in under 10 seconds. This target is not a theoretical aspiration; Stripe's "Minions" agent fleet achieves it in production with the infrastructure techniques described here.

Reaching 10 seconds requires combining multiple techniques. First, pre-warmed container pools (environments waiting in a ready state) eliminate the need to initialize from scratch on every task. Second, Firecracker microVMs or optimized Docker with snapshot support enable fast restore from a checkpointed state rather than full initialization. Third, content-addressable storage for the codebase means that cloning a large repository at a specific commit is a local operation against a pre-populated cache, not a network transfer from GitHub. Fourth, pre-installed and pre-authenticated MCP servers mean the agent does not spend time connecting and authenticating to tools when it starts.

Why does 10 seconds matter? Below roughly 30 seconds of startup time, developers experience the devbox as "instant" - they submit a task and by the time they have documented what they just did or reviewed the previous task, the new environment is ready. Above 30 seconds, there is a perceptible wait that breaks the developer's flow and adds mental overhead to the task dispatch decision. The 10-second benchmark is a usability threshold, not just a technical achievement.

The gap between a naive implementation (3-5 minute cold start) and the 10-second benchmark is mostly infrastructure investment in pre-warming and caching. The actual agent runtime and codebase initialization have to happen either way - the question is whether they happen on the critical path (cold start) or in the background before the task arrives (pre-warming). Getting to 10 seconds means moving as much initialization work as possible off the critical path.

• 10-second startup makes parallel agent dispatch practical - when each devbox starts in 10 seconds, dispatching 10 parallel agent tasks has an 10-second startup overhead; at 3-minute cold start, that becomes 30 minutes, effectively forcing sequential execution
• Sub-30-second startup unlocks quick tasks - developers will only dispatch an agent task if the expected task duration is substantially longer than the startup overhead; at 10-second startup, tasks as short as 2 minutes become worth dispatching to an agent
• Startup time is a lever on iteration rate - an agent that can start a new task in 10 seconds enables faster iteration cycles; the feedback loop between task completion and task dispatch tightens when startup is transparent
• 10 seconds sets the standard that CI systems can meet - CI pipelines that provision agent environments for automated test remediation, automated PR review, or automated dependency updates need startup times that do not add significant latency to the overall pipeline
• Pre-warming infrastructure for devboxes overlaps with pre-warming for CI - the investment in fast devbox spin-up improves the startup time for automated pipeline agents simultaneously, compounding the return on infrastructure investment

1. Baseline your current startup time - Time the full initialization sequence for your existing devbox setup and identify the slowest steps. Common slow steps: git clone (2-5 minutes for large repos), npm install / pip install / go mod download (1-5 minutes), Docker image pull (30-120 seconds). The bottlenecks tell you where to invest.
2. Implement Firecracker for microVM-speed isolation - If you need VM-level isolation (stronger than containers) without VM-level startup overhead, Firecracker microVMs are the technology. Firecracker boots in under 125 milliseconds and supports snapshotting - saving and restoring VM state. Set up Firecracker, configure a snapshot of the agent runtime state post-initialization, and measure the restore time.
3. Switch to snapshot-based initialization - Instead of running git clone and npm install in every container, create a Docker image snapshot that embeds the repository at a recent commit with dependencies installed. Container initialization then runs git pull --depth=1 to apply recent commits (fast, local-cache-friendly) rather than a full clone.
4. Deploy content-addressable object storage for source - Bazel's remote cache, GitHub's object storage, or a custom content-addressable store can serve repository contents at specific commits from a local cache. Instead of cloning from GitHub over the network, the container fetches the specific files it needs from a local cache server.
5. Pre-authenticate MCP servers in the base snapshot - Include MCP server processes in the container snapshot in a running, authenticated state. When the container restores from snapshot, MCP servers are already running and connected. The agent does not spend time starting or authenticating tools.
6. Measure the full end-to-end time from task submit to agent-ready - Do not optimize just container startup time. Measure the time from when the developer submits a task to when the agent sends its first message. This end-to-end time includes pool assignment, credential injection, and agent process startup. Target 10 seconds for this full sequence.

Optimizing container startup but not pool availability. A container that starts in 5 seconds but is not available in the pre-warmed pool results in a cold start when demand exceeds pool capacity. The pool size must match peak demand. A fast container that is always cold-starting is no better than a slow container for the tasks that hit the capacity limit.

Snapshotting at the wrong initialization stage. Snapshotting the container before dependency installation saves the image pull time but not the install time. Snapshot after all initialization steps are complete: repository cloned, dependencies installed, MCP tools running, agent runtime configured. The snapshot should be the fully-ready state, not a partially-initialized state.

Not invalidating stale snapshots. A snapshot that was created 5 days ago has a codebase that is 5 days behind main. Tasks that work on recent commits will spend time applying a large diff, negating the startup benefit. Refresh snapshots at least daily for active repositories, triggered by commits to monitored branches.

Treating 10 seconds as a set-and-forget achievement. Infrastructure evolves: codebases grow, new dependencies are added, tool configurations change. A startup time that is 10 seconds today may be 30 seconds in 6 months without maintenance. Track startup time as a continuous metric and investigate when it exceeds the target.

Not benchmarking the tail latency. Average startup time of 10 seconds can coexist with a P99 startup time of 90 seconds if pool exhaustion causes occasional cold starts. The developer experience is defined by the worst cases, not the average. Monitor P50, P95, and P99 startup times and investigate the tail.