Managing IT infrastructure automation? Chances are you’re using Ansible. But do you know exactly when your current Ansible version will reach end of support?
Running unsupported versions in production environments exposes you to security vulnerabilities and leaves you without help when issues arise. Let’s dive into Ansible’s version-specific support policies and precise EOS/EOL schedules.
1. What is Ansible? A Powerful Infrastructure Automation Tool
Ansible is an open-source IT automation tool provided by Red Hat. As one of the most widely used solutions for implementing Infrastructure as Code (IaC), it automates complex configuration management, application deployment, and provisioning tasks.
Ansible’s biggest advantage is its agentless architecture. Using standard protocols like SSH and WinRM, it requires no additional software installation on managed servers. With YAML-based playbooks, it’s easy to learn and highly readable.
The Ansible ecosystem currently consists of three main components:
- Ansible Community Package: Community-driven open-source package with 85+ collections and thousands of modules
- ansible-core: The core engine providing the base language, runtime, and built-in plugins
- Red Hat Ansible Automation Platform (AAP): Commercial product for enterprise environments
Each has different versioning schemes and support policies, which can be confusing. Let’s break them down one by one.
2. Understanding Ansible’s Versioning Scheme
To understand Ansible’s support policy, you need to grasp the difference between two main projects.
Ansible Community Package adopted a new semantic versioning scheme starting from version 2.10. After 2.10, versions follow the pattern 3.0.0, 4.0.0, and so on. It has approximately 2 major releases per year, with minor versions released every 4 weeks.
ansible-core continues the traditional Ansible versioning scheme: 2.11, 2.12, 2.13, etc. Major releases occur in May and November each year, with minor patches released every 4 weeks.
The critical difference: Ansible Community Package maintains only the latest major version, while ansible-core simultaneously supports the 3 most recent major releases. This difference is crucial for version selection.
3. Complete Ansible Community Package Version Support Schedule
The Ansible Community Package transitioned to a new package structure starting with version 2.10. The table below shows the support status for all versions.
Ansible Version | Release Date | Latest Minor | ansible-core Version | Support Status | Control Node Python |
---|---|---|---|---|---|
12.x | Expected July 2025 | In Development | 2.19 | In Development | Python 3.11 – 3.13 |
11.x | November 19, 2024 | 11.7.0 | 2.18 | Currently Supported | Python 3.11 – 3.13 |
10.x | May 2024 | 10.7.0 | 2.17 | EOL after final release | Python 3.10 – 3.12 |
9.x | November 2023 | 9.13.0 | 2.16 | EOL after final release | Python 3.10 – 3.12 |
8.x | May 2023 | 8.7.0 | 2.15 | EOL | Python 3.9 – 3.11 |
7.x | November 2022 | 7.7.0 | 2.14 | EOL | Python 3.9 – 3.11 |
6.x | May 2022 | 6.7.0 | 2.13 | EOL | Python 3.8 – 3.10 |
5.x | November 2021 | 5.10.0 | 2.12 | EOL | Python 3.8 – 3.10 |
4.x | May 2021 | 4.10.0 | 2.11 | EOL | Python 2.7 / 3.5 – 3.9 |
3.x | November 2020 | 3.4.0 | 2.10 | EOL | Python 2.7 / 3.5 – 3.9 |
2.10.x | August 2020 | 2.10.7 | 2.10 | EOL | Python 2.7 / 3.5 – 3.9 |
2.9.x | October 2019 | 2.9.27 | 2.9 | EOL | Python 2.7 / 3.5 – 3.8 |
As of October 2025, only Ansible 11 is officially maintained. Ansible 10 and 9 will reach EOL after their final minor releases. According to the official documentation, each EOL version may issue one final maintenance release at or shortly after the first release of the next version, becoming EOL at the release date.
If you’re running Ansible 8 or earlier, you’re no longer receiving security patches. Upgrade as soon as possible.
4. Complete ansible-core Version EOS/EOL Detailed Schedule
ansible-core operates on a graduated 3-phase maintenance structure. It simultaneously supports the 3 most recent major releases, with different support levels for each phase.
Support Phase Descriptions
- GA (General Availability): Security and general bug fixes
- Critical: Security and critical bug fixes only
- Security: Security fixes only
- EOL: End of Life
ansible-core Version | Release Date | Latest Version | GA Ends | Critical Ends | Security Ends | EOL Date | Control Node Python |
---|---|---|---|---|---|---|---|
2.20 | Expected November 2025 | In Development (Beta) | TBD | TBD | TBD | Expected May 2027 | Python 3.12 – 3.14 |
2.19 | July 21, 2025 | 2.19.3 | November 4, 2025 | May 19, 2026 | November 3, 2026 | November 2026 | Python 3.11 – 3.13 |
2.18 | May 20, 2024 | 2.18.10 | November 4, 2024 | May 19, 2025 | November 2025 | November 2025 | Python 3.11 – 3.13 |
2.17 | November 6, 2023 | 2.17.14 | May 20, 2024 | November 4, 2024 | May 2025 | May 2025 | Python 3.10 – 3.12 |
2.16 | November 6, 2023 | 2.16.14 | May 20, 2024 | November 2024 | Security Phase | July 2025 | Python 3.10 – 3.12 |
2.15 | May 22, 2023 | 2.15.13 | November 6, 2023 | May 20, 2024 | November 2024 | November 2024 EOL | Python 3.9 – 3.11 |
2.14 | November 7, 2022 | 2.14.18 | May 22, 2023 | November 6, 2023 | May 20, 2024 | May 2024 EOL | Python 3.9 – 3.11 |
2.13 | May 23, 2022 | 2.13.13 | November 7, 2022 | May 22, 2023 | November 6, 2023 | November 2023 EOL | Python 3.8 – 3.10 |
2.12 | November 8, 2021 | 2.12.10 | May 23, 2022 | November 7, 2022 | May 22, 2023 | May 2023 EOL | Python 3.8 – 3.10 |
2.11 | April 26, 2021 | 2.11.12 | November 8, 2021 | May 23, 2022 | November 7, 2022 | November 2022 EOL | Python 2.7 / 3.5 – 3.9 |
2.10 | August 13, 2020 | 2.10.17 | April 26, 2021 | November 8, 2021 | May 23, 2022 | May 2022 EOL | Python 2.7 / 3.5 – 3.9 |
2.9 | October 31, 2019 | 2.9.27 | August 13, 2020 | April 26, 2021 | May 23, 2022 | May 2022 EOL | Python 2.7 / 3.5 – 3.8 |
As of October 2025, ansible-core 2.19, 2.18, and 2.17 are officially supported. ansible-core 2.16 is in the Security phase (security patches only) and will reach EOL in July 2025.
Note the Python version requirements. Starting with ansible-core 2.18, Python 3.11+ is mandatory for control nodes, and 2.20 will require Python 3.12+. Plan your Python upgrades accordingly.
5. Complete Red Hat Ansible Automation Platform (AAP) Version Lifecycle
Red Hat Ansible Automation Platform for enterprise environments follows a separate lifecycle policy, offering longer support periods than community versions.
AAP Support Phases
- Full Support: Security patches, bug fixes, and feature enhancements
- Maintenance Support 1: Security patches and critical bug fixes only
- Maintenance Support 2: Security patches only (approximately 6 months)
- EOL: End of Life
AAP 2.x Series
AAP Version | GA Release | Default ansible-core | Full Support Ends | Maintenance 1 Ends | Maintenance 2 Ends | Current Status |
---|---|---|---|---|---|---|
2.6 | Expected 2025 | 2.18 | TBD | TBD | TBD | In Development |
2.5 | 2024 | 2.16 / 2.17 / 2.18 | Active | TBD | TBD | Currently Supported |
2.4 | 2023 | 2.15 / 2.16 | November 2024 | May 2025 | November 2025 | Maintenance |
2.3 | 2023 | 2.14 / 2.15 | May 2024 | November 2024 | May 2025 | Maintenance |
2.2 | 2022 | 2.13 / 2.14 | November 2023 | May 2024 | November 2024 | EOL |
2.1 | December 2, 2021 | 2.12 | June 2022 | December 2022 | June 2023 | EOL |
2.0 | July 15, 2021 | 2.11 | December 2021 | July 2022 | January 2023 | EOL |
AAP 1.x Series (Ansible Tower-based)
AAP Version | Ansible Tower Version | Ansible Engine | GA Release | EOL Date | Notes |
---|---|---|---|---|---|
1.2 | Tower 3.8.x | Engine 2.9 | November 18, 2020 | September 29, 2023 | Extended Support available |
1.1 | Tower 3.7.x | Engine 2.9 | May 18, 2020 | November 18, 2021 | – |
1.0 | Tower 3.6.x | Engine 2.9 | November 14, 2019 | May 14, 2021 | – |
Each AAP version receives approximately 2 years of support. AAP 2.5 is the current recommended version, while AAP 2.4 and 2.3 are in Maintenance Support phases. AAP 1.2 reached EOL in September 2023, so immediate migration to AAP 2.x is required for any remaining 1.x installations.
Starting with AAP 2.5, you can select from multiple ansible-core versions (2.16, 2.17, 2.18) via Execution Environment images, significantly improving flexibility.
6. Ansible Tower Version EOL Schedule
Ansible Tower was renamed “Automation Controller” starting with AAP 2.0, and Tower is no longer offered as a standalone product. Here’s the EOL information for major Tower versions for reference.
Tower Version | Final Release | Ansible Version | Included in AAP | EOL Date | Status |
---|---|---|---|---|---|
3.8.x | 3.8.6 | 2.9 | AAP 1.2 | September 29, 2023 | EOL |
3.7.x | 3.7.5 | 2.9 | AAP 1.1 | November 18, 2021 | EOL |
3.6.x | 3.6.7 | 2.9 | AAP 1.0 | May 14, 2021 | EOL |
3.5.x | 3.5.6 | 2.8 | – | Before 2020 | EOL |
3.4.x | 3.4.5 | 2.7 | – | Before 2020 | EOL |
3.3 and earlier | – | – | – | Before 2019 | EOL |
Tower 3.8 was supported as part of AAP 1.2 until September 2023, marking the last Tower version. Current Tower users must transition to AAP 2.x’s Automation Controller.
7. Key Support Policy Points
Here’s a summary of Ansible’s support policies at a glance.
Ansible Community Package Policy
- Maintains only the latest major version
- Approximately 2 major releases per year (typically May, November)
- Minor versions released every 4 weeks
- Previous versions reach EOL immediately or after final minor release when new major version is released
ansible-core Policy
- Simultaneous support for the 3 most recent major releases
- 3-phase maintenance structure (GA → Critical → Security)
- Each phase lasts approximately 6 months
- Total support period: approximately 18 months from release
AAP Policy
- Full Support + Maintenance Support 1 + Maintenance Support 2 = approximately 2 years
- Multiple ansible-core version selection available (Execution Environments)
- Enterprise-grade support with extended lifecycle
Important Notes
- EOL versions no longer receive security vulnerability (CVE) patches
- Python version requirements must be verified
- Windows PowerShell support follows separate policies
- Python 3.11+ required starting with ansible-core 2.18
8. Version Upgrade Checklist
When upgrading Ansible, verify these items:
Pre-Upgrade Checks
- Identify current Ansible and ansible-core versions
- Verify target version Python requirements
- Check collection compatibility
- Review porting guides
Test Environment Validation
- Test critical playbooks
- Verify custom module and plugin functionality
- Check for performance and behavioral changes
Leverage Official Porting Guides
Ansible’s official documentation provides detailed porting guides for each version. These cover major changes, deprecated features, and new functionality between versions. Always review before upgrading.
When upgrading to ansible-core 2.18, Python 3.11+ is mandatory, so plan OS-level Python upgrades accordingly.
9. Real-Time Support Status Resources
Here are useful resources for checking Ansible support status in real-time.
Official Documentation
- Ansible Releases and Maintenance: Most accurate and current information
- Ansible Roadmap: Future release plans
- ansible-core Roadmap: ansible-core development roadmap
Third-Party Tracking Sites
- endoflife.date/ansible: Ansible Community Package EOL tracking
- endoflife.date/ansible-core: ansible-core EOL tracking
- Red Hat Customer Portal: AAP lifecycle
endoflife.date provides visual tracking and iCalendar subscriptions for calendar app integration.
Version Check Commands
# Check Ansible Community Package version
ansible-community --version
# Check ansible-core version
ansible --version
After identifying your current version, use the above resources to verify support status.
While Ansible’s version support policy appears complex, the core concept is simple: Ansible Community Package maintains only the latest major version, while ansible-core supports the 3 most recent releases.
If you’re running Ansible in production, remember:
- Ansible 11 (ansible-core 2.18) is the current recommended community version
- AAP 2.5 is the current recommended enterprise version
- ansible-core 2.16 and earlier will reach EOL by July 2025
- All AAP 1.x versions are EOL and require immediate migration
- Prepare to upgrade to Python 3.11+
- Regularly check official documentation and roadmaps
Continuing to use EOL versions exposes you to security risks and prevents access to new features. While upgrades may seem burdensome, they’re essential for long-term stability and security. 🙂