ansible-core versus the ansible community package · Ansible

There are two things on PyPI called Ansible, and installing the wrong one for your situation is the first version incident of most estates.

ansible-core is the language, the runtime and exactly one collection: ansible.builtin. It gives you ansible, ansible-playbook, ansible-inventory, ansible-galaxy, ansible-doc, ansible-config, ansible-vault and the roughly seventy modules that ship inside ansible.builtin — copy, template, service, package, user, file, command, apt, dnf, and the rest of the set every playbook uses. Nothing else.

The ansible community package is ansible-core plus a curated batch of external collections, selected and version-locked by the Ansible community release process. It is a distribution: one download, a few hundred megabytes, and support for AWS, Azure, VMware, half the network vendors on earth, and community.general.

Both are legitimate. They answer different questions.

The version numbers do not line up, and that is deliberate

This is the single most common confusion. ansible-core and ansible carry unrelated version numbers.

`ansible` community package	`ansible-core` underneath
11.x	2.18
12.x	2.19
13.x	2.20
14.x	2.21

So “we run Ansible 13” and “we run Ansible 2.20” can describe the same machine. When a colleague reports a version, ask which number they read. When a bug report says “fixed in 2.21”, that is a core version, and you need to know which community release carries it.

You can settle it in one command on any controller:

Read-only / Safethe only version answer that is not ambiguous— Reports the ansible-core version regardless of which package installed it, plus the Python interpreter and the config file actually in effect.

$ ansible --version

ansible [core 2.21.3]
config file = None
configured module search path = ['/home/ops/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /home/ops/.venvs/estate/lib/python3.14/site-packages/ansible
ansible collection location = /home/ops/.ansible/collections:/usr/share/ansible/collections
executable location = /home/ops/.venvs/estate/bin/ansible
python version = 3.14.4 (main, Jun 18 2026, 14:25:02) [GCC 15.2.0] (/home/ops/.venvs/estate/bin/python3)
jinja version = 3.1.6
pyyaml version = 6.0.3 (with libyaml v0.2.5)

ansible --version always reports core. There is no --version that prints 14.2; if you need the community package number, ask pip for it (pip show ansible).

What the difference looks like on disk

The contrast is not rhetorical. Here are two controllers on the same machine, one built from ansible-core alone and one from a distribution-packaged community release.

Read-only / Safeansible-core, freshly installed, nothing pinned yet— A core-only controller. This command prints no rows at all - not an error, not an empty table, simply nothing - because ansible.builtin is not a separately installed collection.

$ ansible-galaxy collection list

Nothing is printed. That empty output is the point of ansible-core: whatever appears in that list later got there because a requirements.yml in your repository asked for it, at a version you wrote down.

The same command against the distribution’s ansible package on the same host:

Read-only / Safethe community package, as shipped— Truncated. The full listing on this machine is 91 collections, none of which were individually chosen.

$ ansible-galaxy collection list

# /usr/lib/python3/dist-packages/ansible_collections
Collection                               Version
---------------------------------------- -------
amazon.aws                               10.1.2
ansible.netcommon                        8.2.0
ansible.posix                            2.1.0
ansible.utils                            6.0.0
ansible.windows                          3.3.0
arista.eos                               12.0.0
awx.awx                                  24.6.1
azure.azcollection                       3.12.0
check_point.mgmt                         6.7.0
chocolatey.chocolatey                    1.5.3
cisco.aci                                2.13.0
cisco.dnac                               6.43.0
...

Ninety-one collections. An estate that manages fifteen Debian web servers uses perhaps three of them. The other eighty-eight are code on the controller’s import path that nobody in the organisation has read, reviewed, or chosen.

Why this course installs core and pins collections

Not because the community package is bad. Because of what happens on upgrade day.

When you upgrade the community package from 13.x to 14.x, you change ansible-core and you change every one of those collections at once, to versions selected by the release process rather than by you. A community release is a batch. It is tested as a batch upstream, which is real value, but it arrives as a batch on your controller too — and your estate is not what it was tested against.

The alternative costs one file:

# requirements.yml - the collections this estate actually uses
---
collections:
  - name: ansible.posix
    version: '2.1.0'
  - name: community.general
    version: '11.4.0'

Configuration changeinstall exactly what the repository declares— Writes into the collections path. Nothing on the managed fleet is touched - this is a controller-side install - but it does change what your next playbook run will execute.

$ ansible-galaxy collection install -r requirements.yml -p ./collections

Starting galaxy collection install process
Process install dependency map
Starting collection install process
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/ansible-posix-2.1.0.tar.gz to /home/ops/.ansible/tmp/ansible-local-402094/tmpvrh11ic6/ansible-posix-2.1.0-lmi55r02
Installing 'ansible.posix:2.1.0' to '/home/ops/estate/collections/ansible_collections/ansible/posix'
ansible.posix:2.1.0 was installed successfully
Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/community-general-11.4.0.tar.gz to /home/ops/.ansible/tmp/ansible-local-402094/tmpvrh11ic6/community-general-11.4.0-6ho3dm_g
Installing 'community.general:11.4.0' to '/home/ops/estate/collections/ansible_collections/community/general'
community.general:11.4.0 was installed successfully

And now the list is a manifest rather than an inventory of surprises:

Read-only / Safewhat this controller will actually run— Two collections, both at versions written down in a file under review. This output is the artefact you compare between two controllers when a playbook works on one and not the other.

$ ansible-galaxy collection list

# /home/ops/estate/collections/ansible_collections
Collection        Version
----------------- -------
ansible.posix     2.1.0
community.general 11.4.0

The blast radius of a collection upgrade

It is easy to read “a collection changed version” as a controller-local detail. It is not.

A collection contains modules. Modules run on managed nodes and change them. When community.general moves from 11.4.0 to 12.0.0, the behaviour of every task in your estate that calls a community.general module can change — a new default, a renamed option, a stricter validation, a different definition of what counts as changed. You have not edited a playbook. You have not touched the fleet. The next scheduled run does something different anyway.

The number of hosts affected is the number of hosts your playbooks reach, which for most estates is all of them. This is why the controller’s own dependency versions are treated in this course as a production change with a fleet-wide blast radius, and not as a tooling detail.

When the community package is the right answer

State the trade honestly, because “always use core” is not true.

Choose the community package when:

You are learning, or exploring an unfamiliar cloud or network vendor, and you want the batteries included rather than a lookup for every namespace.
Your organisation genuinely uses collections across many vendors and has no appetite to maintain a requirements.yml for each.
You are running one-off ad-hoc work from a workstation, and reproducibility on a second machine is not a requirement.

Choose ansible-core plus a pinned requirements.yml when:

The controller runs scheduled or CI-triggered change against production.
More than one person, or more than one machine, must produce identical results.
You need to answer “what changed since last Tuesday” with a diff rather than a shrug.

What happens if two controllers disagree?

A playbook succeeds on the engineer’s laptop and fails on the shared jump host, with an error about an unrecognised module option.

The diagnosis people reach for is the playbook, which is identical in Git and therefore innocent. The actual cause is almost always one of three lines of output:

ansible --version — different ansible-core on the two machines.
ansible-galaxy collection list — same core, different collection version, because one machine has the community batch and the other has pins.
ansible-config dump --only-changed — same code, different behaviour, because a config file on one machine changes a default.

Collect all three from both controllers before you read a single line of YAML. The comparison takes ninety seconds and resolves the majority of “works on my machine” reports outright.