Is Ansible Still Relevant in 2026? ansible-core 2.22 vs Terraform

Every year someone in a team channel asks whether Ansible is still relevant, usually right after they have spent an afternoon fighting a YAML indentation error in a playbook nobody has touched since 2021. I have been writing Ansible on and off for most of my fourteen years in infrastructure, and the honest answer in 2026 is more interesting than "yes" or "it's dead". Ansible lost the job of building cloud infrastructure to Terraform and OpenTofu, lost application configuration to containers and Kubernetes, and still owns a large and stubborn set of jobs that neither of those does well. This post covers what is current (ansible-core 2.22 shipped on 2 November 2026), how Ansible compares with Terraform, cloud-init and Kubernetes, where configuration management still fits, and what Event-Driven Ansible and the Lightspeed AI tooling actually do once you look past the press releases.

What is Ansible actually for in 2026?

Ansible is an agentless automation tool: a control node pushes small Python modules to target machines over SSH (or WinRM for Windows, or vendor APIs for network gear), runs them, and collects JSON results. Each module is meant to be idempotent, so ansible.builtin.apt: name=nginx state=present does nothing on a host that already has nginx. That design is the whole reason the tool survived: there is no daemon to install, no state file to lock, and a playbook can run against a laptop, a Raspberry Pi and a Cisco switch in the same play.

What it is not is a resource lifecycle manager. Ansible has cloud modules (the amazon.aws collection ships at version 11.5.1 inside the Ansible 14.6.0 package, per the build data), but it has no plan, no dependency graph between resources and no record of what it created. Delete a task and the resource it made stays in your account forever. That gap is why the industry settled on a split: a declarative tool provisions, something else configures.

ansible-core 2.22, Ansible 14 and 15: what is current?

There are two things called "Ansible", and the versions confuse everyone. ansible-core is the engine: the CLI, the language, and the ansible.builtin modules. The ansible package is a community bundle of ansible-core plus a curated set of collections. Ansible 14.6.0 pins ansible-core~=2.21.6 and bundles 94 collections, from amazon.aws to cisco.ios, according to its published dependency file.

Release	Date	Controller Python	Status (Nov 2026)	Source
ansible-core 2.20	GA 3 Nov 2025	3.12 to 3.14	Security fixes ended 2 Nov 2026, EOL May 2027	Ansible support matrix
ansible-core 2.21 (2.21.6)	GA May 2026, 2.21.6 on 2 Nov 2026	3.12 to 3.14	Security fixes to May 2027, EOL Nov 2027	Support matrix, PyPI
ansible-core 2.22.0	2 Nov 2026	3.13 and newer (3.12 dropped)	Current	2.22 changelog
Ansible 14.6.0 (community)	4 Nov 2026	3.12 and newer	Current, on core 2.21	PyPI
Ansible 15.0.0 (community)	beta1 3 Nov, rc1 scheduled 10 Nov, final planned 17 or 24 Nov 2026	Follows core 2.22	In pre-release	Ansible 15 roadmap
Ubuntu 24.04 apt package	Noble release	System Python 3.12	ansible-core 2.16.3, out of upstream support	Launchpad

That last row is the one that bites people. apt install ansible-core on Ubuntu 24.04 gives you 2.16.3, which upstream stopped supporting long ago, and a lot of "Ansible is broken" forum threads are really "my distro's Ansible is two years old". Install it per project with a pinned version instead:

# Pin the engine per project instead of using the distro package (2.16.3 on Ubuntu 24.04).
# ansible-core 2.21.x supports controller Python 3.12 to 3.14; 2.22 needs 3.13+.
uv venv --python 3.12 .venv
uv pip install --python .venv/bin/python "ansible-core==2.21.6" "ansible-lint==26.11.0"
.venv/bin/ansible --version | head -1
# ansible [core 2.21.6]

I ran exactly that while writing this, so the output is real. The headline change in 2.22 is automatic secret masking: vault plaintext, become passwords, no_log values and the values returned by the password and unvault lookups are now registered as secrets and replaced with $REDACTED$ in display output and in the results handed to callback plugins, per the 2.22 changelog. That matters more than it sounds in 2026, when the thing reading your CI logs is increasingly an AI agent with a context window and no sense of discretion. The same release stops printing raw SSH stdout at -vvv, and ansible-config now validates plugin sections such as [ssh_connection] by default.

Ansible vs Terraform: provisioning vs configuration

The short version: Terraform (now 1.17.1, released 28 October 2026) and OpenTofu (1.13.9, 5 November 2026) create and destroy things through cloud APIs and remember what they made in state. Ansible logs into things and changes what is inside them. They overlap at the edges, but they answer different questions.

Terraform is the better tool when the resource has an API and a lifecycle: VPCs, IAM roles, managed databases, DNS records. Its plan shows a diff before anything changes, and removing a block removes the resource. I covered how teams structure that side in Infrastructure as Code in 2026 and how to lay out Terraform environments.

Ansible is the better tool when the target is an operating system or a device: packages, users, sudoers, sshd, kernel parameters, a switch's VLAN table. Terraform can run a script on first boot through user_data or a provisioner, but HashiCorp's provisioner docs tell you to exhaust every alternative first, and nothing re-runs them when the server drifts six months later.

The corporate picture has also converged. IBM closed its $6.4 billion HashiCorp acquisition on 27 February 2025, and IBM already owned Red Hat, so the two most common tools for this split now sit under one parent. The official terraform-provider-ansible (v1.5.0, June 2026) lets Terraform write hosts and groups into an Ansible inventory, which is the cleanest way I know to hand off from "the VM exists" to "the VM is configured".

Ansible vs cloud-init vs Kubernetes: do you still need configuration management?

The strongest argument against Ansible is not Terraform. It is immutable infrastructure. If every server is built from an image and replaced rather than patched, there is nothing left to configure after boot, and the configuration tool shrinks to whatever runs once at first boot.

That first-boot tool is usually cloud-init (26.2, released July 2026), which reads user-data on almost every cloud image and can create users, write files, install packages and run commands. For a fleet of short-lived, identical VMs behind an autoscaling group, cloud-init plus a baked image is enough, and adding Ansible would be ceremony.

Kubernetes took a bigger bite. Application configuration now lives in container images, Helm charts and Kustomize overlays, and the node operating system is often something you never log into. If your whole estate is EKS or GKE with managed node groups, you can reasonably go years without writing a playbook. I made the broader case for and against that model in Is Kubernetes Still Worth It in 2026?.

The trouble is that most organisations do not have that estate. They have long-lived VMs that someone has to patch, a database host that cannot be replaced on a whim, and bare metal under the Kubernetes cluster. cloud-init runs once; it does not notice when someone edits /etc/ssh/sshd_config by hand in March. Ansible run on a schedule, with --check --diff, does.

Where Ansible still wins: VMs, network gear and bare metal

Here is where I still reach for it without hesitation.

Long-lived Linux and Windows servers. Baseline hardening, patch windows, user and key rotation, and compliance checks across hundreds of hosts. The companion guide to this post, how to harden an Ubuntu 24.04 server with an Ansible playbook, is a working example of exactly this job.

Network devices. Switches, routers and firewalls rarely run an agent and often expose only SSH, NETCONF or a vendor API. The community package bundles collections for Cisco IOS, IOS XR and NX-OS, Arista EOS, Cisco ACI and Meraki, among others (Ansible 14.6.0 deps), because an agentless SSH-and-API tool is a natural fit for hardware you cannot install software on.

Bare metal and GPU hosts. The machines under an AI cluster need drivers, firmware, kernel parameters and container runtimes before Kubernetes can schedule anything on them. Image-based installs help, but someone still has to roll a driver update across racks without rebuilding every node.

Day-2 operations that cross tools. Rotating a certificate on a load balancer, a VM and a DNS record in one ordered run is awkward in Terraform and natural in a playbook.

How many people actually do this? The Stack Overflow 2025 Developer Survey asked which cloud, container and infrastructure-as-code tools respondents had done extensive work in over the past year. The figure plots the all-respondents numbers.

Ansible sits at 11.7% of all respondents and 11.2% of professional developers, next to Podman and well behind Docker and Terraform. That is a survey of developers, not operators, so it undercounts the sysadmins and network engineers who use Ansible most. It is still a useful corrective to both camps: Ansible is not dead, and it is not the default anymore either.

Event-Driven Ansible and Lightspeed: what the AI and automation parts really do

Red Hat has spent two years repositioning Ansible from "run a playbook" to "the execution layer that other systems trigger". Two pieces matter.

Event-Driven Ansible is ansible-rulebook (1.3.2, September 2026) plus event source plugins. A rulebook listens to a source such as a webhook or Kafka topic, matches conditions, and runs a playbook or job template. It needs a Java 17 or newer runtime because the rule engine is Drools, per the installation docs, and several sources including the webhook have moved into ansible-rulebook itself under the eda.builtin namespace, per the ansible.eda collection README. A minimal rulebook looks like this:

# restart-on-alert.yml, run with: ansible-rulebook -r restart-on-alert.yml -i inventory.yml
# Tested against the ansible-rulebook 1.3.2 docs. Put a token or HMAC secret on any real webhook.
- name: Remediate known alerts
  hosts: all
  sources:
    - eda.builtin.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Restart nginx when Alertmanager reports it down
      condition: event.payload.alerts[0].labels.alertname == "NginxDown"
      action:
        run_playbook:
          name: playbooks/restart-nginx.yml

That is useful for a narrow class of well-understood remediations. It is also a remote trigger for root-level changes on your fleet, so the webhook needs the token or hmac_secret options its source plugin supports, and the playbooks it calls should be boring.

Lightspeed is now two products with new names. The code generator in the VS Code extension, renamed the automation coding assistant, still defaults to IBM watsonx Code Assistant but can now use Google Gemini, Red Hat AI or an OpenAI-compatible endpoint, per Red Hat's automation coding assistant page and the extension's provider docs. The chat assistant inside Ansible Automation Platform, renamed the automation intelligent assistant, helps administrators run the platform itself. Ansible Automation Platform 2.7, generally available since June 2026, added a Technology Preview MCP server that lets external AI tools query job status, gather facts and launch automation workflows, according to Red Hat Developer.

My read: the MCP server is the strategically interesting part. An agent that can call a vetted, RBAC-controlled job template is much safer than an agent with a shell, and that is the same argument I make in policy as code for AI agents. The code generator is fine for scaffolding tasks but still produces plausible YAML that needs ansible-lint and a human read.

Should you learn Ansible in 2026?

If you work on Kubernetes-only, cloud-native application teams: learn it to the level of reading a playbook and running one, and spend your depth on Terraform and Kubernetes. If you work in platform, SRE, network, security operations or anywhere with long-lived servers or bare metal: yes, properly, including roles, collections, --check --diff, Molecule or at least ansible-lint, and inventory design. It is also a cheap skill; the core concepts fit in a week. The DevOps roadmap post covers where it sits next to everything else.

FAQ

Is Ansible being replaced by Terraform?

No. Terraform replaced Ansible for provisioning cloud resources, which was never Ansible's strength. Configuring operating systems, network devices and bare metal after they exist is still Ansible's job, and the official terraform-provider-ansible exists precisely so the two tools hand off to each other.

What is the latest version of Ansible in November 2026?

ansible-core 2.22.0 was released on 2 November 2026 and needs Python 3.13 or newer on the controller. The community ansible package is at 14.6.0, built on ansible-core 2.21.6, and Ansible 15.0.0 (built on core 2.22) is in pre-release (beta1 on 3 November, rc1 scheduled for 10 November) with a final release planned for 17 or 24 November 2026.

Is Ansible dead because of Kubernetes?

Kubernetes took over application deployment and configuration, so a pure Kubernetes shop needs much less Ansible. Somebody still has to build and patch the nodes, configure the network and manage the servers that are not in the cluster, and most organisations have plenty of those.

Do I need Ansible if I use cloud-init?

For identical, short-lived VMs built from a baked image, cloud-init is often enough. For long-lived servers you need something that re-applies and verifies configuration over time; cloud-init runs at first boot and does not detect drift afterwards.

This quarter I would do three things on any estate with real servers in it. Move every controller off distro-packaged Ansible onto a pinned ansible-core in a virtual environment, so the 2.22 secret masking and the Python 3.13 requirement are deliberate upgrades rather than surprises. Put ansible-lint and a scheduled --check --diff run in CI, so drift shows up as a report instead of an incident. And draw the line explicitly: Terraform or OpenTofu creates it, Ansible configures what lives inside it, and anything an AI agent is allowed to trigger goes through a reviewed job template, never a raw shell.

Related: SSH Security Best Practices 2026: OpenSSH 10.6, ML-KEM and FIDO2 Keys, Crossplane vs Terraform vs Pulumi in 2026: Control Plane or Plan/Apply? and Infrastructure as Code in 2026: Two Forks at 1.16 and 1.13, a $6.4B Owner, 912 Public State Files, and One Agent That Ran terraform destroy.