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.

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

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 1.x Series (Ansible Tower-based)

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 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. 🙂