What is the differnce in the packaging and distribution of
Ansible, in RHEL9 vs RHEL 10
The transition from RHEL 9 to RHEL 10 marks a significant shift in how Red Hat approaches Ansible packaging, moving away from a "convenience bundle" toward a more streamlined, "core-first" philosophy.
In RHEL 9, users were accustomed to a more traditional experience where a simple dnf install ansible provided a large, bundled package containing both the engine and a wide array of commonly used collections and plugins. This was great for immediate convenience but resulted in a heavier footprint. RHEL 10 changes this by only providing ansiblecore. This means the base OS now ships with a lightweight, high performance engine, but it does not include the extra collections by default.
This shift has direct implications for your automation scripts and workflows. While RHEL 9 allowed you to rely on builtin modules, RHEL 10 requires an explicit installation of the specific collections you need, typically via Ansible Galaxy or the Automation Hub. Additionally, the underlying environment has been modernized.
RHEL 10 moves to Python 3.12 and a newer ecosystem, ensuring better performance and security compared to the older Python versions found in RHEL 9. Essentially, the move to RHEL 10 encourages a more modular, "install only what you use" approach to automation.
https://www.geeksforgeeks.org/devops/ansible-vs-ansible-core/
https://www.redhat.com/en/blog/updates-using-ansible-core-in-rhel
https://access.redhat.com/support/policy/updates/ansible-automation-platform
Chetan, a significant shift in how things are approached is something
that I should know to expect - with Ansible packaging, and everything
else associated with the OS.
In my opinion, by RHEL 10 only providing Ansible Core, that is an
appropriate route to take. If my network is comprised of only 4
systems that need to be managed, Ansible Automation Platform
(AAP) is overkill.
That move to Python 3.12 and a newer ecosystem won't add
appreciably to my learning journey - at least I don't think it will.
Thanks for the nice lesson, along with the resources to consider in
updating my knowledgebase!
@Trevor
In RHEL 9, Ansible is distributed primarily via Application Streams, where ansible-core is included in the base OS lifecycle, and additional collections are delivered separately through Automation Hub / Ansible Galaxy. This allows Red Hat to provide a stable, supported core while keeping content flexible and updatable.
With RHEL 10, Red Hat has taken this further by decoupling Ansible even more from the OS, focusing RHEL on the minimal supported runtime ansible-core and positioning Ansible Automation Platform as the recommended way to consume fully supported automation content. This improves lifecycle independence, security patching, and consistency across hybrid environments.
Overall, the shift reflects Red Hat’s direction toward alighter OS + faster-moving automation ecosystem, while maintaining enterprise support guarantees.
Thanks for raising this — it’s a great topic for anyone planning long-term automation on RHEL.
Thanks Priyanshu20041 for your response.
Your comment, "...on the minimal supported runtime
ansible-core...", prompts a question. Who is providing
the support for ansible-core, the community or Red Hat?
Thanks in advance!
@Trevor, For RHEL-packaged ansible-core , support is provided by Red Hat—including updates, fixes, and guidance. The upstream community maintains Ansible itself, but in RHEL environments, enterprise support comes from Red Hat.
Makes sense.
Thanks Priyanshu20041!
You’re welcome, Trevor! Happy to help.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.