Ansible Execution Strategies: Linear vs Free for Deployment Speed

The problem: one slow host holds up the whole playbook

You run an Ansible playbook against ten application servers. Nine finish a package update in thirty seconds. One takes four minutes because of a slow package mirror. With the default execution behavior, Ansible will not start the next task on any host until every host has finished the current one. Your total run time is governed by the slowest node, not the average.

The useful takeaway is simple: Ansible lets you choose between two built-in execution strategies. Use linear when tasks must stay synchronized across hosts. Use free when each host can work through the playbook independently, and you want faster total completion in mixed-speed environments.

How the linear strategy works

Linear is the default. Ansible executes one task across the entire batch of target hosts before any host begins the next task. Think of it as a barrier: no host passes the finish line for task one until the last host crosses it.

This is necessary for rolling updates. For example, if a task removes a server from a load balancer, the next task restarts that server, and a later task returns it to the pool, every host must move through those steps together. Otherwise one host could be restarted while another is still receiving traffic.

How the free strategy works

With strategy: free, each managed node runs through the playbook as fast as it can, without waiting for other hosts. Host A can be on the final task while host B is still on the first.

This reduces wall-clock time in heterogeneous fleets, but it changes what the output looks like. Log lines from different hosts interleave, so you cannot read a single host's playbook run top-to-bottom without filtering. It also introduces risk: if one task writes to a shared file or depends on another host being in a specific state, free execution can create race conditions.

Worked example: switching strategies in a playbook

You set the strategy at the play level with the strategy keyword. This example runs a simple update playbook against an inventory file.

---
- name: Update application servers
  hosts: webservers
  strategy: free
  become: true

  tasks:
    - name: Ensure nginx is installed
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

Run this from your Ansible control node, the machine where Ansible is installed and from which you execute commands:

ansible-playbook -i [inventory-file] [playbook.yml]

Replace [inventory-file] with your inventory path and [playbook.yml] with the playbook path. The account running the command needs read access to those files and SSH access to the managed nodes, or become privileges if tasks use become: true.

To compare, copy the playbook and change strategy: free to strategy: linear, or omit the keyword entirely because linear is default. Run both against the same hosts and observe the order in which tasks complete. With linear, you should see all hosts finish the package install before any host starts the service restart. With free, hosts may restart the service at different times.

A practical way to verify the current default on your control node is:

ansible-config dump | grep DEFAULT_STRATEGY

This prints the configured default strategy for your installation. You do not need to change ansible.cfg unless you want a project-wide default; the playbook keyword overrides it for that play.

Trade-offs and limitations

• Free strategy is unsafe for tasks that require synchronization, such as draining connections from a load balancer before restarting nodes.
• Interleaved output makes debugging harder. You may need callback plugins or log filtering to follow one host's execution.
• Custom strategy plugins require placing files in the strategy plugin directory configured in ansible.cfg, which adds maintenance overhead.

Actionable closing

Start by measuring your current runs. If one slow host consistently extends your playbook time and your tasks do not depend on each other, switch to strategy: free for that play. If your playbook includes rolling restarts, load balancer changes, or shared state, keep linear. Check your default with ansible-config, test the change on a small inventory subset first, and revert the keyword if you see inconsistent results.

Changing the strategy keyword is a configuration change, not a data mutation. If a free run produces unexpected ordering, edit the playbook back to strategy: linear and rerun.