⚡ Tuning Ansible With Mitogen and the Free Strategy Using AI

Strategy plugins are the part of Ansible most engineers never touch, which is a shame, because they control the single most impactful thing about a run: the order tasks execute across hosts. The default linear strategy runs each task on every host before moving to the next task. It’s predictable and it’s why your output reads top to bottom in a sane order. It’s also why a fleet of fifty hosts waits for the slowest one at every single task. There are two well-known ways to claw that time back, and both deserve more attention than they get: the built-in free strategy and the third-party Mitogen connection layer.

I lean on AI here not to write code but to reason through tradeoffs, because performance tuning is where confident-sounding advice does the most damage. “Just add Mitogen” is the kind of tip that doubles your throughput right up until it breaks a module that does something Mitogen doesn’t expect. So I use the model to lay out the mechanics and the risks, and I verify every claim against a real run before I believe it.

How the linear strategy holds you back

Picture fifty hosts and a playbook of twenty tasks. Under linear, task one runs on all fifty, and Ansible waits for the slowest host before starting task two. One sluggish host — a slow disk, a busy box — stalls the entire fleet at every step. The total runtime is essentially the sum of each task’s slowest host, multiplied across the play. For homogeneous, fast fleets that’s fine. For anything with stragglers, it’s a tax you pay on every run.

You can see the strategy in play in your config:

[defaults]
strategy = linear
forks = 5

That forks = 5 is the other half of the story and the first thing to fix. Forks is how many hosts Ansible talks to in parallel. The default of five is conservative to the point of being a bottleneck on any real fleet. Bumping it is the cheapest speedup there is.

The free strategy: let fast hosts run ahead

The free strategy removes the per-task barrier. Each host races through the playbook as fast as it can, without waiting for the others. Your fast hosts finish in minutes while the slow ones take their time, instead of everyone moving at the pace of the slowest.

[defaults]
strategy = free
forks = 25

The tradeoff is real and worth stating plainly. Output is no longer neatly ordered, so logs are harder to read. More importantly, free weakens cross-host ordering guarantees: any orchestration that assumes “all hosts finished task N before any starts task N+1” — a rolling deploy, a coordinated migration — can break. If your play has genuine ordering dependencies across hosts, free is the wrong tool. For independent, embarrassingly-parallel work like patching or config convergence, it’s a clean win.

Here’s the kind of question I put to AI when I’m deciding:

I have a 60-host config-convergence playbook. No task depends on another host having finished. Output readability doesn’t matter, speed does. Walk me through whether free strategy is safe here, what could break, and how I’d confirm the speedup without risking a bad run.

The answer I want isn’t “yes, use free.” It’s the list of conditions under which free is safe and the ones under which it isn’t — so I can check my playbook against them.

Mitogen: faster connections, more caveats

Mitogen for Ansible is a connection and strategy layer that replaces the default SSH-and-Python-fork model with a persistent, more efficient one. The headline is dramatically reduced overhead per task, especially for playbooks with many small tasks, because it stops re-establishing the heavy module-execution machinery on every step.

[defaults]
strategy = mitogen_linear
strategy_plugins = /path/to/ansible_mitogen/plugins/strategy
forks = 25

The caveats matter more than the config. Mitogen is a third-party project that hooks deep into Ansible internals, so it tends to lag new ansible-core releases and can interact badly with certain modules, become methods, or connection plugins. The failure mode is nasty: a module that works fine under the default strategy misbehaves under Mitogen in ways that look like the module’s fault. This is precisely why I never take a blanket “use Mitogen” recommendation at face value.

Pro Tip: Treat Mitogen as an opt-in optimization for a specific, tested playbook — not a global default you set and forget. Pin its version against your ansible-core version and re-verify after any upgrade of either.

Verifying the gain instead of assuming it

This is where AI-assisted reasoning has to give way to measurement. The honest way to evaluate any strategy change is to run the same playbook both ways and compare, with profiling on:

[defaults]
callbacks_enabled = profile_tasks, timer

# Baseline
ansible-playbook site.yml --limit canary_group

# Same play, free strategy or mitogen, same hosts
ANSIBLE_STRATEGY=free ansible-playbook site.yml --limit canary_group

The timer callback prints total wall-clock time at the bottom of each run; profile_tasks shows where the time actually went. Run against a small canary group first, in check mode where the tasks support it, and compare. If free or Mitogen genuinely helps your workload, the timer makes it obvious. If it doesn’t — and for some playbooks it won’t — you’ve learned that for the cost of two runs instead of a production incident.

I also watch for correctness, not just speed. A faster run that quietly changed task ordering or tripped a module under Mitogen is not a win. So the canary run gets the same scrutiny as any change: read the output, confirm changed/ok counts match the baseline, then widen the blast radius.

Picking the right lever

There’s a natural order to these levers, cheapest and safest first:

1. Raise forks. Almost always safe, often the biggest single win on a fleet that’s been running with the default five.
2. Enable pipelining. A connection-level optimization that cuts SSH round-trips; safe on most setups as long as requiretty is off in sudoers.
3. Switch to free strategy. Safe for independent work, dangerous for cross-host orchestration.
4. Adopt Mitogen. The biggest potential gain and the biggest caveat surface; opt-in, version-pinned, verified per playbook.

Work down that list and stop when you’ve hit your target. Most teams get most of the win from forks and pipelining alone and never need the riskier options.

The throughline is the same one that applies to every AI-assisted Ansible decision: let the model lay out mechanics and tradeoffs, then verify the actual behavior against a real, profiled, canary run before you trust it. Performance tuning rewards measurement and punishes assumptions.

For related performance work see tuning Ansible performance with forks, pipelining, and fact caching and the wider AI for Ansible category. To frame a strategy decision for an AI assistant, browse the Ansible prompts.