Red Hat Ansible Automation Platform Life Cycle

Ansible Automation Platform Lifecycle

Overview

As part of a Red Hat Ansible Automation Platform (AAP) subscription, customers have access to supported versions of on-premise packages, as well as hosted Ansible services provided on Red Hat Hybrid Cloud Console. Red Hat provides a published product life cycle for Ansible Automation Platform so that customers and partners can properly plan, deploy, support, and maintain their on-premise automation clusters as well as operate the Red Hat Hybrid Cloud Console Ansible hosted services that they use as part of the Ansible Automation Platform subscription.

Customers are recommended to upgrade their Ansible Automation Platform environments to the most current supported version of the product in a timely fashion. Features and bug fixes target only the latest versions of the product, though some allowance may be given for high security risk items.

This lifecycle page outlines and details the versions of Ansible Automation Platform, its dependencies and what it can manage.

Life Cycle Dates

Ansible Automation Platform Life Cycle

Scope of Coverage

Support will be provided for use according to the published Scope of Coverage in Appendix 1 of the Red Hat Enterprise Agreement.

To encourage the rapid adoption of new technologies while keeping the high standard of stability inherent in Red Hat enterprise product, the product life cycle for Red Hat Ansible Automation Platform is divided into three phases of maintenance, described below.

Production Phases

Life Cycle Phase
Description Full Support Maintenance Support 1 Maintenance Support 2 Extended Life-cycle Support add-on
Qualified critical security fixes Yes Yes Yes Yes3
Bug fixes by severity 1 Critical and important severity issues Critical severity issues No No
Asynchronous Security Errata (RHSA) Yes Yes Yes No
Asynchronous Bug Fix Errata (RHBA)2 Yes Yes No No
Select Software Enhancements Yes No No No
The following table reflects the Maintanance Support Phases for Ansible Automation Platform and what type of security and bug fixes are included
Phases Security Fixes Bug Fixes Feature Fixes / Enhancements
Maintenance Support 1 Critical & Important Critical only No new features
Maintenance Support 2 Critical only None No new features

Table 1.0 - Description of Maintanance Support Phases

The following image shows the relationships between Ansible Core versions that are either default in the AAP release or available for use with AAP as per Table 1.1 AAP Release Lifecycle.

Current AAP and Ansible Core lifecycles

Table 1.1 - Current AAP and Ansible Core lifecycles

Ansible Automation Platform Installation Requirements

The following table depicts what the minimal install requirements are for Operating System and Database for Ansible Automation Platform

AAP version Default Ansible-core 1 Required OCP version for Operator RHEL-provided PostgreSQL version RPM Install OS Containerized OS
2.5 ansible-core 2.16 4.12-4.18 15 RHEL 8, RHEL 9 RHEL 9, RHEL 10
2.4 ansible-core 2.15 4.10-4.18 15 (v13 is supported until Nov'25) RHEL 8, RHEL 9 RHEL 9 (Tech Preview)

Table 1.2 - Operating System and Database Requirements

1. Ansible-core platform version is the version of Ansible Core required to install and operate AAP for its supported lifecycle as well as the default version of Core in the platform. The default version of core is supported for the entire lifecycle of the platform version it is attached to.

2. AAP is versioned as 2.5, 2.4 etc.. The components and services within are versioned with each release and move independently. For example, running the installer on an existing cluster can and will update only those components for that release of the installer, therefore moving each changed component on a version independently.

Scope of Support

Customer Provided Database

Commercially reasonable support is offered for customer provided databases. Issues may be requested to be shown on the shipped database for full support resolution.

The Ansible Automation Platform is supported for standard activities, and also has the common unsupported exclusions as follows;

Supported Activities Unsupported Activities
Installation Database Replication/Failover
Upgrades External applications integrated with the platform (i.e. third party loggers, load balancers, or authentication)
Backup/Restore Custom content/collection development and debugging
Standard configuration Custom configurations
Usage (API and UI) Custom API integrations
Operation Custom content

Customer Provided Kubernetes - Container Groups Only

Commercially reasonable support is offered for customers that want to leverage an Ansible Automation Platform control plane (running on a Red Hat supported platform) with an execution plane (container groups) running on Amazon EKS, Azure AKS or Google Cloud GKE.

Cloud kubernetes services must be running a version of the kubernetes API in a matching supported release of OpenShift, tested against the version of AAP being deployed. Supported OpenShift versions are available in the Ansible Platform Services and Components table above, and matching Kubernetes API versions to OpenShift versions is available at https://access.redhat.com/solutions/4870701.

Ansible Core Version Support by OS and Execution Environment Images

Ansible Core is made available in Ansible Automation Platform via the use of Execution Environment images. We supply execution environment images containing various versions of Ansible Core to meet your automation needs. Examples of this are;

  • EE with Ansible Core 2.16 - The default version in AAP 2.5. To be able to continue to support RHEL8 for its entire lifecycle. Supported for the entire life of AAP 2.5, this is stable.
  • EE with Ansible Core 2.18 - Latest Ansible Core to take advantage of newest features. Supported for the entire life of AAP 2.5, this is stable.
  • EE with Ansible Core 2.17 - An interim release for customers to move to latest at that time.
  • EE with Ansible Core 2.15 - The default version in AAP 2.4, Supported for the entire life of AAP 2.4, this is stable.

We aim to have stable supported long lifecycles for Ansible Core versions ending with “even” suffix and short term lifecycle as shown in Graphic 1.0 for “odd” suffixed Ansible Core versions.

Versioned and Version-less Execution Environment Images

All Execution Environment images are released to catalog.redhat.com as the official and supported source. Versioned EEs are locked to the Ansible Automation Platform version by way of their namespace whereby Version-less are not locked to any version and all can be found in the ansible-automation-platform namespace.

Versioned EE Version-less EE
  • Tagged with explicit AAP versions, e.g., registry.redhat.io/ansible-automation-platform-25/ee-supported-rhel8.
  • You explicitly reference a specific version of the image and the AAP version as the namespace.
  • Stable and predictable: the image contents remain fixed, making it ideal for production environments that require consistency.
  • Lifecycle is tied to that version: It follows the support and maintenance lifecycle defined for that specific AAP/Core version.
  • You only get updates if you pull a newer tagged version.
  • Best for controlled environments where exact behavior is needed across deployments.
  • Tagged without a specific AAP version, e.g., registry.redhat.io/ansible-automation-platform/ee-supported-rhel8.
  • Acts as a rolling tag: always points to the latest supported EE image that Red Hat has published for that stream.
  • Automatically updated: when new minor versions or fixes are released, the image behind this tag may change.
  • Lifecycle and support still match the Core version it aligns with — this image just tracks updates dynamically.
  • Best for development, testing, or cases where you want to stay current without manually updating tags.

The following table details the supported control and managed node coverage, please refer to AAP Lifecycle table 1.1 for supported dates per Ansible Core.

Ansible Core Version Execution Environment (EE) Images EE Base OS Control Node Python Versions Managed Node Python Versions (2)Managed Node PowerShell Versions (1)Supported Managed OS (RHEL)
2.18 ee-minimal-rhel8, ee-minimal-rhel9, ee-supported-rhel8, ee-supported-rhel9 RHEL 8, 9,10 3.11 – 3.13 3.8 – 3.13 5.1 RHEL 9 – 10
2.17 ee-minimal-rhel8, ee-minimal-rhel9, ee-supported-rhel8, ee-supported-rhel9 RHEL 8, 9,10 3.10 – 3.12 3.7 – 3.12 5.1 RHEL 9 – 10
2.16 ee-minimal-rhel8, ee-minimal-rhel9, ee-supported-rhel8, ee-supported-rhel9 RHEL 8, 9,10 3.10 – 3.12 2.7, 3.6 – 3.12 4 – 5.1 RHEL 7 – 10
2.15 ee-minimal-rhel8, ee-minimal-rhel9, ee-supported-rhel8, ee-supported-rhel9 RHEL 8, 9 3.9 – 3.11 2.7, 3.5 – 3.11 4 – 5.1 RHEL 7 – 9

Table 1.3 - Control and Managed Node Coverage

1. In all RHEL cases, depending on what version is being managed, you may need to set ansible_python_interpreter to the correct python path so that your Ansible and Python's dependencies align for the automation use cases you wish to perform.

2. Windows Server versions 2016, 2019, 2022 and 2025 (requires Ansible core 2.18+) are supported. Windows Server with WDAC enabled is currently not supported. OpenSSH is supported in Windows Server 2022+ and Ansible core 2.18+. Additionally, Desktop/laptop devices and devices running desktop variants of supported operating systems (e.g. Windows 10/11) are not covered by commercially reasonable support unless a support exception has been granted with agreed conditions.

Other Operating System Supported EE or Ansible Control Node Supported Target
(3)IBM Operating Systems Ansible Core version 2.15 or later OpenSSH enabled IBM Open Enterprise SDK for Python 3.11 or later
IBM z (z/OS)
IBM i
IBM AIX
Arista EOS Cisco IOS, IOS-XE, IOS-XR, NX-OS Juniper Junos OS VyOS Refer to Ansible Collection for requirements and/or vendor documentation.
Ubuntu (x86_64 only) As Per AAP Lifecycle
Additional operating systems such as unlisted RHEL variants available for Commercially-reasonable support only (i.e. issue can be replicated on a supported platform)

Table 1.4 - Other Operating System Support

3. IBM-managed nodes are tested and supported by IBM and require a valid support contract with IBM. Please refer to the following for more details: Ansible Support for IBM operating systems and content

Ansible Collections

In Red Hat Ansible Automation Platform (AAP), most automation is delivered through Ansible Collections. This means that when you automate a target system (or "end node"), the tasks are executed using collections that are purpose-built for that specific platform or technology.

As a result, the lifecycle and support of automation for a given end node are governed by the individual Ansible Collection used to manage it.

Examples:

  • Red Hat OpenShift automation is managed through the OpenShift Collection and follows its lifecycle.
  • Microsoft Azure automation is managed through the Azure Collection and follows its lifecycle.
  • Cisco ACI automation is supported via the Cisco ACI Collection, which defines its own lifecycle.
  • NetApp automation is handled through the NetApp Collection, which has an independent lifecycle.

It’s important to note that this model does not impact the support or lifecycle of the Ansible Automation Platform itself. The platform remains fully supported by Red Hat, independently of the individual collections in use. Please refer to individual collection lifecycles for further details.