Pulumi vs Terraform: choosing your IaC tool

Real programming languages vs HCL: how state handling, unit testing, blast radius, and your team's skills should decide between Pulumi and Terraform.

Both Pulumi and Terraform solve the same core problem: declarative infrastructure with a plan/apply loop and a state file that maps code to cloud ids. The difference is the language layer. Terraform uses HCL — a DSL tuned for graphs of resources. Pulumi uses TypeScript, Python, Go, or C# — general-purpose languages with loops, classes, and unit tests your team already knows. Neither choice removes the hard parts: state locking, secret handling, module boundaries, and review culture.

This note puts the same S3 bucket side by side in both tools, compares state and testing ergonomics, and gives a decision framework based on team skills — not vendor marketing. Explore Terraform and Pulumi courses if you want hands-on depth in both before committing org-wide.

The same bucket in Terraform

Terraform expresses resources as HCL blocks. The graph is explicit; loops use for_each and count. Plans are widely understood by platform reviewers who may never write application code.

Terraform's module registry, terraform test, and widespread hiring pool are real advantages. State backends (S3, Terraform Cloud) are battle-tested. Teams that already standardized on HCL rarely benefit from rewriting working modules in Python just for loops — for_each covers most repetition.

resource "aws_s3_bucket" "app" {
  bucket = "acme-app-data"
}
 
resource "aws_s3_bucket_versioning" "app" {
  bucket = aws_s3_bucket.app.id
  versioning_configuration {
    status = "Enabled"
  }
}
 
resource "aws_s3_bucket_server_side_encryption_configuration" "app" {
  bucket = aws_s3_bucket.app.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

The same bucket in Pulumi (Python)

Pulumi wraps the same provider APIs behind SDK classes. You can extract functions, share types, and run ordinary unit tests against helper logic — though integration tests still hit the cloud or use mocks.

Pulumi shines when platform code lives beside application code — same repo, same PR reviewers, shared libraries for naming and tagging. Pulumi Automation API drives self-service infra from internal portals. State can live in Pulumi Cloud or self-managed S3-compatible backends; the locking story is comparable to Terraform when configured correctly.

import pulumi
import pulumi_aws as aws
 
bucket = aws.s3.Bucket(
    "app",
    bucket="acme-app-data",
)
 
aws.s3.BucketVersioning(
    "app-versioning",
    bucket=bucket.id,
    versioning_configuration=aws.s3.BucketVersioningVersioningConfigurationArgs(
        status="Enabled",
    ),
)
 
aws.s3.BucketServerSideEncryptionConfiguration(
    "app-sse",
    bucket=bucket.id,
    rules=[aws.s3.BucketServerSideEncryptionConfigurationRuleArgs(
        apply_server_side_encryption_by_default=(
            aws.s3.BucketServerSideEncryptionConfigurationRuleApplyServerSideEncryptionByDefaultArgs(
                sse_algorithm="AES256",
            )
        ),
    )],
)

Where this goes next

Whichever tool you pick, invest in remote state, policy scanning (Checkov works on both Terraform and Pulumi YAML/converted HCL), and CI gates that block apply on drift. Many orgs standardize on one primary IaC and allow the other only in application teams that own their runtime. Compare hands-on in Pulumi and Terraform — the plan output and state story matter more than syntax sugar.

Migration between tools is expensive — export state, rewrite resources, re-import. Pick for the next five years of hiring and review culture, not a blog post. Both support policy-as-code, drift detection, and encrypted remote backends when configured properly.

Related posts