What Is Runner Autoscaling? Capacity That Follows Demand
Runner autoscaling automatically launches more runners when jobs queue up and removes them when demand drops - ideally all the way to zero when nothing is running.
CI load is spiky: nothing for an hour, then fifty jobs at 5pm. A fixed pool either wastes money idling or starves your team during peaks. Autoscaling matches runner count to actual demand, moment to moment.
Why fixed capacity fails
Provision for the peak and you pay for idle machines most of the day. Provision for the average and your busiest hours back up into long queues. Neither is acceptable, which is why autoscaling exists.
How autoscaling works
A controller watches the job queue. When queued jobs exceed available runners, it launches more. When runners go idle past a threshold, it terminates them. The goal is enough capacity to clear the queue without leaving machines burning money.
Scale to zero
The ideal is scaling all the way down to zero idle runners when no jobs are running, so off-hours cost nothing. The catch is that scaling from zero reintroduces cold starts - which is why warm pools and autoscaling are usually paired.
Scaling lag
Reacting to demand takes time: detect the queue, launch instances, boot, register. That delay is scaling lag, and it is why a burst can briefly queue before new runners come online.
Autoscaling without the work
Building autoscaling on self-hosted runners means writing and operating controllers. Managed platforms like Latchkey autoscale for you and scale to zero, with warm pools papering over the scale-from-zero cold start.
Key takeaways
- Autoscaling matches runner count to live job demand.
- It avoids both idle waste and peak-time queueing.
- Scaling to zero saves off-hours cost but reintroduces cold starts.
- Managed platforms autoscale for you and pair it with warm pools.