Ansible: agentless IT automation over SSH, and where it stops being the right tool

What Ansible solves, and who actually needs it

The problem is the gap between a machine you configured by hand once and the same machine six months later on ten other hosts. Ansible closes that gap by letting you describe the end state of a system in a file, then applying it over the SSH daemon that is already running on the target. Nothing is installed on the remote side, no port beyond 22 is opened, and a new machine can be managed the moment it answers SSH. That is the design principle the README states most plainly: avoid custom agents and additional open ports, be agentless by leveraging the existing SSH daemon.

The audience is system administrators, developers and information technology teams, which is exactly how pyproject.toml classifies the package. It fits teams that already have SSH access to their hosts and want configuration management, application deployment, cloud provisioning and ad-hoc task execution from one tool. The README also lists network automation and multi-node orchestration, and calls out zero-downtime rolling updates with load balancers as an example of a complex change it is meant to make easy.

The honest boundary is that Ansible is a configuration and orchestration tool, not a scheduler and not a state machine. It runs when you invoke it. Between runs, nothing watches the host. If that distinction matters to your environment, read the limitations section before anything else.

The mechanism: a control node pushes modules over SSH

The repository layout tells you a lot about the architecture. lib/ holds the Python package, bin/ holds the command line entry points, test/ holds the test suite, and packaging/ holds distribution metadata. The runtime dependency list is deliberately short: requirements.txt says it is the loosest set possible, only required packages, and names jinja2, PyYAML, cryptography, packaging and resolvelib. Jinja2 is what renders templated values inside playbooks; PyYAML parses the YAML files; resolvelib is described in the file as the dependency resolver used by ansible-galaxy, which is how collections get their dependencies resolved.

Execution flows in one direction. You run a command on the control node, it reads an inventory of hosts and a playbook, and for each task it connects to the target over SSH, copies a module, runs it, and collects the JSON result. Because the module runs on the remote host, the remote host needs a Python interpreter; the README's claim that module development is allowed in any dynamic language does not remove that requirement for the standard Python modules.

Two consequences follow. First, the control node is a single point of failure and of load: parallelism is a property of the machine you run from. Second, because the module executes remotely and returns data, the control node never needs inbound connectivity, which is why the model survives restrictive networks where a pull-based agent would need a listener.

Collections extend this. ansible-galaxy fetches content from Galaxy and resolves its dependencies with resolvelib, so a playbook can depend on modules that are not in the core package. That separation is why the README points contributors at devel and stable-2.X branches rather than at a single monolith.

Installing ansible-core and what the first run looks like

The README says a released version of Ansible can be installed with pip or a package manager, and points to the installation guide for platform-specific detail. The package name declared in pyproject.toml is ansible-core, and the build backend is setuptools.build_meta. The same file sets requires-python to 3.13 or newer, so the interpreter on the control node is a hard constraint before any of this works.

A pip install therefore looks like this:

pip install ansible-core

What you should see is pip resolving the five runtime dependencies named in requirements.txt: jinja2, PyYAML, cryptography, packaging and resolvelib. If pip instead reports that no matching distribution was found, the usual cause is an interpreter older than 3.13, and that is a control-node problem, not a managed-host one.

The README does not print a sample playbook or a sample inventory, and it does not list the flags for the command line tools. That absence is worth noting on its own: the repository's front page is a pointer to the documentation site rather than a tutorial, so the first playbook is something you write from the docs, not from the README. What the README does tell you is the shape of the work. It lists configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation and multi-node orchestration as the things Ansible handles, and it names zero-downtime rolling updates with load balancers as the kind of complex change the tool is meant to make easy.

For a first check that the control node can reach its inventory and that the remote side has a usable interpreter, the ad-hoc path is the shortest one. The README describes ad-hoc task execution as a supported use but does not give the invocation, so treat the exact flags as documentation territory. The property to verify on the first run is that the remote host answers over SSH and returns a result, because every later playbook depends on that.

Where the push model breaks down

The most important limitation is the one the design implies rather than states: Ansible does not converge on its own. If someone edits a config file on a managed host at 3am, nothing corrects it until the next playbook run. Tools built around a long-running agent on the host have the opposite property. If your compliance story depends on continuous enforcement, a push-only tool leaves a window you have to cover with scheduled runs, and scheduled runs are a cron job you now own.

Scale is the second constraint. Because the control node drives every connection, throughput is bounded by that machine's CPU, file descriptors and network, and by the SSH handshake cost per host. The README's stated goal is to manage machines quickly and in parallel, and parallelism exists, but it is parallelism on one node. Very large fleets generally end up with multiple control nodes or a different execution model.

The third is Python on the target. The control node requires Python 3.13 or newer per pyproject.toml, and the managed node needs a Python interpreter for the standard modules. Network devices and appliances that expose only a CLI or an API are handled through connection plugins rather than SSH-to-Python, and that is a different code path with its own module set. If your estate is mostly switches and firewalls, evaluate the network modules specifically rather than assuming the server workflow transfers.

Finally, the devel branch. The README is explicit that running devel means you are more likely to encounter breaking changes. If you are not prepared to track that, pin to a stable release line.

Ansible compared with Terraform: different verbs

The comparison people search for most is Ansible against Terraform, and the difference is in what each one treats as its subject. Terraform's subject is infrastructure resources: it holds a state file recording what it believes exists, plans a diff against that record, and applies the difference. Ansible's subject is hosts and the tasks you run against them. There is no state file in the core workflow, and no plan-then-apply cycle in the Terraform sense.

That produces a practical split. Provisioning a VPC, a load balancer and a managed database is a resource graph problem, and a state file is what lets the tool detect drift and destroy resources it created. Configuring the operating system inside those instances, installing packages, placing files and restarting services, is a host problem, and Ansible's inventory plus modules fit it without a state file to store and protect.

Ansible does have cloud provisioning modules, and the README lists cloud provisioning as a supported use. The distinction is not that one tool can and the other cannot; it is that Ansible applies tasks to hosts and Terraform reconciles a recorded resource graph. Teams commonly run both, using one to create the machines and the other to configure them. If you are choosing a single tool, choose based on whether your hard problem is resource lifecycle or host configuration.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-10, the same date as the v2.21.3, v2.20.8 and v2.19.12 releases. Three release lines receiving builds on one day is the clearest signal about upgrade cost: the project maintains parallel stable branches, and the README describes stable-2.X as corresponding to stable releases while devel is the branch actively under development. You are not forced onto the newest line the day it ships.

That said, the version numbers in the package metadata move. pyproject.toml requires Python 3.13 or newer and classifies the package for 3.13, 3.14 and 3.15. A control node on an older Python is a migration you will have to schedule, and it is a control-node problem only, since managed hosts run whatever interpreter the modules need.

Collections carry their own upgrade cost. resolvelib is pinned with an upper bound below 2.0.0, and requirements.txt warns that resolvelib 0.x version bumps should be considered major or breaking and that the upper cap should be updated with care. That is a dependency-resolution constraint inside ansible-galaxy, not something you can tune from a playbook.

On licensing: the project is GPL-3.0-or-later, and pyproject.toml declares license = "GPL-3.0-or-later" with license-files covering COPYING and licenses/*.txt. The README states the project is sponsored by Red Hat. If you redistribute Ansible or build a product around it, the copyleft terms are the thing to read in COPYING before you decide how it ships. That is a question for your own counsel, not something this review can settle.

Editorial conclusion

Adopt Ansible when your fleet is reachable over SSH, your team wants a readable YAML description of desired state, and you can live with a push model that has no continuous reconciliation. Do not adopt it as a replacement for a state-reconciling controller on long-lived, constantly drifting hosts, and do not expect it to provision bare infrastructure the way a declarative provisioning tool does. Before committing, verify that your control node runs Python 3.13 or newer, since pyproject.toml sets requires-python = ">=3.13", and check whether the collections you depend on ship for the release line you install.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes