Ansible vs Terraform: What Each One Does

Ansible vs Terraform: configuration management compared with infrastructure provisioning

Ansible and Terraform are often compared as if they were rivals, but they solve different halves of the same job. The short answer: Terraform creates and changes infrastructure (virtual machines, networks, DNS records, cloud services) through provider APIs and remembers what it built in a state file. Ansible configures what runs on those machines (packages, services, users, files, patches) by connecting over SSH or WinRM and running modules. Most teams that use both let Terraform build the servers and hand them to Ansible. Versions and facts below were checked against PyPI, GitHub and the official documentation on 31 October 2026. Not tested yet: we have not run these tools side by side on our own infrastructure, so there are no speed or scale claims here.

Ansible vs Terraform at a glance

PointAnsibleTerraform
Main jobConfiguration management and task automation on existing systemsProvisioning and lifecycle of infrastructure resources
LicenceFree, open source (GPL-3.0-or-later)Business Source License 1.1 from version 1.6.0, with an Additional Use Grant (see below)
Latest stable we checkedCommunity package 14.5.0 with ansible-core 2.21.5 (both 5–6 October 2026)1.17.1 (28 October 2026)
LanguageYAML playbooksHCL configuration files
How it reaches targetsAgentless: SSH with existing OS credentials, or WinRM/SSH for WindowsProvider plugins that call each platform’s API
Memory of what existsNo state file; each run checks the live systemState file (terraform.tfstate by default), refreshed before each operation
Preview of changesCheck mode (--check), where modules support itterraform plan before apply
Where it runsControl node on Linux, macOS or WSL; Python 3.12 or later for the current releaseSingle binary; official builds for Linux, macOS, Windows, FreeBSD, OpenBSD and Solaris

What Terraform does

According to HashiCorp’s introduction, Terraform is an infrastructure as code tool for cloud and on-prem resources. You describe the end state in declarative configuration files; Terraform works out the order of operations from a resource graph and calls the platform API through a provider. The documented workflow has three stages: write the configuration, run plan to see what will be created, updated or destroyed, then apply after approval.

The key difference from Ansible is state. Terraform keeps a mapping between each resource in your code and the real object it created. By default that mapping lives in a local terraform.tfstate file with a terraform.tfstate.backup beside it; teams usually move it to a shared backend. Because of state, Terraform knows that removing a resource block from the code means “destroy this VM”, which a configuration tool cannot infer on its own. The flip side is that the state file must be protected, backed up and never edited by hand.

A minimal workflow on any project looks like this:

terraform init      # download providers, set up the backend
terraform plan      # show the proposed changes
terraform apply     # make them after confirmation
terraform destroy   # remove everything this configuration manages

What Ansible does

The Ansible documentation describes it as agentless automation built on playbooks: you declare the desired state of a system in YAML, and Ansible connects to the hosts in your inventory and makes them match. Modules are written to be idempotent, so when a host already matches the playbook, a second run changes nothing. There is no agent to install on managed hosts and no state database; the live system is the source of truth on every run.

That makes Ansible good at the work that happens after a server exists: installing packages, templating config files, managing services and users, rolling restarts, and patching. On Windows it uses WinRM or OpenSSH with PowerShell modules, and it pairs with Chocolatey for software installs. A typical playbook run:

ansible-playbook -i inventory.ini site.yml --check --diff   # dry run
ansible-playbook -i inventory.ini site.yml                  # apply

Ansible can also create cloud and virtualization resources through modules, but without a state file it does not track what it created. Deleting a task from a playbook does not remove the resource; you need an explicit task with state: absent.

Can Ansible replace Terraform, or the other way round?

For small, stable setups, partly. A handful of VMs that rarely change can be created with Ansible modules, and Terraform can run commands on new machines with provisioners. Neither is a good substitute at scale:

  • Using Ansible for provisioning means writing your own create, update and teardown logic, and detecting drift yourself.
  • Using Terraform for configuration means provisioners. HashiCorp’s documentation says Terraform is primarily designed for immutable infrastructure and strongly recommends purpose-built tools for post-apply work. Ongoing changes inside the OS, such as monthly patching, do not fit Terraform’s model of resources and state.

The practical rule: if the thing has an API and a lifecycle (create, resize, delete), it belongs to Terraform. If the thing lives inside an operating system and changes regularly, it belongs to Ansible.

Using Ansible and Terraform together

Both projects publish official integration points, so you do not need to glue them with shell scripts:

  • Terraform provider ansible/ansible (version 1.5.0, partner tier in the Terraform Registry, GPL-3.0). It adds resources such as ansible_host and ansible_group to describe inventory in Terraform, ansible_playbook to run a playbook, and ansible_vault.
  • Ansible collection cloud.terraform (version 4.0.0, requires ansible-core 2.15 or later). Its terraform module runs a Terraform deployment from a playbook, and the terraform_provider inventory plugin builds an Ansible inventory from the hosts recorded in Terraform state.

A common flow: Terraform creates the VMs and declares them with ansible_host resources; Ansible reads that inventory and configures the machines.

# Terraform: register a VM in the inventory
resource "ansible_host" "web1" {
  name   = "web1.example.internal"
  groups = ["web"]
}

# Ansible: inventory.yml in the Terraform project directory
plugin: cloud.terraform.terraform_provider

# Then
ansible-galaxy collection install cloud.terraform
ansible-inventory -i inventory.yml --graph
ansible-playbook -i inventory.yml site.yml

The inventory plugin reads state through terraform show, so it needs an initialized working directory, and according to its documentation it does not support caching.

Licence: what changes for your team

Ansible is GPL-3.0-or-later and free to use for any purpose. Red Hat Ansible Automation Platform is a separate commercial product; you do not need it to run playbooks.

Terraform 1.6.0 and later use the Business Source License 1.1. The current LICENSE file names IBM as licensor. Its Additional Use Grant allows production use as long as you do not offer Terraform to third parties, hosted or embedded, as a paid product that competes with the vendor’s paid versions; free products are not treated as competitive. For a sysadmin or MSP team managing its own or clients’ infrastructure, this is usually not a blocker. If you need a fully open source licence, OpenTofu is an MPL-2.0 fork that reads the same HCL; its latest release when we checked was 1.13.2 (21 October 2026). This is not legal advice; read the licence text for your case.

Proxmox VE and other on-prem targets

“Ansible vs Terraform for Proxmox” is a frequent search, and both tools can drive Proxmox VE. On the Terraform side, the actively maintained bpg/proxmox provider is a community-tier provider (0.119.0 on 29 October 2026). On the Ansible side, the community.proxmox collection (2.1.0) includes modules such as proxmox_kvm for VMs, proxmox_disk, proxmox_nic, proxmox_backup and firewall modules. Neither is an official Proxmox product, so check each release note before upgrading. The same split applies: use Terraform when you want a plan and state for a lab you rebuild often; use Ansible when you mostly manage a fixed set of hosts. For local test VMs, Vagrant is a lighter option.

Who each tool suits

  • Ansible only: a fixed fleet of Linux and Windows servers that need patching, software and configuration, with machines created by hand or by a hypervisor template. Good fit for small IT teams and MSPs.
  • Terraform only: cloud accounts, DNS, networks and managed services where almost everything is an API resource and machines are replaced rather than changed.
  • Both: environments you rebuild or scale, where servers must also be configured after creation. Keep each tool in its lane and connect them with the official provider and collection.

For CI/CD and other options see the DevOps automation tools hub; for hypervisors, the virtualization and container tools hub.

Limitations

This comparison is based on official documentation, PyPI, GitHub releases and the Terraform Registry as of 31 October 2026. Not tested yet: we have not measured run times, memory use or behaviour on large inventories. Integration resource names and collection modules change between releases; check the current docs before copying examples.

FAQ

Ansible vs Terraform: which is better?

Neither is better in general. Terraform is better for creating and destroying infrastructure through APIs with a plan and state. Ansible is better for configuring operating systems and applications on machines that already exist.

Can Ansible replace Terraform?

Only for simple, rarely changing setups. Ansible has no state file, so it does not track or clean up the resources it created unless you write explicit tasks for that.

Can Terraform and Ansible be used together?

Yes. The ansible/ansible Terraform provider and the cloud.terraform Ansible collection are the official integration points: Terraform builds the hosts, Ansible reads them as inventory and configures them.

Is Terraform free?

The Terraform CLI can be downloaded and used without charge, but since version 1.6.0 it is under the Business Source License 1.1, which is not an open source licence. OpenTofu is the MPL-2.0 alternative.

Can Ansible be installed on Windows?

Not as a native control node. Run Ansible in WSL or a Linux VM; it can still manage Windows hosts over WinRM or SSH.

Last updated: 31 October 2026 · ITForgePro editorial team. Licence, version and platform details are checked against each developer's official documentation.

Other articles

Submit your application