Terraform vs Pulumi vs Ansible: IaC for small teams

You're a team of three engineers. One of you just broke staging by running a script manually. Nobody knows what the current state of infra actually is. IaC is the obvious fix — but Terraform, Pulumi, and Ansible all claim to solve this. Which one?

The short answer: they're not the same kind of tool, and the right choice depends on your team's profile more than the tools' feature lists.

What each tool actually does

It's worth being precise about categories because "IaC" gets used too loosely:

• Terraform (HashiCorp, now BSL licensed): declarative, state-file-based cloud provisioning. You describe desired state; Terraform computes the diff and applies it.
• Pulumi: same concept as Terraform, but you write real code (Python, Go, TypeScript) instead of HCL.
• Ansible: imperative, agentless configuration management. Strong for day-2 ops (installing packages, configuring services), weaker for provisioning.

These aren't identical tools competing for the same niche.

When Ansible makes sense — and when it doesn't

Ansible is solid for: configuring existing servers, deploying applications, running ordered multi-step procedures across a fleet.

It's awkward for: managing cloud resources from scratch. The modules exist (for EC2, VPCs, RDS), but state management is painful. Ansible doesn't track what it created — each run answers "did this task succeed?", not "does this resource still exist?". You end up with orphaned resources and no clear inventory.

For a small team provisioning cloud infra, Ansible alone isn't sufficient. The pattern that actually works: provision with Terraform, configure with Ansible.

# playbook.yml — configure a Python app on a freshly provisioned EC2 instance
- name: Deploy Python app
  hosts: web
  become: yes
  tasks:
    - name: Install system dependencies
      apt:
        name: [python3, python3-pip, nginx]
        state: present
        update_cache: yes

    - name: Deploy application files
      copy:
        src: ./app/
        dest: /opt/myapp/
        owner: www-data

    - name: Install Python requirements
      pip:
        requirements: /opt/myapp/requirements.txt
        executable: pip3

    - name: Enable and start service
      systemd:
        name: myapp
        state: started
        enabled: yes

This works well. But you need Terraform or Pulumi to create that instance in the first place.

Terraform: the safe default

Terraform has been the standard for cloud provisioning for years. HCL is learnable in a day, the provider ecosystem covers AWS, GCP, Azure, Cloudflare, GitHub, Datadog, and hundreds more. The plan/apply workflow gives you an explicit diff to review before any change lands.

For a small team, the main advantages:

• Anyone can read and write HCL without a deep programming background
• terraform plan output is reviewable in PRs — non-engineers can spot obvious regressions
• State locking via S3 + DynamoDB prevents concurrent applies from corrupting state
• The BSL license change only affects vendors building Terraform-as-a-service; internal use remains free

The friction:

• HCL is not a real programming language. Complex logic via for_each, dynamic blocks, and conditionals becomes unwieldy at scale
• No native test framework — you need Terratest or heavy terraform validate discipline
• State drift is a real burden: manual cloud console changes require terraform import or state rm

# main.tf — minimal VPC + EC2 for a Go API on AWS
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags       = { Name = "main" }
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "eu-west-1a"
}

resource "aws_security_group" "api" {
  name   = "api-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 8080
    to_port     = 8080
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_instance" "api" {
  ami                    = "ami-0c55b159cbfafe1f0"
  instance_type          = "t3.small"
  subnet_id              = aws_subnet.public.id
  vpc_security_group_ids = [aws_security_group.api.id]
  tags                   = { Name = "go-api" }
}

Readable, reviewable, and straightforward for any team member — including whoever joined last month.

Pulumi: real code, real tradeoffs

Pulumi replaces HCL with actual programming languages. The same stack in Python:

import pulumi
import pulumi_aws as aws

vpc = aws.ec2.Vpc("main",
    cidr_block="10.0.0.0/16",
    tags={"Name": "main"}
)

subnet = aws.ec2.Subnet("public",
    vpc_id=vpc.id,
    cidr_block="10.0.1.0/24",
    availability_zone="eu-west-1a"
)

sg = aws.ec2.SecurityGroup("api-sg",
    vpc_id=vpc.id,
    ingress=[{
        "from_port": 8080, "to_port": 8080,
        "protocol": "tcp", "cidr_blocks": ["0.0.0.0/0"]
    }],
    egress=[{
        "from_port": 0, "to_port": 0,
        "protocol": "-1", "cidr_blocks": ["0.0.0.0/0"]
    }]
)

instance = aws.ec2.Instance("go-api",
    ami="ami-0c55b159cbfafe1f0",
    instance_type="t3.small",
    subnet_id=subnet.id,
    vpc_security_group_ids=[sg.id],
    tags={"Name": "go-api"}
)

pulumi.export("instance_id", instance.id)

The real appeal: you can loop over a list of environments without count gymnastics, write unit tests with pytest, reuse Python functions, and import your own internal libraries. For infra with 10+ environments or heavily dynamic configuration, Pulumi's expressiveness is a genuine win.

The tradeoffs:

• State goes to Pulumi Cloud by default — there's a free tier, but self-hosting requires more setup than Terraform's S3 backend
• Steeper onboarding: new team members need to know the language and Pulumi's async resource graph model. Debugging Output[T] types is not obvious
• Smaller community: Stack Overflow coverage and available modules are thinner than Terraform's

Practical decision tree for small teams

Use Ansible when you're configuring existing servers, not provisioning from scratch.

Use Terraform when:

• Your team has mixed backgrounds — not everyone writes Python or Go fluently
• Your infra is relatively stable: fewer than five environments, no heavy dynamic resource generation
• You want the largest provider ecosystem and the most community resources

Use Pulumi when:

• Your team is developer-heavy and HCL feels like a cognitive tax
• You need real programming constructs: dynamic loops, proper unit tests, shared libraries across stacks
• You're comfortable with Pulumi Cloud pricing or willing to configure a self-hosted state backend

For most teams under five engineers, Terraform is the right starting point. The plan/apply review workflow fits naturally into PRs, HCL is fast to learn, and you won't hit its limits until your infra grows significantly.

One thing that matters regardless of tool: gate every apply behind CI/CD with mandatory code review on infra changes. A misconfiguration merged without review is where incidents start. We maintain a security checklist for IaC pipelines covering state file access control, least-privilege IAM for CI runners, and safe secrets handling in both Terraform and Pulumi.

The takeaway

Terraform, Pulumi, and Ansible aren't direct competitors — they solve overlapping but distinct problems. Ansible handles configuration; Terraform and Pulumi handle provisioning. Between the two provisioning tools, Terraform wins on simplicity and ecosystem breadth; Pulumi wins when your infra logic outgrows what HCL can express cleanly.

Pick based on your team's actual skills and infra complexity, not on which tool had the best talk at the last DevOps conference.

---

I run AYI NEDJIMI Consultants, a cybersecurity consulting firm. We publish free security hardening checklists — PDF and Excel.