Technology Preview of Ansible Core 2.20 in Ansible Automation Platform

Updated 23 Feb 2026

As the Product Manager of Ansible Core, it is my pleasure to share an early look at the upcoming release of Ansible Core 2.20, available as a *Technology Preview in Red Hat Ansible Automation Platform. This release delivers significant Python modernization, powerful new playbook capabilities, expanded plugin extensibility, and the completion of deprecation removals that have been building across prior releases. Let's explore what's new and why it matters to you.

*Technology Preview features provide early access to upcoming product innovation

What is Ansible Core?

Ansible Core is the foundational layer to Ansible Automation Platform that performs the automation derived from Ansible Playbooks. Ansible Core runs playbooks that are orchestrated as jobs in the highly scalable enterprise platform that is Ansible Automation Platform. Ansible Core is also responsible for the Domain Specific Language that makes Ansible Playbooks human readable.

Technology Preview of Ansible Core

The importance of Ansible Core is paramount to the operational success of your automation use case, for this reason we take the release and upgrading of Ansible Core very seriously as we do not wish to impose adverse effects on your automation use cases. For these reasons, we are leveraging tried and tested Red Hat release procedures bringing Red Hat Ansible Automation Platform customers an early preview of Ansible Core 2.20. Let's talk about the benefits:

You get early access to test and accredit the release prior to it becoming default in a future AAP release.
You can raise issues regarding the use of the new release in your environment for your automation use cases.
Allow for early skills development in new ways of doing things in the release.
Strategically plan for impacts to your automation use case and provide feedback.
Enable faster adoption of the future release of AAP that ships by default the preview release of Ansible Core.

These benefits to you allow us at Red Hat to develop fast and release faster by engaging directly with our customer base in a safe Technology Preview encapsulation. Customers should join the technology preview of Ansible Core 2.20 to gain early access for testing before a future 2.2x Core version becomes the default in a future AAP release. This allows time to identify and raise issues with Red Hat, develop skills with the new release, plan for impacts on automation use cases, and enable faster adoption of future AAP releases. Ultimately, it's about ensuring a smooth transition and proactively addressing potential problems.

Support Guidance for Technology Preview

We release it as Technology Preview so that customers clearly understand that the software they are testing is exactly that, it is a test scenario and should be treated as such. Technology Preview should NOT be installed in production. If you encounter an issue with Ansible Core 2.20 you should raise a standard support ticket stating the Ansible Core version as 2.20 Technology Preview. We will look to address the issue in accordance with the technology preview support guidance https://access.redhat.com/support/offerings/techpreview

We would really appreciate any and all issues raised to support our quality goals and high standards for a generally available release.

What you can expect from Ansible Core 2.20

Everything from Ansible Core 2.19 Technology Preview

Ansible Core 2.20 builds upon the changes introduced in Ansible Core 2.19. As such, all improvements and updates from the 2.19 release are also included in this version. For a detailed overview of the 2.19 changes, please refer to the published article at https://access.redhat.com/articles/7128367 and the Content from docs.ansible.com is not included.Ansible-core 2.20 Porting Guide.

Python Version Modernization

Ansible Core 2.20 advances Python version support with significant changes to both the control node and target node requirements.

Control Node (minimum Python 3.12): Python 3.12 is now the minimum supported version for the Ansible controller, with Python 3.14 added as a supported version. Python 3.11 support has been dropped.

Target/Managed Nodes (minimum Python 3.9): Python 3.9 is now the minimum supported version for managed/target nodes. Python 3.8 support has been dropped, and Python 3.14 has been added.

RHEL Compatibility Matrix:

The following table shows Python availability across Red Hat Enterprise Linux releases and compatibility with Ansible Core 2.20 requirements:

RHEL Version	Default Python	Additional Python Available	Control Node (min 3.12)	Target Node (min 3.9)
RHEL 8	3.6	3.9 (module streams); 3.11, 3.12 (AppStream)	✅ Python 3.12 via dnf install python3.12	✅ Python 3.9 via dnf module install python39
RHEL 9	3.9	3.11 (since 9.2); 3.12 (since 9.4)	✅ Python 3.12 via dnf install python3.12 (RHEL 9.4+)	✅ Default Python 3.9 meets requirement
RHEL 10	3.12	Additional versions via AppStream	✅ Default Python 3.12 meets requirement	✅ Default Python 3.12 meets requirement

Key Considerations:

RHEL 10 is fully compatible out of the box for both control and target node roles, with Python 3.12 as the system default.
RHEL 9.4+ meets the control node requirement when Python 3.12 is installed from AppStream (dnf install python3.12). The system default Python 3.9 is sufficient for the target node role. Customers running RHEL 9.0 through 9.3 will need to upgrade to at least RHEL 9.4 to obtain Python 3.12 for the control node.
RHEL 8 can serve as both a control node and target node, but requires installing non-default Python versions from AppStream. Python 3.12 is available as the python3.12 package for the control node role, and Python 3.9 is available as a module stream for the target node role. Note that RHEL 8 is in the Maintenance Support phase; customers are encouraged to plan migration to RHEL 9 or RHEL 10.
Execution Environments — Because the Ansible controller runs inside Execution Environments in Ansible Automation Platform, the Python version requirement for the control node is met by the EE image itself. The Technology Preview EE images for Ansible Core 2.20 are built on RHEL 9 and RHEL 8 with Python 3.12 included. Customers should focus their Python version audit on their managed/target hosts.

Customers should audit their managed host estate to ensure all target nodes are running Python 3.9 or later. Hosts still running Python 3.8 as the highest available version will not be manageable by Ansible Core 2.20.

Tech Preview of Play Argument Specs

Ansible Core 2.20 includes a technology preview of Play Argument Specs. This feature brings the same argument specification and validation capabilities currently available to modules and roles to the play level.

Impact on Playbooks: Play argument specs will enable playbook authors to define expected variables, types, and constraints at the play level, catching misconfiguration early before tasks execute. As a technology preview within this release, customers are encouraged to experiment with this capability and provide feedback.

Module and Plugin Improvements

Ansible Core 2.20 includes a number of practical improvements to built-in modules and plugins:

blockinfile and lineinfile module — A new encoding option has been added, enabling support for files in encodings other than UTF-8. This is a welcome improvement for customers managing legacy systems or applications that use region-specific character encodings.

stat module — SELinux context is now available as a return value, with a new option to control this return. This improves visibility into the security context of files for customers in SELinux-enforcing environments.

setup module (facts) — Added a new lvs subkey within each entry of ansible_facts['vgs'] to provide complete logical volume data scoped by volume group. The top-level lvs fact deduplicates logical volume names across volume groups and may be incomplete, making this new per-VG view essential for environments with complex LVM configurations.

default callback plugin — A new option allows you to configure indentation for JSON and YAML output, giving you control over how task output is formatted for readability.

deb822_repository module — Automatic installation of the python3-debian package when missing, reducing prerequisites for managing APT repositories on Debian-based target nodes.

Removal of Deprecated Functionality

Ansible Core 2.20 completes the removal of functionality that was deprecated in prior releases. Customers who have been tracking deprecation warnings in Ansible Core 2.19 should review the following changes carefully:

Transport Changes:

The DEFAULT_TRANSPORT configuration option no longer supports the smart value. This was previously deprecated in Ansible Core 2.16. The smart value historically selected between ssh and paramiko based on platform configuration. Customers should explicitly set their transport to ssh if not already doing so.
The paramiko connection plugin no longer supports the PARAMIKO_HOST_KEY_AUTO_ADD and PARAMIKO_LOOK_FOR_KEYS configuration keys, which were previously deprecated.

Galaxy and Vault:

The ansible-galaxy command no longer supports the v2 Galaxy server API. Galaxy servers hosting collections must support v3.
The vault and unvault filters no longer accept the deprecated vaultid parameter. Use vault_id instead.

Module Deprecations:

The dnf and dnf5 modules no longer support the deprecated install_repoquery option.
The yum_repository module no longer supports the deprecated keepcache option.
The encrypt module utility no longer includes the deprecated passlib_or_crypt API.

Other Removals:

The py3compat.environ call has been removed.
Vars plugins that do not inherit from BaseVarsPlugin and define a get_vars method can no longer use the deprecated get_host_vars or get_group_vars fallback.
PowerShell module utilities no longer attempt to remove quotes from paths during Windows file operations. Playbooks that relied on this automatic quote removal will need adjustment.
The DataLoader.get_basedir method now returns an absolute path instead of a relative path. Plugin code that relies on relative paths may need adjustment.

Behavioral Changes

Argument Spec Validation: None values are now treated as empty strings for the str type for better consistency with pre-2.19 templating conversions.

failed_when Behavior: When using failed_when to suppress an error, the exception key in the result is now renamed to failed_when_suppressed_exception to prevent the error from being displayed by callbacks after being suppressed.

replace module: The replace module now reads and writes files in text mode as Unicode characters instead of bytes, and regex matching uses Unicode characters instead of bytes.

New Deprecations in 2.20

The following items are newly deprecated in Ansible Core 2.20 and will be removed in future releases:

The vars internal variable cache will be removed in 2.24. Use the vars and varnames lookups instead.
Specifying ignore_files as a string in the include_vars module is deprecated. Use a list instead.
The shell plugin's wrap_for_exec function is deprecated and being removed to simplify the plugin API.

How do I participate in the Technology Preview

We will be making available an Ansible Automation Platform Execution Environment Image that contains Ansible Core 2.20 Technology Preview. We will make this EE available at registry.redhat.com and clearly label it as Technology Preview.

This content is not included.EE Minimal RHEL 8

This content is not included.EE Minimal RHEL 9

Note: Ansible Core 2.20 Technology Preview Execution Environments are available for both RHEL 8 and RHEL 9. The Python 3.12 minimum requirement for the control node is satisfied within the EE image itself, regardless of the underlying RHEL version.

We stress that you should ONLY sync this image to a test Ansible Automation Platform cluster for the purpose of testing your automation use cases with this Technology Preview version of Ansible Core. You should NOT sync this technology preview execution environment image to a Production Cluster.

If you experience issues in your test environment, you can simply change the Execution Environment image referenced in your Job Template or Organisation back to a previous version with no harm done.

Any issues that you find would be gratefully received by our support organisation through the normal support ticket process. Technology Preview support cases do not have the same SLA as your normal contract. Technology Preview support cases are best efforts and hence should not be raised in production environments.

Testing Guidance

Given the scope of changes in Ansible Core 2.20, we recommend the following testing priorities:

Python compatibility — Verify that all control nodes and target hosts meet the new minimum Python version requirements (3.12 for controller, 3.9 for targets).
Transport configuration — If your environment relies on smart transport or paramiko-specific configuration keys, verify your connection settings are explicitly configured for ssh.
Fact access patterns — Review playbooks for deprecated direct fact variable access (e.g., ansible_os_distribution) and begin migrating to ansible_facts dictionary syntax.
Module-specific changes — Test any playbooks using dnf/dnf5, yum_repository, vault/unvault filters, replace, or ansible-galaxy against v2-only Galaxy servers.
Windows automation — If managing Windows hosts, verify that any playbooks relying on automatic quote removal from paths still function correctly.

Final Thoughts

Ansible Core 2.20 represents a significant step forward in modernizing the Ansible Core runtime, with Python version alignment, powerful new playbook capabilities like Register Projections, and the completion of a major deprecation cycle. Whether you're managing infrastructure, applications, networks, or security workflows, this release delivers tools that make automation faster, more maintainable, and easier to extend.

Thank you for your continued support and participation with Red Hat Ansible.

Product(s)

Red Hat Ansible Automation Platform

Article Type

General