ansible-core 2.19 End of Life Is November 30, 2026: What Changes

By Scott Bissett  ·  Published: October 7, 2026  ·  Reference guide  ·  Dates read at the ansible-core Releases and maintenance page and the ansible-core 2.19, 2.21 and 2.22 roadmaps (docs.ansible.com) on October 7, 2026.

ansible-core 2.19 reaches end of life on November 30, 2026 in our data. The ansible-core project prints that date in the support matrix of its Releases and maintenance page as "Nov 2026", a month without a day, the way it prints every end of life since 2.15; we carry the last day of the printed month. What actually ends the release is a rule rather than a calendar entry: ansible-core maintains three releases at a time, so 2.19 stops receiving fixes when ansible-core 2.22 ships, and the 2.22 roadmap schedules that release for November 2026 with the roadmap's standing note that dates are subject to change. 2.19 was released on July 21, 2025 and has been in the project's security-fixes-only phase since 2.21 shipped in May 2026. Its EOL Risk Score is 25 (live value, recomputed each build).

Key Dates at a Glance

• ansible-core 2.19 released: July 21, 2025 (security and general bug fixes)
• ansible-core 2.20 released: November 3, 2025 (2.19 moves to security and critical bug fixes)
• ansible-core 2.21 released: May 2026 (2.19 moves to security fixes only)
• ansible-core 2.19 end of life: November 30, 2026 (printed as Nov 2026; the month 2.22 is scheduled to ship)
• Ansible 12 (the community package on ansible-core 2.19) end of life: December 9, 2025
• ansible-core 2.18 end of life: May 31, 2026 (printed as May 2026)

What ends on the date, in the project's words

The Releases and maintenance page states the rule in one sentence: "ansible-core maintenance continues for 3 releases. Thus the latest release receives security and general bug fixes when it is first released, security and critical bug fixes when the next ansible-core version is released, and only security fixes once the follow on to that version is released." The support matrix on the same page turns that rule into three dates for each release, labelled GA, Critical and Security, with the note that the dates "indicate the start date of the maintenance cycle". For 2.19 the three are GA on July 21, 2025, Critical on November 3, 2025 (the day 2.20 shipped) and Security in May 2026 (the month 2.21 shipped). End of life is the fourth step, the release after that, and the matrix prints it as "Nov 2026".

So the end of life changes less than the label suggests. 2.19 has not received general bug fixes since November 3, 2025, and has received nothing but security fixes since May 2026. What stops on the end-of-life date is the security stream: the page says "we generally do not provide fixes for unmaintained releases of ansible-core, however, there can sometimes be exceptions for critical issues", and warns that unmaintained versions "can contain unfixed security vulnerabilities (CVEs)". Minor releases ship on a four-week schedule for each maintained version, so the last scheduled 2.19.x patch is whichever one lands before 2.22 is released; our data carries the most recent one as a live value on the 2.19 status page.

Two details of how the project counts are worth knowing. The project calls 2.19, 2.20 and 2.21 major releases, denoted by the Y in X.Y.Z, and ships one "approximately every 6 months, in May and November". And because the end of life is tied to a release rather than a day, the matrix prints a month for it until the release has happened; the rows for 2.14 and earlier carry exact days because those releases are history.

Every maintained and recently ended ansible-core release

These rows are read from the ansible-core support matrix on October 7, 2026, with the project's Python ranges. Release days come from the matrix and the per-release roadmaps; end-of-life months are the matrix's, carried as the last day of the month. Each version links to its live status page.

Only the three newest rows are maintained, which is the whole of the project's policy in one glance: when 2.22 ships, 2.19 drops off the bottom and 2.22 joins at the top.

ansible-core and the Ansible community package: two products, two clocks

The Releases and maintenance page opens by separating the two projects, and the separation matters for anyone reading an end-of-life date. ansible-core is "the language, runtime, and builtin plugins", developed in the ansible/ansible repository, versioned 2.19, 2.20, 2.21 and maintained three releases at a time. The Ansible community package, what pip install ansible installs, bundles one ansible-core release with "more than 85 Collections containing thousands of modules and plugins", follows semantic versioning (12, 13, 14) and, in the page's words, "guarantees maintenance for only one major community package release at a time". The page adds that each end-of-life package version "may issue one final maintenance release at or shortly after the first release of the next version", and that when it does, "the final maintenance release is EOL at the date it releases".

Put the two clocks side by side for 2.19 and the gap is nearly a year:

Ansible 12, the only package built on ansible-core 2.19, reached end of life on December 9, 2025, the day its final maintenance release shipped. Since then the Ansible page has listed 12.x as "Unmaintained (end of life)" while ansible-core 2.19 underneath it was still receiving critical and security fixes. If you installed ansible rather than ansible-core, the date that applies to you has already passed, and the collections in your installation have been frozen since. The ansible-core date on this page is the one that applies if you installed ansible-core on its own and manage collections yourself. Every package version is on our Ansible community package lifecycle page.

Python requirements: 2.19 against what comes next

The project's Python rule is also on the Releases and maintenance page. From 2.12 on, "each release includes control node support for the three most recently released Python versions". From 2.16 on, each release supports managed (target) nodes on "the 6 most recently released Python versions", with a seventh every sixth release (2.16, 2.22 and so on). Because ansible-core ships twice a year and Python once, every second ansible-core release drops a Python version at each end.

• ansible-core 2.19: control node Python 3.11 to 3.13; managed nodes Python 3.8 to 3.13; Windows targets PowerShell 5.1.
• ansible-core 2.20 and 2.21: control node Python 3.12 to 3.14; managed nodes Python 3.9 to 3.14. 2.21 adds PowerShell 7 alongside 5.1 on Windows targets.
• ansible-core 2.22 (planned): the roadmap lists "Add Python 3.15 support" and "Drop Python 3.12 for controller". "Drop Python 3.9 on target" is listed as delayed to 2.23.

The practical consequences of leaving 2.19: a control node running Python 3.11 must move to 3.12 or newer before 2.20 or 2.21 will install, and if you go straight to 2.22 when it ships, to 3.13 or newer. Any managed node still on Python 3.8 (the system Python on several enterprise distributions still in service) falls out of support on 2.20 and 2.21; Python 3.9 targets survive through 2.22 under the current roadmap. Check the control node first, because that is the install that fails outright; an unsupported target Python produces errors at task time instead.

Upgrade path

1. Find out which product you are actually running. ansible --version prints the ansible-core version on its first line. pip show ansible tells you whether the community package is installed on top; if it is, your package version (12.x for anything on ansible-core 2.19) has been end of life since December 9, 2025 and the collections inside it are frozen.
2. Choose the target release by the Python you can run. 2.21 is the newest maintained release and will receive security and general bug fixes until 2.22 ships, then critical and security fixes until 2.23, then security fixes until 2.24: it has the longest runway today, with end of life printed as November 30, 2027. 2.20 ends six months earlier, on May 31, 2027, and offers nothing 2.21 does not. Both need Python 3.12 to 3.14 on the control node.
3. Read the porting guides in order. The project publishes an Ansible Core Porting Guide per release. The 2.20 and 2.21 guides cover the changes between 2.19 and your target. If you are still on 2.18 or earlier, the project's documentation carries a banner on the 2.19 release: it "made significant templating changes that might require you to update playbooks and roles", and asks users to validate content before upgrading to 2.19 or Ansible 12. That validation has to happen on the way through 2.19, not after.
4. Mind the deprecation window. ansible-core removes deprecated features "across 4 feature releases": something deprecated in 2.19 is normally removed in 2.22. Deprecation warnings you have been ignoring on 2.19 become failures on 2.22, so clear them on 2.21 while the warnings still print.
5. Collections move separately. ansible-core carries only the builtin plugins. Each collection declares the ansible-core versions it supports in its own meta/runtime.yml (the requires_ansible field), so run ansible-galaxy collection list and check that every collection you depend on has a release that supports your target ansible-core. Ansible 14 is the current package built on 2.21, and its contents are the simplest known-good set.
6. Treat the control node as part of the fleet. The ansible-core control node is a privileged machine with credentials to everything it manages, and its Python runtime has its own end of life. Our Python lifecycle page carries the dates for 3.11 through 3.14, and our EOL Checker and API cover the operating systems the managed nodes run.

Red Hat Ansible Automation Platform is a different schedule

Red Hat Ansible Automation Platform ships an ansible-core build inside each platform release, but its support dates are set by Red Hat and published on the platform life cycle page, not by the community matrix on this page; the Releases and maintenance page itself opens with a pointer to that life cycle for subscribers. The difference is visible in our own data: Red Hat Ansible Automation Platform 2.6 ships ansible-core 2.16, a release the community project ended in 2025, and Red Hat maintains it for the life of the platform release. A platform subscriber on ansible-core 2.19 inside the platform follows the platform dates, which are on our Red Hat Ansible Automation Platform lifecycle page and in our Ansible Automation Platform 2.5 guide. Nothing on this page shortens or extends a platform subscription.

Frequently Asked Questions

Related

• ansible-core — the live status page for every release, with its EOL Risk Score
• Ansible community package — the package versions (12, 13, 14) and the ansible-core each is built on
• Red Hat Ansible Automation Platform — the separately published platform lifecycle
• Python — the control node and managed node runtimes behind every row above
• ansible-core Releases and maintenance — the project page these dates were read from
• How we verify our dates — the rules every number on this site is held to