Guides
How to size runners for Java builds
You are guessing at a runner size for a Maven or Gradle build.
4 min read
You are guessing at a runner size for a Maven or Gradle build.
Why it happens
JVM builds are memory-hungry before they are CPU-hungry, and GC thrash looks exactly like a slow build.
How to fix it
- Start at 8 vCPU with 4 GB per vCPU; Gradle and Maven both parallelise across modules
- Give the JVM enough heap — an undersized heap costs more than an undersized CPU
- Watch for the configuration phase, which is single-threaded and unaffected by core count
- Scale up only if module-level parallelism is actually saturating the 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.