Terraform vs Pulumi in 2026: Which One Should You Pick for a Greenfield Project?

I've used Terraform for three years and Pulumi for two. I have production infrastructure running on both. My take: they're both good tools, and the tool choice is far less important than the workflows and conventions you build around whichever one you pick. That said — you asked which one to pick for a greenfield project, so here's my honest answer.

The state of each tool in 2026

Terraform(now OpenTofu for the open-source fork, Terraform for the HashiCorp enterprise version) is the incumbent. The provider ecosystem is unmatched — if a cloud service exists, there's a Terraform provider for it, and it's probably well-maintained. The HashiCorp Registry has 3,000+ providers. HCL (HashiCorp Configuration Language) is opinionated and limited by design — you can't write a for loop that generates arbitrary resources based on runtime logic, and that constraint turns out to be mostly a feature.

Pulumi lets you write infrastructure in TypeScript, Python, Go, Java, or .NET. Your infrastructure is a real program — you can use loops, conditionals, functions, testing frameworks, and every other language feature you already know. Pulumi has a growing provider ecosystem (most are wrappers around Terraform providers under the hood), a solid state backend, and first-class support for testing infrastructure logic.

When Terraform wins

You need breadth of providers.For anything beyond the major clouds, Terraform's provider ecosystem is deeper. If you're using Cloudflare, Datadog, PagerDuty, Vault, and three SaaS tools, Terraform has stable, well-documented providers for all of them. Pulumi often wraps Terraform providers, which works but sometimes lags on updates.

Your team isn't all software engineers. DevOps engineers, SREs, and sysadmins who are comfortable with YAML and shell scripting often find HCL more approachable than a real programming language for infrastructure work. The explicit, declarative nature of HCL means you can read a Terraform file and know what it will do without understanding control flow.

You want a large community and existing examples. Any infrastructure pattern you want to implement — VPC design, EKS cluster, RDS setup — has been done in Terraform, documented, and probably open-sourced. The Terraform Registry module ecosystem is huge.

When Pulumi wins

You need to test your infrastructure logic.Pulumi supports unit and integration testing using standard testing frameworks. You can write a test that verifies your VPC doesn't have public subnets in production, or that every resource has required tags. Terraform's testing story (terraform test) is improving but still limited compared to what you can do with a real testing framework.

Your infrastructure is highly dynamic.If you're generating dozens of similar resources based on external data (e.g., creating one Route53 record per entry in a config file, or one IAM role per team in a list), Pulumi's programming model is much cleaner than Terraform's for_each and dynamic blocks.

Your team is primarily software engineers. If everyone already knows TypeScript and the infrastructure team is the same people as the application team, Pulumi removes the context-switch into HCL. Testing infrastructure the same way you test application code is a real workflow win.

The one thing that matters more than the tool

I've seen terrible Terraform codebases and terrible Pulumi codebases. The tool isn't the variable. The pattern I see in bad infrastructure code, regardless of tool:

• No module or component abstraction — everything in one flat directory
• State stored locally (or worse, not at all)
• No CI/CD for infrastructure changes — people run apply from their laptops
• No code review for infrastructure changes
• Hardcoded values instead of variables
• No drift detection

These problems exist independently of whether you picked Terraform or Pulumi. A team with good IaC conventions will succeed with either. A team without them will fail with both.

My recommendation for greenfield in 2026

Default to Terraform (OpenTofu)unless you have a specific reason not to. The ecosystem maturity, the community, and the amount of existing reference material give you a faster start. If you're on AWS with a standard setup, the hashicorp/aws provider is excellent and will cover everything you need.

Consider Pulumi if:your team is software engineers who write TypeScript or Python daily, you need serious infrastructure testing, or your infrastructure is genuinely dynamic in ways that Terraform's for_each handles awkwardly.

Whatever you pick, invest in the workflow: remote state with locking (S3 + DynamoDB for Terraform, Pulumi Cloud or self-hosted for Pulumi), CI/CD with plan on PR and apply on merge, consistent module structure, and mandatory code review for infrastructure changes. That's what makes the difference between infrastructure you trust and infrastructure you're afraid to touch.