Terraform vs Ansible: Which Should You Use?

If you are moving from clicking around a cloud console to managing infrastructure as code, you will hit this question fast: Terraform or Ansible? Both are popular, both use text files you keep in Git, and both can create a server in the cloud. So which one should you learn, and which should your team standardize on?

The honest answer is that they were built for different jobs. Terraform is a provisioning tool. Ansible is a configuration management and automation tool. Once you see that split, the choice gets much easier, and you will probably find you want both.

New to the concept? Our plain-English guide to infrastructure as code covers the basics first.

Provisioning vs configuration: the core difference

Think of building a restaurant.

• Provisioning is the construction: the building, the plumbing, the electrical supply. In cloud terms, that means networks, virtual machines, load balancers, databases, DNS records and access policies.
• Configuration is fitting out the kitchen: installing equipment, setting up the menu, training staff. In server terms, that means installing packages, editing config files, creating users, deploying application code and restarting services.

Terraform is designed for provisioning. You describe the infrastructure you want, and it creates, changes or destroys cloud resources to match.

Ansible is designed for configuration and task automation. You describe what should be true on your machines, and it connects to them and makes it so.

There is overlap. Ansible has modules that can create cloud resources, and Terraform can run basic setup scripts on new machines. But each tool is strongest in its own lane.

Key takeaway: Terraform builds the infrastructure; Ansible configures what runs on it. Asking “Terraform or Ansible?” is often like asking “builder or interior designer?” Most serious projects need both.

Side-by-side comparison

How Terraform works

You write configuration files in HCL describing resources, such as “a virtual network with these subnets” or “a database of this size.” Terraform uses providers, plugins that talk to each platform’s API, to create them.

The key concept is state. HashiCorp’s documentation describes state as a record that maps real-world infrastructure to the resources in your configuration. By default it is a local file called terraform.tfstate. When you run terraform plan, Terraform compares your configuration with the state and the real infrastructure, then shows exactly what it will add, change or destroy. terraform apply makes those changes.

This plan step is Terraform’s superpower. Reviewers can see “this will delete a database” before it happens.

State also brings responsibilities:

• Store it remotely in a backend such as cloud object storage or HCP Terraform, so the team shares one source of truth and locking prevents simultaneous changes.
• Protect it. HashiCorp warns that state can contain secrets, so it should never be committed to version control.
• Avoid changes outside Terraform. Manual edits in the cloud console cause drift, which the next plan will try to undo.

The license question and OpenTofu

On August 10, 2023, HashiCorp announced it was moving its products from the Mozilla Public License 2.0 to the Business Source License 1.1 for future releases. The license still allows most end users to use Terraform, but restricts building competing commercial offerings.

In response, a group of companies forked the last open source version as OpenTofu, which now runs under the Linux Foundation and describes itself as a drop-in replacement for Terraform. IBM completed its acquisition of HashiCorp on February 27, 2025. For most teams using Terraform internally, the license change has little practical effect, but if open source licensing matters to your organization, OpenTofu is worth evaluating. This is not legal advice; check the license terms with your legal team if you build products on top of these tools.

How Ansible works

Ansible’s documentation highlights its agentless architecture: it uses SSH with existing operating system credentials to reach remote machines, so there is nothing extra to install on the servers you manage.

You write playbooks in YAML. Each playbook lists tasks, such as “install nginx,” “copy this config file,” or “make sure this service is running,” and Ansible runs them in order against hosts listed in an inventory. Most modules are idempotent: if a server already matches the desired state, Ansible makes no change, even if you run the playbook again.

Ansible is also good for one-off operational work: rolling out a security patch to 200 servers, rotating a certificate, or restarting a service across a cluster in a controlled order. Red Hat also sells Ansible Automation Platform, a commercial product that adds a web interface, access control and scheduling on top of the open source engine.

When to use each

If your applications run in containers on a managed platform like Kubernetes, you may need less Ansible, because container images replace much of the server configuration work. Our comparison of Docker vs Kubernetes explains that model.

How teams use Terraform and Ansible together

The most common pattern is a hand-off:

1. Terraform provisions the network, virtual machines, load balancer and database.
2. Terraform outputs details such as IP addresses or hostnames.
3. Ansible consumes those outputs, often through a dynamic inventory that queries the cloud directly, and configures each server.
4. A CI/CD pipeline runs both, typically Terraform plan for review, Terraform apply after approval, then the Ansible playbook.

Git commit | [CI/CD pipeline] |-- terraform plan -> human review |-- terraform apply -> creates VMs, network, database |-- ansible-playbook -> installs packages, config, app v Running, configured environment

Keep a clear boundary. Let Terraform own anything with an API-driven lifecycle, and let Ansible own what happens inside the machines. When both tools try to manage the same thing, they fight, and drift follows.

If you are choosing a pipeline tool to run this workflow, see our comparison of GitHub Actions vs GitLab CI vs Jenkins.

Where to start

1. List what you manage today. Separate cloud resources (provisioning) from server setup and app deployment (configuration).
2. Start with the bigger pain. If environments are hand-built in the console, start with Terraform. If servers drift and patching is manual, start with Ansible.
3. Pick one small, real target. For Terraform, a single network and VM in a test account. For Ansible, a playbook that sets up one web server.
4. Put everything in Git and require review for changes.
5. Set up remote state with locking before a second person touches Terraform.
6. Automate in CI/CD once the manual runs are reliable. Our guide to building a CI/CD pipeline shows the basic structure.
7. Secure secrets. Keep credentials in a secrets manager or Ansible Vault, not in plain-text files. Our cloud security checklist covers related controls.

Conclusion

Terraform and Ansible are not true rivals. Terraform is the better tool for creating and tracking infrastructure, with a plan you can review before anything changes. Ansible is the better tool for configuring machines and running operational tasks, with no agents to install. Learn the one that matches your biggest problem today, and expect to add the other. Both skills show up in DevOps engineer job descriptions for a reason.

Sources

• HashiCorp: Terraform state documentation — what state is, default local storage and the warning about secrets
• HashiCorp: HashiCorp adopts Business Source License — August 10, 2023 move from MPL 2.0 to BSL 1.1
• IBM: IBM completes acquisition of HashiCorp — February 27, 2025 completion
• Ansible documentation: Introduction — agentless architecture, SSH, YAML playbooks and idempotency
• OpenTofu — Terraform fork under the Linux Foundation