Ansible vs Terraform: Which One Do You Actually Need? (2026)

The Night I Tried to Crown a Winner

It was 2023, deep in the Clickly rabbit hole — my URL shortener with, famously, zero users. I’d already convinced myself a redirect service needed a Kubernetes cluster (I confessed to that here), and now I was staring at two tools everyone in DevOps kept mentioning in the same breath: Terraform and Ansible.

I did what a broke engineer does at 1 AM. I opened a spreadsheet and built a comparison table, like I was picking a phone. Terraform in one column, Ansible in the other. Features, pricing, community size.

I spent two hours before it hit me: I was comparing a hammer to a screwdriver and asking which was “better.” The whole exercise was wrong. Terraform and Ansible aren’t competitors. They’re not even in the same fight. They just hang out in the same neighborhood — infrastructure-as-code — so beginners assume they’re rivals.

Let me save you the two hours. Here’s what each one actually does, why the “vs” is mostly a myth, and — because this is the Broken Engineer Guide — why you probably need neither yet.

---

They’re Not Fighting — They Do Different Jobs

The one sentence that unlocks everything: Terraform builds the box. Ansible sets up the box.

Terraform is a provisioning tool. Its job is to create infrastructure that doesn’t exist yet — servers, networks, load balancers, DNS records, databases, storage buckets. You describe the infrastructure you want, and Terraform talks to AWS, Google Cloud, or Azure and makes it real. Empty land, and Terraform pours the foundation and frames the house.

Ansible is a configuration management tool. It assumes the box already exists — a running server with an IP you can reach — and its job is to make what’s inside it correct. Install nginx. Drop in a config file. Create a user. Start a service. Harden SSH. Ansible walks into the framed house and installs the plumbing, wires the lights, paints the walls.

That house analogy is the same one I used in the Ansible Galaxy post, and it holds up because it’s just true. Terraform doesn’t know how to install nginx. Ansible doesn’t know how to create a VPC. Asking “Ansible or Terraform?” is like asking “electrician or bricklayer?” — for a real building the answer is both, in order.

---

Declarative vs Procedural (the Real Mental Split)

The deeper difference — the one that actually changes how you write code — is how you tell each tool what you want.

Terraform is declarative. You describe the end state — “I want a VPC, two subnets, and an RDS instance” — not how to get there. Terraform reads your files, builds a dependency graph, figures out the subnets need the VPC first, and executes in the right order on its own. You describe the destination; it plots the route.

Ansible is procedural. A playbook is an ordered list of tasks that runs top to bottom, like a shell script. “Install this package. Then copy this file. Then restart this service.” You control the sequence yourself. It reads less like a blueprint, more like a recipe.

There’s a nuance that trips people up: Ansible’s individual tasks are still declarative and idempotent — you write “package nginx is present,” not “run apt-get install.” But the flow between tasks is procedural. You own the ordering; Terraform owns it for you.

One more structural difference that matters in practice: Ansible is agentless. It connects over plain SSH and runs Python — nothing to install on the target first, no daemon in the background. That’s a big part of why it beat older tools like Puppet, Chef, and Salt (which historically wanted an agent on every node) for a lot of teams. Terraform doesn’t run on your servers at all — it runs from your laptop or a CI job and talks to cloud APIs.

---

State: Terraform’s Superpower and Its Loaded Gun

Here’s the single biggest operational difference between the two, and it’s the one that’ll actually hurt you if you ignore it.

Terraform keeps state. Ansible doesn’t.

Terraform maintains a state file — a JSON ledger mapping “the bucket I called uploads in my config” to “the actual bucket living in AWS.” Every terraform apply diffs your config against that state against reality, and works out the minimum set of things to create, change, or destroy. That’s what makes it so good at managing infrastructure over time: it remembers what it built, so it can update or tear it down cleanly later.

The catch is that the state file becomes the most dangerous object you own. Lose it, corrupt it, or let two people run apply at once, and you can orphan or nuke live resources. I went deep on this — remote state, locking, secrets leaking in — in the Terraform import guide. Short version: the moment real infrastructure lives in a state file, lock it down like a password vault.

Ansible has none of this. It doesn’t track state between runs. It shows up, checks the current reality (“is nginx installed? no?”), makes it match your playbook, and leaves. Nothing to lose, corrupt, or lock. The trade-off is that Ansible has no memory — it can’t tell you “here’s everything I manage and what drifted,” because it never wrote that down. It only knows what you point it at, right now.

State is exactly why Terraform is the right tool for provisioning (you want a durable record of the infra you stood up) and Ansible is the right tool for configuration (you just want the box correct every time it runs).

---

Idempotency: The Word Both Camps Love

You’ll hear “idempotent” in both worlds, and it’s worth thirty seconds because it’s the one piece of jargon that actually matters. It means: run it once or a hundred times, you get the same result. No damage from repeating it.

Both tools are built around this, from opposite directions. Terraform gets it from state — it knows what exists, so a second apply with no changes is a no-op. Ansible gets it from its modules — each task checks reality first, so “ensure nginx is installed” does nothing if nginx is already there. Same promise, different mechanism. It’s why you can re-run either without fear — the whole point of infrastructure-as-code versus a pile of shell scripts you’re terrified to touch twice.

---

The 2026 Ownership Plot Twist: Both Roll Up to IBM

Here’s a genuinely funny wrinkle if you’re comparing these two in 2026: after all the corporate shuffling, they both belong to the same company now.

Terraform comes from HashiCorp. In August 2023, HashiCorp relicensed it from the open-source MPL to the Business Source License — source-available, restricted, not OSI-approved open source. The community revolted, and a fork called OpenTofu spun up almost overnight, kept the MPL, and joined the Linux Foundation as a CNCF sandbox project (April 2025) with real momentum. OpenTofu 1.12 landed in May 2026; it’s a near drop-in, you just type tofu instead of terraform. Then the twist: IBM closed its $6.4 billion acquisition of HashiCorp in February 2025. Terraform is now an IBM product.

Ansible? It’s a Red Hat project — Red Hat bought it in 2015 for around $126 million. And Red Hat has been an IBM subsidiary since 2019 ($34 billion deal).

So the two tools beginners think are locked in mortal combat are, as of 2026, both owned by IBM. They were never rivals — they’re practically corporate roommates. (The full license-fork saga is in the Terraform import post; the Ansible enterprise side is in the Automation Platform guide.)

For a bootstrapper: if you care about genuinely open tooling, OpenTofu is the safer long-term bet; if you want the biggest ecosystem, Terraform is still fine. And if HCL makes you want to throw your laptop, Pulumi lets you write infrastructure in real programming languages — I compared it head-to-head in Pulumi vs Terraform.

---

So Why Do Teams Use Both?

Now the part that makes the “vs” collapse entirely. On a real project, the two form a pipeline with a clean handoff:

1. Terraform provisions. It stands up the servers, the network, the load balancer, the DNS. When it finishes, you have running-but-empty boxes with IPs.
2. Ansible configures. It takes those IPs, SSHes in, installs your software, drops your configs, starts your services. Now the boxes actually do something.

Terraform makes the box; Ansible sets it up. That’s not a compromise — it’s the standard playbook at most companies running their own servers, each tool used for exactly the layer it’s best at. Some teams even hand Terraform’s output (the fresh server IPs) straight to Ansible as its inventory, so the whole thing runs as one flow.

There is overlap at the edges — Terraform can run scripts on a box, Ansible can create some cloud resources — but using either off its home layer is fighting the tool. Right layer, right tool. Don’t get cute.

---

The Broken Engineer Verdict: You Need Neither Yet

Here’s the part the tutorials never say out loud, because both IBM and every DevOps course want you inside these tools.

If you’re a solo founder in 2026, you almost certainly need neither Terraform nor Ansible. Not yet.

Ask the honest question before “which one”: how much infrastructure do I actually run? If your stack is Vercel for the frontend, Railway or Fly.io for the backend, and Neon for Postgres — the answer is basically zero. Terraform provisions infrastructure, but you have no VPC to stand up, no fleet, no IAM policies to describe; your platforms already are your infrastructure layer, hidden behind a git push. And Ansible configures servers, but you don’t have a server — you never SSH into anything. One tool builds a house you’re not building; the other furnishes a house you don’t own.

They earn their keep the moment you have sprawl — dozens of cloud resources on AWS, a fleet of VMs on DigitalOcean, multiple environments that must stay identical, a team reviewing infra changes in pull requests. That’s a good problem — it usually means real revenue. It is not a $0 MRR problem.

I reached for both in 2023 and 2024 for the same broken reason I reached for Kubernetes: I manufactured an enterprise problem so I could learn the enterprise tool. I gave a zero-user redirect service a cluster, then Terraform to build imaginary infrastructure, then Ansible to configure servers I didn’t own. Classic Broken Engineer theatre. The learning was real — I can read a playbook and an HCL file now — but if I’d just shipped Clickly to Railway like a sane person, there’d have been nothing to provision and nothing to configure.

---

The Bottom Line

Terraform and Ansible were never fighting. Terraform is declarative, keeps state, and provisions the infrastructure — it builds the box. Ansible is procedural, agentless, stateless, and configures what runs on it — it sets the box up. Real teams use both, in that order, because they solve different halves of the same job. In 2026 they even share a parent company in IBM, which should end the rivalry framing for good.

But the deepest lesson isn’t the comparison — it’s the layer. Both tools live below your product, on machines you own and operate. Managed platforms exist so you don’t have to live down there until you’ve earned the right to. The best provisioning code is the code Vercel already ran for you; the best configuration management is the server Railway set up so you never saw it.

Learn these the day you’re drowning in cloud consoles and SSH sessions — not before, to feel like a real engineer. I learned them to feel like a real engineer, for a product with no users. Don’t be like me. (Still assembling the cheap stack that makes all of this unnecessary? Start with the broke solopreneur’s survival guide and where I actually deploy.)

This is the Broken Engineer Guide. I over-engineer everything, fail at business, and share the scars so you can skip a few. Go build something that has neither a state file nor a server to configure yet.