unit 1 · Orientation
ansible-core vs the community package
Two packages, one engine — and two version numbers
tl;dr
- ansible-core = the engine plus the ansible.builtin collection only. Minimal by design.
- The ansible community package = core plus a big curated bundle of collections — batteries included.
- Two version tracks: each community major pins one core series, and only the latest major is maintained.
why it matters Install the wrong package and half the modules in your team’s playbooks don’t exist; misread the two version tracks and you’ll debug against docs for a release you aren’t running.
Type pip install ansible and you get one thing. Type
pip install ansible-core and you get something much smaller. Same engine,
same commands — the difference is what ships alongside it, and this split is
the first fork in the road every newcomer has to understand.
ansible-core is the engine: the ansible and ansible-playbook commands,
the plugin machinery, and exactly one collection of modules —
ansible.builtin. It’s deliberately minimal, built for people who want to
install only the collections they actually need.
ansible — the community package — is ansible-core plus a large curated bundle: more than 85+ collections containing thousands of modules and plugins. It restores the batteries-included experience Ansible had before the big collections split, when everything shipped as one monolith.
What it means day to day
# Batteries included: engine + the curated bundle, pre-installed
pip install ansible
# Just the engine + ansible.builtin — you add collections yourself
pip install ansible-core
ansible-galaxy collection install community.general # pinning: lesson 26
ansible --version # verify either installThe bundle exists so things work out of the box; bare core trades that convenience for a footprint you control and populate yourself. One wrinkle to file away for later: in AWX and Ansible Automation Platform neither model applies directly, because collections are baked into an execution-environment container image instead — lesson 40 covers that.
Two packages means two version numbers
This is where colleagues, docs and error messages will genuinely confuse you. Each package has its own version track. Right now the community package sits at major 14 , riding on ansible-core
2.21 — and that pairing is the rule, not a coincidence: each community major pins exactly one core series, published in the official release announcements.
The cadence is quick. The community package cuts roughly two majors a year with a new minor every four weeks, and only the latest major is maintained — there’s no long-term-support branch to hide on. ansible-core moves slower and maintains three majors at a time under graduated support windows, so every release you run has a published end-of-life date. Check those dates on endoflife.date before an upgrade conversation, the same way you’d check an Azure API version’s retirement date. One more moving part: each core series also sets a floor for the control node’s Python — core
2.21 tracks Python 3.12–3.14 .
So: one engine, two packages, two version tracks, short support windows. The last question is what’s actually inside that curated bundle — collections, each with a namespace that changes how every module name is written. That’s the next lesson, and it’s the reason most old tutorials will lie to you.
at work, this sounds like
- “Are we on bare core or the full package?”
- Which pip package the control node has — ansible-core (install collections yourself) or ansible (bundle pre-installed).
- “The EE already has that collection baked in.”
- In AWX/AAP, collections ship inside an execution-environment container image, not on the control node.
self-check — recall, not a test
1 Same engine either way — so what does pip install ansible give you that pip install ansible-core doesn’t?
2 A colleague quotes one version number, the docs quote a completely different one. Contradiction?
3 How often does the community package move, and how many of its majors stay maintained?