What Is a Warm Pool? Pre-Booted Runners, Zero Wait
A warm pool is a small reserve of runners already booted and idling, so when a job arrives it starts immediately instead of waiting for a machine to be provisioned from scratch.
Ephemeral runners are clean but slow to start - every fresh machine has to boot, register, and prepare. A warm pool hides that latency by keeping a few runners ready in advance, trading a little idle cost for a lot of speed.
The cold-start problem
Provisioning a fresh runner takes time: launch the instance, boot the OS, start the runner agent, register with GitHub. On a cold path that can be tens of seconds to minutes before your first step even runs.
How a warm pool fixes it
The platform keeps N runners pre-booted and registered, waiting. When a job arrives it grabs a ready runner and starts in roughly a second. The pool then replenishes itself in the background so the next job is also fast.
Sizing the pool
- Too small: bursts overflow the pool and overflow jobs hit cold starts.
- Too large: you pay for idle machines that never get used.
- Right-sized: the pool covers your typical concurrency, with autoscaling for spikes.
Warm pool vs persistent runner
A warm pool gives you the speed of a ready machine without the dirtiness of reuse: pool runners are still ephemeral and single-use. You get fast starts and clean state at the same time.
Warm pools on Latchkey
Latchkey maintains warm pools so your jobs typically start in about a second, with no queue and no cold-start tax, while each runner remains ephemeral.
Key takeaways
- A warm pool is pre-booted, idling runners ready to grab a job instantly.
- It hides the cold-start latency of provisioning fresh machines.
- Pool size trades idle cost against the chance of overflow cold starts.
- Latchkey uses warm pools so jobs start in about a second.