What About Chef and Puppet in a Terraform World?

Terraform took over conversations about infrastructure pretty quickly. Write some HCL, run terraform apply, and your cloud resources appear. Clean, predictable, versioned.

So where does that leave tools like Chef and Puppet?

If you’ve worked in DevOps long enough, you’ve probably heard someone say: “We don’t need Chef anymore, we use Terraform now.” That’s not entirely wrong—but it’s definitely incomplete.

Different layers, different jobs

Here’s the key idea that clears up most confusion:

• Terraform manages infrastructure
• Chef and Puppet manage configuration inside that infrastructure

Terraform provisions things like:

• EC2 instances
• VPCs and subnets
• Load balancers
• Databases

Chef and Puppet step in after the machine exists and handle:

• Installing packages
• Configuring services
• Managing users and permissions
• Keeping systems in a desired state

Think of it like this: Terraform builds the house. Chef and Puppet arrange the furniture and keep everything in place.

A quick example to make it concrete

Let’s say you want a web server.

Terraform handles this part

1resource "aws_instance" "web" {
2  ami           = "ami-0c55b159cbfafe1f0"
3  instance_type = "t2.micro"
4
5  tags = {
6    Name = "web-server"
7  }
8}

This gives you a running EC2 instance. But it’s just a plain machine.

Chef or Puppet handles what comes next

With Chef, you might define a recipe:

1package 'nginx' do
2  action :install
3end
4
5service 'nginx' do
6  action [:enable, :start]
7end

Now your instance isn’t just running—it’s configured as a web server.

Why Terraform didn’t replace Chef and Puppet

Terraform is declarative, but it’s focused on resource provisioning, not deep system configuration.

Here’s where Chef and Puppet still shine:

• State enforcement: If someone changes a config manually, they revert it
• Long-running nodes: Persistent servers need ongoing configuration management
• Complex system setups: Multi-step software installations and dependencies

Terraform, on the other hand, is not designed to continuously enforce system state inside a machine.

But the landscape has changed

Here’s where things get interesting.

The rise of:

• Containers (Docker)
• Immutable infrastructure
• Kubernetes

…has reduced the need for tools like Chef and Puppet in many environments.

Instead of configuring servers after launch, teams now:

• Build pre-configured images (AMIs or containers)
• Deploy them as-is
• Replace instead of mutate

This shifts the workflow from “configure after provisioning” to “deploy ready-to-run artifacts.”

So do you still need Chef or Puppet?

The honest answer: it depends on your architecture.

You probably don’t need them if:

• You use containers for everything
• Your infrastructure is immutable
• You rebuild instead of patching servers

You still benefit from them if:

• You manage long-lived VMs
• You run legacy systems
• You need strict configuration enforcement

A lot of enterprises still fall into the second category.

How teams combine Terraform with Chef or Puppet

In real-world setups, these tools are often used together rather than replaced.

A common workflow looks like this:

1. Terraform provisions infrastructure
2. Instances boot with a bootstrap script
3. Chef or Puppet agent registers with a server
4. Configuration is applied automatically

Here’s a simplified Terraform example using user data:

1resource "aws_instance" "app" {
2  ami           = "ami-123456"
3  instance_type = "t2.micro"
4
5  user_data = <<-EOF
6              #!/bin/bash
7              curl -L https://omnitruck.chef.io/install.sh | bash
8              chef-client
9              EOF
10}

This bridges the gap between provisioning and configuration.

Chef vs Puppet: quick perspective

If you're choosing between the two (and not replacing them):

• Chef feels more like programming (Ruby-based DSL)
• Puppet is more declarative and policy-driven

Both are mature, stable, and widely used in enterprise environments. The choice often comes down to team familiarity rather than capability.

A common mistake developers make

One trap is trying to force Terraform to do configuration management.

You’ll see things like:

• Long, complex user_data scripts
• Provisioners running shell commands

This works for small setups, but it becomes brittle fast.

Terraform provisioners are intentionally limited. They’re not meant to replace configuration management tools.

Where things are heading

The industry is slowly moving toward:

• Terraform for infrastructure
• Containers for application packaging
• Kubernetes for orchestration

In this model, Chef and Puppet become less central—but not obsolete.

They still play a role in:

• Hybrid environments
• On-prem systems
• Compliance-heavy setups

Bottom line

Terraform didn’t kill Chef and Puppet—it just changed where they fit.

If you’re building modern, container-first systems, you might never touch them. But if you’re dealing with real-world infrastructure (especially outside greenfield projects), understanding configuration management is still valuable.

The smartest approach isn’t picking one tool over another—it’s knowing which layer each tool is responsible for and using them accordingly.