Ansible Guide
Playbook execution sizing

Ansible Forks Calculator

A planning estimate for the forks value in ansible.cfg, the memory a control node needs to sustain it, and roughly how long a play of that size takes to sweep an inventory. Everything is computed in your browser and nothing is sent anywhere.

Starting forks
24 forks
Control node memory
10.0 GB
Estimated play runtime
1.7 min

What the model assumes

These are planning heuristics, not measurements. They turn a host count into a starting point you can verify against your own control node, and every figure below is a stated assumption rather than an observation.

  • Starting forks is one fork per five hosts, floored at 5 and capped at 50. Ansible's shipped default is 5 regardless of inventory size, so almost any estate above a handful of machines starts under-parallelised.
  • Control node memory assumes roughly 250 MB per fork plus a base allocation: 1 GB for a plain CLI control machine, 4 GB for an AWX or Automation Controller node, which carries a web tier, a database connection pool and a task queue alongside the run. The figure is never reported below 4 GB, since a control node under that is constrained by something other than the fork count.
  • Runtime assumes 0.8 s of per-host, per-task cost with pipelining enabled and 2.2 s without it, multiplied by the number of fork waves the inventory needs. Pipelining is off by default because it conflicts with sudo where requiretty is set, so the slower figure is what an untuned estate gets.
  • The runtime figure assumes the default linear strategy, where every host finishes a task before any host starts the next. A play whose per-host duration varies widely behaves differently.

Raise forks in steps and watch control node memory and CPU as you do. Each fork is a process holding an outbound connection, so the ceiling is the control node, not the inventory.

Read next