Ansible vs Terraform
Ansible vs Terraform is mostly not either/or: one configures servers, the other provisions cloud infrastructure. Compare state, language, licensing and pricing.
Quick Answer
These tools are complementary, not direct rivals. Terraform (or OpenTofu) is the better tool for provisioning cloud resources declaratively with state; Ansible is better for configuring OS and software on machines and for ad-hoc orchestration. Most mature teams run Terraform to create infrastructure and Ansible to configure what runs on it.
Reviewed by TechLogHub Engineering Team. Last updated October 15, 2026. Updated for Terraform 1.16 (Aug 2026), ansible-core 2.21 / Ansible 14, and HCP Terraform's current 500-resource free tier and per-resource Essentials billing.
| Feature | Ansible | Terraform |
|---|---|---|
| Primary Role | Configuration management & orchestration | Infrastructure provisioning |
| Paradigm | Procedural tasks with idempotent modules | Declarative desired state |
| Language | YAML + Jinja2 | HCL |
| State Management | Stateless (queries live systems) | State file (local or remote backend) |
| Agentless | ||
| Change Preview | --check / --diff mode (module-dependent) | terraform plan (full diff) |
| Drift Detection | Partial, via check mode | Yes, via plan / refresh |
| Cloud API Coverage | Good (collections), narrower than Terraform | Very broad (provider registry) |
| License | GPLv3 (ansible-core) | BSL 1.1 (OpenTofu fork: MPL 2.0) |
| Managed / Enterprise Offering | Red Hat Ansible Automation Platform (quote-based) | HCP Terraform (free up to 500 resources, then per-resource) |
| Latest Version | ansible-core 2.21 / Ansible 14 | 1.16.x (Oct 2026) |
Ansible
Red Hat's agentless automation engine that connects over SSH or WinRM and runs YAML playbooks to configure systems, deploy software and orchestrate operational tasks.
Pros
- Agentless: only needs SSH and Python on targets, nothing to install or keep running
- YAML playbooks are approachable for ops engineers and sysadmins
- Excellent at OS configuration, package installs, user management and app deployment
- Ad-hoc commands and rolling, ordered orchestration across fleets
- Huge collection ecosystem on Ansible Galaxy, including network devices
- ansible-core is GPLv3 open source with predictable six-month releases
Cons
- No state file, so it cannot reliably know what to delete when you remove resources from code
- Idempotency depends on module quality and how you write tasks
- Slow on large fleets compared with pull-based or image-based approaches
- Cloud provisioning modules exist but lag Terraform providers in coverage and plan/preview
- Ansible Automation Platform pricing is quote-based and per managed node
Best For
Configuring operating systems and software on existing servers, network devices and VMs, and orchestrating operational runbooks.
Terraform
HashiCorp's (now IBM's) declarative infrastructure-as-code tool that uses HCL and provider plugins to create, update and destroy cloud and SaaS resources, tracking them in a state file.
Pros
- terraform plan shows an exact diff of creates, updates and destroys before applying
- State file tracks every managed resource, enabling clean deletes and dependency graphs
- Thousands of providers covering AWS, Azure, GCP, Kubernetes, Cloudflare, Datadog and more
- Reusable modules and a public registry for common infrastructure patterns
- Drift detection by comparing state to real infrastructure
- OpenTofu offers an MPL-licensed, largely compatible fork if licensing matters
Cons
- Business Source License since 2023, so it is no longer open source in the OSI sense
- State files must be stored, locked and secured, and they can contain secrets
- Poor fit for configuring inside servers; provisioners are discouraged
- HCP Terraform bills per managed resource beyond a 500-resource free tier
- Refactoring (moving resources between modules or state) takes care
Best For
Provisioning and managing cloud infrastructure and SaaS resources declaratively with reviewable plans.
Different jobs: provisioning vs configuration
Terraform answers 'what infrastructure should exist?' You declare a VPC, a managed database and a Kubernetes cluster, and Terraform works out the API calls to create, change or destroy them. It is strongest when the resources are cloud or SaaS objects with APIs. Ansible answers 'what state should this machine be in?' It SSHes into hosts and makes sure packages are installed, config files are templated, services are running and users exist. It is strongest for long-lived servers, VMs, on-prem hardware and network devices. The overlap is real: Ansible has cloud modules and Terraform has provisioners. But Terraform's own docs treat provisioners as a last resort, and Ansible's cloud modules lack a plan step and state. Using each in its lane avoids most of the pain teams report. A quick test: if the thing you are managing has a cloud API and an ID, Terraform is probably the right tool. If it has a shell, packages and config files, Ansible probably is.
State: Terraform's superpower and its burden
Terraform keeps a state file mapping your code to real resource IDs. That is what makes terraform plan accurate, what lets it delete a resource when you remove it from code, and what enables drift detection. It is also operational overhead: state must live in a remote backend with locking, must be protected because it can contain secrets, and must be carefully manipulated when you refactor. Ansible has no state. Each run inspects the target and changes what differs. That keeps things simple, but deleting a task does not remove what it created; you have to write an explicit 'state: absent' task. Check mode gives a preview, but its accuracy depends on each module. For ephemeral cloud infrastructure, state is worth the burden. For configuring hosts, statelessness is a feature. Teams that try to use one tool for both jobs usually end up writing workarounds, such as Terraform remote-exec scripts or Ansible tasks that hand-roll delete logic. Splitting responsibilities keeps each codebase simpler and easier to review.
Licensing, ownership and cost in 2026
HashiCorp moved Terraform to the Business Source License in 2023, and IBM completed its acquisition of HashiCorp in early 2025. The CLI remains free to use for your own infrastructure, but it is not OSI open source; OpenTofu, a Linux Foundation fork under MPL 2.0, is the alternative for teams that need that. Red Hat, which owns Ansible, is also part of IBM, so both tools now share a corporate parent. HCP Terraform's free tier covers up to 500 managed resources with one concurrent run; beyond that, the Essentials tier bills per managed resource per hour, and Standard and Premium are sales-quoted. ansible-core is GPLv3 and free. Red Hat Ansible Automation Platform adds a web UI, RBAC, execution environments and support, priced per managed node via sales quotes. Many teams get by with open-source AWX or plain CLI runs in CI. If licensing or vendor concentration worries you, OpenTofu and AWX keep both halves of the stack fully open source. Check provider and module compatibility before switching, but most Terraform codebases move to OpenTofu with little change.
Using them together in practice
The common pattern is a pipeline: Terraform provisions VMs, load balancers and networking, then outputs host addresses into an Ansible inventory, and Ansible configures the OS and deploys the application. Dynamic inventory plugins for AWS, Azure and GCP let Ansible discover Terraform-created hosts by tags, avoiding brittle handoffs. For Kubernetes-centric stacks the balance shifts. Terraform creates the cluster and cloud dependencies, and GitOps tools such as Argo CD or Flux handle in-cluster configuration, so Ansible may only be needed for bastion hosts, legacy VMs or network gear. For image-based workflows, Ansible often runs inside Packer to bake AMIs, and Terraform then deploys those images. That moves configuration to build time, which is faster and more reproducible than configuring live servers. Whatever split you choose, keep the boundary explicit: document which tool owns which resources, and never let both manage the same object. That single rule prevents most of the drift and surprise deletions that give infrastructure-as-code a bad name.
Verdict
Do not treat this as either/or. Use Terraform (or OpenTofu) to create networks, clusters, databases, DNS and IAM, since its plan and state model is built for that. Use Ansible to configure what runs on the machines Terraform creates, and for patching and runbook-style orchestration. If you must pick one, pick Terraform for cloud-native stacks built on managed services and Kubernetes, and Ansible for fleets of long-lived VMs, on-prem servers or network gear.