Which Ansible to install on Ubuntu and Rocky

Which Ansible to install on Ubuntu server: the short answer

Which Ansible to install on an Ubuntu server depends less on the control node and more on the Python version of the hosts you manage. For a fleet of Ubuntu 24.04 and 26.04 servers, install ansible-core 2.21 with pipx and hold it on that series. If the fleet still has Ubuntu 20.04 or Enterprise Linux 8 hosts, current ansible-core does not support them as they ship. You then either give those hosts a newer Python or run an older core that has reached end of life.

The comparison below covers install sources only. It does not teach a first playbook. For that, follow writing your first Ansible playbook against a VPS, which uses a pipx install of the full package. All version numbers here were read from the vendors' package archives and docs on 8 November 2026. Your own apt-cache policy or dnf info output is the final word, so each section shows you how to print it.

Two packages: ansible and ansible-core

The Ansible installation guide splits Ansible into two packages. ansible-core is the minimal engine. ansible is the "batteries included" community package: one pinned ansible-core plus a large set of collections.

Each community major release is tied to one core series. The Ansible release and maintenance page maps community 9.x to core 2.16, 13.x to core 2.20, 14.x to core 2.21, and the in-development 15.0.0 to core 2.22. So on Ubuntu 24.04 and 26.04, apt install ansible and apt install ansible-core give you the same core version. The full package adds collections, not a newer engine. The same page says the community team maintains only one major release at a time. That means the 9.x in Ubuntu 24.04 and the 13.x in Ubuntu 26.04 are both outside community maintenance today.

If the words control node and managed node are new to you, read what Ansible is and how it reaches servers over SSH first. In short, Ansible runs on one machine, the control node, and connects to the managed nodes. The installation guide says a managed node "does not require Ansible to be installed, but requires Python to run Ansible-generated Python code." That Python is the number this whole choice turns on.

The column that decides it: Python on the managed host

The support matrix on docs.ansible.com gives two Python ranges for each ansible-core series. One is for the control node. The other is for targets, the hosts you manage. Most install guides only read the first one. Here are both, with the end-of-life (EOL) dates from the same page:

• 2.16: control node Python 3.10 to 3.12. Targets Python 2.7 and 3.6 to 3.12. EOL July 2025.
• 2.17: control node 3.10 to 3.12. Targets 3.7 to 3.12. EOL November 2025.
• 2.18: control node 3.11 to 3.13. Targets 3.8 to 3.13. EOL May 2026.
• 2.19: control node 3.11 to 3.13. Targets 3.8 to 3.13. EOL November 2026.
• 2.20: control node 3.12 to 3.14. Targets 3.9 to 3.14. It moved to security fixes only on 2 November 2026, and full EOL is May 2027.
• 2.21: control node 3.12 to 3.14. Targets 3.9 to 3.14. EOL November 2027.

The matrix has no 2.22 row yet. The PyPI metadata for ansible-core 2.22.0, uploaded on 2 November 2026, declares requires_python >=3.13. The 2.21.5 release declares >=3.12.

Now put the default Python of each distribution next to those ranges. The package archives list Python 3.8.2 on Ubuntu 20.04, 3.10.6 on 22.04, 3.12.3 on 24.04 and 3.14.3 on 26.04. Rocky Linux 8 BaseOS ships platform-python 3.6.8, and Rocky 9's python3 is 3.9.25.

• Ubuntu 20.04 and EL8 targets are below the floor of current core. 2.20 and 2.21 start at target Python 3.9. A stock 20.04 host has 3.8 and Rocky 8 ships 3.6.8, so both are outside the supported range.
• Older core still covers them. 2.16 is the last series that lists 3.6 as a target. 2.18 and 2.19 still list 3.8.
• 2.16 does not reach the newest hosts. Its target range ends at 3.12, so an Ubuntu 26.04 host with 3.14 is outside it.
• Ubuntu 22.04 as a control node tops out at 2.17. Its Python is 3.10, and 2.18 and later need 3.11 or newer on the control node.
• Ubuntu 24.04 as a control node tops out at 2.21. Its Python is 3.12, and 2.22 declares 3.13 or newer.

If old hosts are the reason you are reading this, the lasting fix is on the host side. The upgrade path off Ubuntu 20.04 is worth reading, because Ubuntu's release-cycle page shows 20.04 standard security maintenance ended in May 2025. Only Ubuntu Pro extends it, to May 2030.

Check a target's Python with the raw module

Do not guess what a host runs. Ask it. The raw module runs a command on the host directly and reads the result. Its documentation says it "does not require python on the remote system", so it works on a host where every normal module would fail. It is meant for a few cases like this one. For ordinary commands the docs point you to ansible.builtin.command or ansible.builtin.shell instead.

ansible all -i inventory.ini -m ansible.builtin.raw -a 'python3 --version'

Each host should answer with a line such as Python 3.12.3. A host with no python3 at all reports a non-zero return code and the shell's own "not found" message. If inventories and one-off commands are new to you, how an Ansible inventory file is laid out and running Ansible ad hoc commands cover both.

By default Ansible uses interpreter discovery. The docs say it will "attempt to discover a suitable Python interpreter on each target host", and auto is the default mode. When you install a newer Python on an old host, tell Ansible where it is with the ansible_python_interpreter inventory variable. The discovery docs also warn that a Python installed later can change what auto picks. That is one more reason to set the path yourself on any host where you added an interpreter.

[legacy]
old-app.example.com

[legacy:vars]
ansible_python_interpreter=/opt/python3.12/bin/python3.12

In this example the old host has a Python 3.12 built from source with --prefix=/opt/python3.12. Use the path of the interpreter you actually installed. Then check that normal modules work:

ansible legacy -i inventory.ini -m ansible.builtin.ping

A healthy host returns SUCCESS with "ping": "pong".

Source 1 on Ubuntu: ansible-core from universe

Both packages live in the universe component on Ubuntu, not in main. On 8 November 2026 packages.ubuntu.com listed ansible-core 2.16.3-0ubuntu2 for 24.04 and 2.20.1-1 for 26.04. The full ansible package was 9.2.0 on 24.04 and 13.1.0 on 26.04. Print what your server would install:

sudo apt update
apt-cache policy ansible-core ansible
sudo apt install -y ansible-core
ansible --version

apt-cache policy shows a Candidate: version for each package. ansible --version names the core version on its first line and, further down, the Python version it runs on.

The two releases give you very different tools. 24.04's 2.16 has been past upstream EOL since July 2025. It is still the only archive build here that lists Python 3.6 targets. 26.04's 2.20 is current enough for modern hosts. Upstream moved it to security fixes only on 2 November 2026, and its EOL is May 2027. The packages page shows no noble-updates row for ansible-core, and that page does not say whether universe packages like this one get security fixes. Run pro security-status on the control node to see what your machine is covered for, and do not assume.

Source 2 on Ubuntu: the Ansible PPA

The Ansible docs give these commands for Ubuntu. They install the full ansible package from a PPA (personal package archive) that, in the docs' words, "contains more recent versions than the standard repositories." The install line below also names ansible-core, so that apt moves an already installed universe build to the PPA build too.

sudo apt update
sudo apt install -y software-properties-common
sudo add-apt-repository --yes --update ppa:ansible/ansible
sudo apt install -y ansible ansible-core
apt-cache policy ansible-core
ansible --version

On 8 November 2026 the Launchpad page for ppa:ansible/ansible listed ansible 14.5.0 and ansible-core 2.21.5 for both noble and resolute. After the install, apt-cache policy ansible-core should show the PPA build as the installed version, with the PPA's URL on the line under it. Launchpad shows its standard warning on the page: you "update your system with unsupported packages from this untrusted PPA."

This is the apt route to 2.21. The target floor is therefore Python 3.9 again, the same as pipx. The PPA also publishes for older series, but that does not help a 22.04 control node. 2.21 needs Python 3.12 there, and 22.04 has 3.10. The PPA follows new releases, so a routine apt upgrade takes whatever it publishes next. To freeze the version on a control node, run sudo apt-mark hold ansible ansible-core, and remove the hold when you choose to move.

Source 3 on Ubuntu: pipx, with the core series pinned

pipx installs each Python application into its own isolated environment and adds its commands to your PATH. It runs as your normal user, not root. The pipx docs give this install for Ubuntu 23.04 and newer:

sudo apt update
sudo apt install -y pipx
pipx ensurepath

Open a new terminal so the PATH change applies. Then install the core series you want, with an upper bound:

pipx install "ansible-core>=2.21,<2.22"
ansible --version

The range matters most on Ubuntu 26.04. Its Python 3.14 meets 2.22's requirement, so an install without the bound takes 2.22.0 today. On Ubuntu 24.04, pip itself stops at 2.21.x, because 2.22 declares Python 3.13 or newer and the system Python is 3.12.

The range at install time is not a lock. The pipx CLI reference says pipx upgrade runs pip install --upgrade PACKAGE, and it does not say that the original range is kept. The pin command is the real lock. The pipx docs say pipx upgrade and pipx upgrade-all skip pinned environments. pipx pin arrived in pipx 1.6.0, so check your version first:

pipx --version

Ubuntu 26.04 ships pipx 1.8.0, so it has the command. There, run pipx pin ansible-core and confirm the lock with pipx list --pinned. To take a newer 2.21 patch release later, run pipx unpin ansible-core and pipx uninstall ansible-core, install again with the same range, and pin again. Ubuntu 24.04 ships 1.4.3, which has no pin command, and there the Python 3.12 limit above does the same job for now.

For the full community package, the installation guide uses pipx install --include-deps ansible. If you are unsure whether pipx, a plain venv or uv fits your server, the venv, pipx and uv comparison explains how each one isolates a tool.

Rocky Linux 9: ansible-core from AppStream

On Rocky 9 the core comes from the AppStream repository.

dnf info ansible-core
sudo dnf install -y ansible-core
ansible --version

On 8 November 2026 the only ansible-core in Rocky 9 AppStream was 2.14.18, and the newest build was dated 20 August 2026. The ansible-core 2.16 docs list 2.14 as EOL on 20 May 2024, with control node Python 3.9 to 3.11 and targets Python 2.7 and 3.5 to 3.11. The recent build date shows the distribution still rebuilds it. The target range has a practical effect: 2.14 covers EL8 and Ubuntu 20.04 hosts, but Ubuntu 24.04 (3.12) and 26.04 (3.14) are outside it.

You may hope EPEL (Extra Packages for Enterprise Linux) has something newer. EPEL 9 does ship the full ansible package, but it is 7.7.0, and the package file is dated November 2023. Community 7.x pairs with core 2.14, so it adds collections and not a newer engine. If EPEL is not enabled yet, enabling EPEL and CRB on Rocky and Alma shows how. Then check it yourself:

dnf info ansible

Rocky Linux 9: a newer core on python3.12

Rocky 9 AppStream also ships python3.12 (3.12.15 on 8 November 2026), which meets 2.21's control node range. A plain virtual environment works without pipx:

dnf info python3.12
sudo dnf install -y python3.12
python3.12 -m venv ~/ansible-2.21
~/ansible-2.21/bin/pip install "ansible-core>=2.21,<2.22"
~/ansible-2.21/bin/ansible --version

pip accepts the install because 2.21.5 declares Python 3.12 or newer. ansible --version should report core 2.21 and a Python 3.12 path inside ~/ansible-2.21. A venv only moves when you run pip in it. To take patch releases, run the same range again:

~/ansible-2.21/bin/pip install --upgrade "ansible-core>=2.21,<2.22"

Which Ansible to install for your fleet

Read your fleet's oldest and newest target Python first. Then pick the case that matches, and accept its support cost knowingly.

Newest servers only: Ubuntu 24.04, 26.04 and Rocky 9

• Install: pipx with ansible-core>=2.21,<2.22, or the PPA if you want apt to manage it.
• What it manages: targets from Python 3.9 to 3.14, so every host in this group.
• Support cost: upstream EOL for 2.21 is November 2027. On a 24.04 control node 2.21 is the last series you can run, so plan to move the control node to 26.04 before then. Ubuntu lists standard security maintenance until May 2029 for 24.04 and May 2031 for 26.04.

Mixed fleet with Ubuntu 20.04 or EL8 targets

• Preferred: keep current core on the control node. Give each old host a newer Python and set ansible_python_interpreter for it.
• Its cost: you maintain an extra interpreter on hosts that are near their own end. Ubuntu 20.04 needs Ubuntu Pro for security fixes until May 2030, and Rocky 8 reaches EOL on 31 May 2029.
• Fallback: Ubuntu 24.04's apt ansible-core 2.16, which lists targets from 3.6 to 3.12.
• Its cost: it has been past upstream EOL since July 2025, and it does not cover 26.04 hosts. Once 26.04 servers join the fleet, you need a second control environment beside it.

A RHEL-family control node

• AppStream 2.14: fits EL8 and 20.04 targets. Upstream EOL was May 2024, and the build lives as long as Rocky 9, which reaches EOL on 31 May 2032 (active support ends 31 May 2027). Ubuntu 24.04 and 26.04 hosts are outside its target range.
• python3.12 venv with 2.21: covers modern targets until November 2027. The cost is that you own every upgrade, because dnf does not touch that venv.

FAQ

Should I install ansible or ansible-core?

Install ansible-core if you only need the built-in modules, or if you add collections yourself with ansible-galaxy. Install ansible if you want the large community set of collections in one step. On Ubuntu 24.04 and 26.04 both carry the same engine: each community release is tied to one core series, for example community 14.x to core 2.21. So the choice changes which collections you get, not which hosts you can manage.

Can current Ansible manage Ubuntu 20.04 servers?

Not as they ship. The Ansible support matrix lists target Python 3.9 to 3.14 for ansible-core 2.20 and 2.21, and stock Ubuntu 20.04 has Python 3.8. Either install a newer Python on the 20.04 host and set ansible_python_interpreter to it, or manage it with an older core such as 2.19 (targets 3.8 to 3.13, EOL November 2026). Upgrading the host is the lasting fix.

Why can my Ubuntu 22.04 control node not run the newest ansible-core?

Ubuntu 22.04 ships Python 3.10. According to the Ansible support matrix, 2.17 is the last series that runs on a 3.10 control node, because 2.18 and later need Python 3.11 or newer. 2.17 reached EOL in November 2025. Move the control node to Ubuntu 24.04 or 26.04, which ship Python 3.12 and 3.14.

How do I stop pipx from moving ansible-core to a new series?

Install with a range, pipx install "ansible-core>=2.21,<2.22", then run pipx pin ansible-core. The pipx docs say pipx upgrade and pipx upgrade-all skip pinned environments. The pin command needs pipx 1.6.0 or newer. Ubuntu 26.04 ships 1.8.0, while Ubuntu 24.04 ships 1.4.3 without it. On 24.04, pip cannot pick 2.22 anyway, because 2.22 requires Python 3.13 and the system Python is 3.12.

Is the ansible-core in Rocky 9 AppStream current?

No. Rocky 9 AppStream ships ansible-core 2.14.18, and the Ansible project ended support for 2.14 on 20 May 2024. Rocky still rebuilds the package, but its documented target range ends at Python 3.11, which leaves out Ubuntu 24.04 and 26.04 hosts. For a newer core, install python3.12 from AppStream and put ansible-core 2.21 in a virtual environment.