Guides
How to size runners for Docker builds
You are choosing a runner size for image builds.
4 min read
You are choosing a runner size for image builds.
Why it happens
Docker builds are usually cache- and network-bound rather than CPU-bound, so a larger runner often changes nothing.
How to fix it
- 8 vCPU is enough for most images — check whether you are actually CPU-bound first
- If layers are being rebuilt, fix the cache before touching the size
- Use a remote builder so the size of the orchestrating runner stops mattering
- Compile-heavy images are the exception and do benefit from more cores
Your next build could be twice as fast, at half the price
Start free. Migrating away is the same one line, and we publish that diff too.
Related
How to scale self-hosted runnersSelf-hosted runners either queue at peak or sit idle and expensive.How to use runner groupsAny repository can schedule jobs on any runner.How to design a runner label strategyLabels grew organically and nobody knows which to use.Hosted or BYOC: how to chooseYou are unsure whether to use hosted runners or deploy into your own cloud.