What is Ansible and what is it used for?

What is Ansible and what does it do?

Ansible is an open source IT automation tool. You describe how your servers should look in a YAML file (a plain text data format), and Ansible connects to them over SSH (secure shell) and makes them match. It is mainly used to configure many servers the same way, apply patches, deploy applications and repeat a new-server setup. The servers it manages run no Ansible agent.

The project's README lists configuration management, application deployment, cloud provisioning and ad-hoc task execution among its jobs. The rest of this page explains the model and the confusing product names. It also covers when you do not need Ansible at all.

What is Ansible mainly used for?

Red Hat names installing software, automating daily tasks, provisioning infrastructure and applying patches among its uses. On a small group of servers, that means jobs like these:

• Configuring a fleet. Every server gets the same packages and config files, because they all run the same playbook. This helps when managing multiple Linux servers by hand becomes slow.
• Patching. One run applies updates to every server in a group, so you do not log in to each one. Reboots need more care, and rebooting only when an update needs it is a separate job.
• Deploying an app. A playbook copies the new release and restarts the service, in the same order every time.
• Repeating a new-server setup. The steps you typed by hand on your first VPS become a file. A new server then needs its address in the inventory and one run of that file.
• One-off jobs. Ansible ad-hoc commands run a single task across your servers without a playbook.

Ansible can also create cloud resources, because provisioning is on its list. Whether it should do that job is a separate question, and Ansible vs Terraform for provisioning answers it.

How does Ansible work?

Five terms explain the whole model.

• Control node. The machine where you run the Ansible tools, such as ansible-playbook. It can be nearly any UNIX-like machine with Python installed.
• Managed nodes. The target devices you want to manage, for example your VPS servers.
• Inventory. The list of managed nodes. You can group them, and the Ansible inventory file has its own guide.
• Modules. Small programs that do the real work. Ansible pushes them to each managed node, runs them there and removes them when they finish.
• Playbooks. Human-readable YAML files. A playbook holds one or more plays, and the tasks inside a play call modules.

A playbook states the result you want. This short one says that a group of servers called web should have nginx installed and running:

- name: Set up the web servers
  hosts: web
  become: true
  tasks:
    - name: nginx is installed
      ansible.builtin.apt:
        name: nginx
        state: present

    - name: nginx is running and starts at boot
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Tasks run in order from top to bottom. By default, each task runs on all matched servers before the next task starts. This example only shows the shape of a playbook. To write and run a real one, follow the first Ansible playbook tutorial.

What does agentless mean in Ansible?

Agentless means you do not install an Ansible agent on each server. Ansible reaches the server over SSH when you run it, and the modules are gone when they finish.

Red Hat's overview says managed nodes need no software installed. The installation docs are more exact. A managed node needs Python, because Ansible generates Python code to run there. It also needs a user account that can connect through SSH with an interactive POSIX shell (a standard Unix-style command shell). So "no agent" is the accurate claim, and "nothing needed on the server" is too strong.

There is one exception. Ansible is not normally installed on managed nodes, unless you use ansible-pull. This page describes Linux servers reached over SSH. If you manage Windows hosts or network devices, read the Ansible docs for that platform first.

What does idempotent mean in Ansible?

Idempotent means you can run the same thing again and the result stays the same. The Ansible docs state it directly: when the system is in the state your playbook describes, Ansible does not change anything.

This works because most modules first check whether the desired final state already exists. If it does, they exit without acting. For example, the docs for the service module say state: started will not run commands unless necessary. A second run of the playbook above should find nginx running and leave it alone.

The caveat comes from the same docs: not all playbooks and not all modules behave this way. The ansible.builtin.command module has a creates option for this reason. If the named file already exists, the step does not run. Without a check like that, the step runs every time. The docs advise testing in a sandbox if you are unsure, and Ansible check mode shows what a run would change.

Ansible vs a shell script: what is the real difference?

This section is our judgement, and no benchmark sits behind it.

A shell script is a list of steps. It runs the steps you wrote, in the order you wrote them. Whether a second run is safe depends on how you wrote each step.

A playbook declares a result, and the modules do the checking described above. That is the real difference. The inventory adds a second one: the same file can target one server or a whole group.

The cost is that you must learn a new tool and keep a control node. If you want to know how large that cost is, read how hard Ansible is to learn.

When does one server not need Ansible?

If you have one server, you set it up once and a rebuild would not hurt you, you probably do not need Ansible. A short script or a written list of commands is less to learn.

The answer changes in two cases. You expect to rebuild the server, or a second server appears. A playbook is then a record of how the server was built, and you can run it again.

Which Ansible is which? The names explained

Readers often trip on these names, because several of them contain the word Ansible.

• ansible-core. The minimal language and runtime, with a set of built-in modules and plugins.
• ansible. The community package. It is much larger, because it adds a community-curated selection of collections (packaged sets of Ansible content) on top of ansible-core. The two packages use different version numbers, so check the Ansible support matrix before you match them.
• Red Hat Ansible Automation Platform. Red Hat's supported enterprise product. It is built on the same fundamentals as community Ansible, and it combines more than a dozen upstream projects.
• Automation controller. The part of Ansible Automation Platform that used to be called Ansible Tower. Red Hat's blog post about Platform 2 calls it "the improved and renamed Red Hat Ansible Tower".
• AWX. An open source web interface and REST API (an HTTP interface for programs) with a task engine, built on top of Ansible. It is one of the upstream projects for Ansible Automation Platform. Its README says releases are paused during a large refactoring. As of November 2026, the last release shown on GitHub is from July 2, 2024.
• Ansible Galaxy. A free site for finding and sharing community collections and roles. The ansible-galaxy command comes bundled with Ansible. If roles are new to you, see the difference between an Ansible playbook and a role.

Who owns Ansible?

Ansible was created by Michael DeHaan. The project is licensed under GPL-3.0-or-later (the GNU General Public License), and its README says it is sponsored by Red Hat, Inc.

Red Hat announced an agreement to acquire Ansible on October 16, 2015. IBM closed its purchase of Red Hat on July 9, 2019, and Red Hat operates as a distinct unit within IBM. So the chain is this: Red Hat agreed to buy Ansible, then IBM bought Red Hat.

For a reader who only wants to automate a few servers, the practical split is simple. The open source project is what you install on your control node. Ansible Automation Platform is what Red Hat sells to companies that want a supported product.

FAQ

Is Ansible free to use?

The Ansible project is open source under the GPL-3.0-or-later license, and Ansible Galaxy is a free site. Red Hat Ansible Automation Platform is a separate supported enterprise product. Red Hat's product page offers a trial and links to a separate pricing page.

Does Ansible need an agent on the server?

No. Ansible connects over SSH, so you do not install an agent on a managed node. The node still needs Python and a user account that can connect through SSH with an interactive POSIX shell. The exception is ansible-pull, which is the one case where Ansible is normally installed on managed nodes.

What is the difference between ansible and ansible-core?

ansible-core is the minimal runtime with a set of built-in modules and plugins. The ansible community package is much larger, because it adds a community-curated selection of collections on top. The two use different version numbers, so check the support matrix on docs.ansible.com.

Does IBM own Ansible?

IBM owns Red Hat, and Red Hat agreed to acquire Ansible in October 2015. IBM closed its Red Hat purchase on July 9, 2019, and Red Hat operates as a distinct unit within IBM. The open source project's README says Ansible is sponsored by Red Hat, Inc.

Can I run Ansible from Windows?

Windows without WSL (Windows Subsystem for Linux) is not natively supported as a control node. The control node can be nearly any UNIX-like machine with Python installed, so use WSL or run Ansible from a Linux machine or a VPS.