Sandbox.create(), Podflare doesn’t cold-boot a Linux kernel from scratch — that would take over a second. Instead, Podflare keeps a pool of pre-booted, agent-ready VMs waiting in an idle queue. Your create() call pops one from the front of that queue and returns it to you. The result: sandbox creation in 7–11 ms, fast enough to create sandboxes on demand inside an agent loop without noticeable latency.
Pool hit vs pool miss
The warm pool has two paths depending on whether an idle VM is available when you callcreate():
Pool hit (normal case)
An idle VM is available.
create() claims it from the front of the queue and returns in 7–11 ms including round-trip network time. A background task immediately starts pre-booting a replacement VM to keep the pool stocked.Pool misses are temporary. After a burst drains the pool, it refills quickly — a pool of 50 VMs can recover in about 600 ms. Subsequent
create() calls return to 7–11 ms once the pool is stocked again.What to expect in practice
For most workloads — including agent loops that create a sandbox per task — the pool ensures consistently fast creation. You’ll see a pool miss only if you spin up many sandboxes nearly simultaneously after a period of inactivity.| Situation | Observed latency |
|---|---|
| Normal create (pool hit) | 7–11 ms |
| Burst create (pool miss) | ~1.4 s |
| First create after a sustained burst | 7–11 ms once pool refills |
The pool and fork
The same pre-booted VM pool backs bothcreate() and fork(). Each fork child is initialized from the parent’s snapshot rather than from the pool directly, but the overall system shares the same fast-path restore machinery — which is why forking 5 children takes ~101 ms total, not 5× the individual cost.
Related concepts
Sandboxes
Full sandbox lifecycle and resource configuration
Fork
N-way branching and fork timing