Guides
How to size runners for Node test suites
Jest or Vitest workers are either starving or thrashing and you are not sure which.
4 min read
Jest or Vitest workers are either starving or thrashing and you are not sure which.
Why it happens
Node test suites are usually I/O-bound during install and CPU-bound during execution, so the right size differs per phase.
How to fix it
- 4 vCPU suits most suites; set --maxWorkers explicitly to the core count
- Watch memory — each worker holds its own module graph and OOM shows up as exit code 137
- Prefer local NVMe over more cores; install is disk-bound, not CPU-bound
- Shard across runners only once a single runner is genuinely saturated
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.