Pulumi vs Terraform: The IaC Showdown Has a New Chapter

Infrastructure as Code has been the bedrock of modern DevOps for over a decade. HashiCorp's Terraform dominated the space with its elegant HCL language and massive provider ecosystem. But Pulumi has been steadily gaining ground, offering a fundamentally different approach: write infrastructure in real programming languages like TypeScript, Python, Go, and C#. With Pulumi's recent "do" feature for direct resource operations and ongoing updates across both platforms, 2026 is shaping up to be the year this comparison truly matters. Let's break down where each stands today.

The Core Philosophy Difference

Terraform uses HashiCorp Configuration Language (HCL), a declarative domain-specific language designed specifically for describing infrastructure state. You declare what you want, and Terraform figures out how to get there. Pulumi takes the opposite approach: it's imperative. You write actual code that provisions resources through well-maintained SDKs. The difference matters more than most engineers realize.

With HCL, you describe your desired end state in a configuration file. Terraform computes a plan showing what changes are needed and applies them. With Pulumi, you write functions that call APIs to create resources imperatively — the platform tracks state behind the scenes just like Terraform does, but your authoring experience is that of writing code.

Language Support: Where Pulumi Wins

This is Pulumi's most compelling advantage. If your team already knows TypeScript, you can write infrastructure in TypeScript and leverage all the patterns, types, and libraries you already use. Consider a typical AWS Lambda deployment:

// Pulumi with TypeScript
import * as pulumi from "@pulumi/pulumi";
import * as aws from "@pulumi/aws";

const lambda = new aws.lambda.Function("my-function", {
  runtime: "nodejs20.x",
  handler: "index.handler",
  code: new pulumi.asset.FileArchive("./src"),
  environment: {
    variables: {
      DB_HOST: db.endpoint,
      CACHE_TTL: "300"
    }
  }
});

export const lambdaArn = lambda.arn;

Compare that to Terraform's equivalent:

# Terraform HCL
resource "aws_lambda_function" "my_function" {
  runtime      = "nodejs20.x"
  handler      = "index.handler"
  filename     = "lambda.zip"
  function_name = "my-function"

  environment {
    variables = {
      DB_HOST   = aws_db_instance.main.endpoint
      CACHE_TTL = "300"
    }
  }
}

The Pulumi version gives you full IntelliSense, compile-time type checking, and the ability to reuse existing npm packages. The Terraform version is clean but limited to what HCL can express natively. For complex infrastructure logic — loops, conditionals, dynamic configurations — Pulumi's programming language approach scales much better.

Provider Ecosystem: Where Terraform Still Leads

Terraform has over 2,400 providers built by HashiCorp and the community. It is the de facto standard for multi-cloud infrastructure descriptions. Pulumi supports major cloud providers including AWS, Azure, Google Cloud, Kubernetes, and Cloudflare, but its ecosystem is smaller — perhaps 300+ providers. For most common use cases this covers everything you need, but edge cases and niche providers still favor Terraform.

However, Pulumi's cross-cloud approach has improved dramatically. Their native cloud providers (AWS Cloud Control, Azure Native, Google Cloud Native) generate directly from upstream API schemas, meaning new resource types land faster than waiting for hand-authored provider releases. This is a significant quality-of-life improvement that was called out in recent Pulumi documentation updates.

The New Game Changer: Pulumi "do"

Pulumi recently introduced "do" — a direct resource operations feature that provides a consistent command structure across every cloud provider. The pattern is straightforward: pulumi do <package:module:type> <operation>. Whether you're managing AWS instances, Azure VMs, Kubernetes pods, or Cloudflare DNS records, the same command syntax applies.

This matters because it reduces context switching. Instead of learning provider-specific Terraform resource types and their unique attributes, you work with a unified interface that mirrors each cloud's native API structure. For teams managing infrastructure across AWS, Azure, and GCP simultaneously, this consistency is genuinely valuable.

State Management: Both Have Maturesd

Both platforms use state files to track what exists in your cloud accounts. Terraform supports local and remote backends (S3, GCS, Consul, etc.). Pulumi offers its own managed service with free tier support plus S3 and other backends. Both handle concurrent access, encryption, and versioning competently now — this is no longer a meaningful differentiator.

Migration Path: Terraform to Pulumi

If you're currently on Terraform, migration is easier than ever. Pulumi provides built-in conversion tools for both YAML manifests and existing Terraform HCL + state files. The pulumi convert command reads your Terraform configuration and generates equivalent code in your chosen language. It won't be perfect — you'll still need to review and adjust the output — but it gets you 80% of the way there.

When to Choose Each

Pick Terraform when:

• Your team prefers declarative configuration over code
• You need a highly specialized or niche cloud provider
• Your organization has invested heavily in the Terraform ecosystem (modules, policy-as-code tools like Sentinel)
• You value the largest possible community and third-party integration base

Pick Pulumi when:

• Your team already uses TypeScript, Python, or Go and wants to reuse that knowledge
• You need complex logic in your infrastructure (loops, conditionals, dynamic configurations)
• Cross-cloud consistency matters more than niche provider coverage
• You want code review, testing, and CI/CD for your infrastructure just like application code

The Verdict

In 2026, the Terraform vs Pulumi question is no longer about which tool works — both are production-ready at scale. It's about which workflow fits your team. Pulumi's programming-language approach and its new "do" feature make it increasingly compelling for engineering teams that want infrastructure to feel like application code. Terraform's maturity, ecosystem breadth, and declarative simplicity remain strong reasons to stay put.

The real winner in this comparison is the engineer who picks the tool that matches their team's strengths and moves fast. Both platforms have evolved significantly, and the competition between them benefits everyone building modern infrastructure.