Overview

Terraform and Pulumi solve the same problem from opposite directions. Both let you declare cloud infrastructure as code, plan changes before applying them, and track the resulting resources in state. The split is in authoring: Terraform gives you HCL, a purpose-built configuration language, while Pulumi runs your infrastructure as a program written in Python, TypeScript, Go, C#, or Java.

That single decision ripples through everything else, including how you express loops and conditionals, how you write tests, who you can hire, and how you reason about an apply. Terraform (now at the 1.9+ line) has the larger install base and the deeper ecosystem. Pulumi appeals to teams that already live in a general-purpose language and want their infrastructure to use the same tooling as their applications.

Neither tool is a clear winner for every team. The right pick depends on the skills you already have and how much logic your infrastructure actually needs.

Language and Authoring Experience

Terraform configuration is declarative HCL. You describe the resources you want, and Terraform figures out the order to create them by building a dependency graph from references between resources.

resource "aws_s3_bucket" "logs" {
 bucket = "acme-app-logs"
}

resource "aws_s3_bucket_versioning" "logs" {
 bucket = aws_s3_bucket.logs.id
 versioning_configuration {
 status = "Enabled"
 }
}

HCL stays readable for straightforward infrastructure, and the constrained syntax keeps configurations consistent across a team. The friction appears once you need real logic. count, for_each, dynamic blocks, and the ternary operator cover a lot of ground, but they get awkward fast when the conditions stack up.

Pulumi expresses the same resources as objects in a language you already know, with the same provider coverage documented in the Pulumi registry:

import pulumi_aws as aws

logs = aws.s3.BucketV2("logs", bucket="acme-app-logs")

aws.s3.BucketVersioning(
 "logs-versioning",
 bucket=logs.id,
 versioning_configuration={"status": "Enabled"},
)

Because it is ordinary Python or TypeScript, you get native loops, functions, classes, and your editor's full IDE support: autocomplete, type checking, and inline docs. Complex branching that would mean nested dynamic blocks in HCL becomes a plain if statement. The cost is that the same generality lets teams write infrastructure that is harder to follow, since there are many ways to produce the same result.

State Management

Both tools track what they have provisioned in a state file and use it to compute a diff on the next run. The operational details differ.

Terraform stores state in a backend you configure: S3, Google Cloud Storage, Azure Blob, or HCP Terraform (formerly Terraform Cloud). With a self-managed backend you own locking, encryption, and access control. S3 with native state locking, or DynamoDB on older setups, is the common pattern.

terraform {
 backend "s3" {
 bucket = "acme-tfstate"
 key = "prod/network.tfstate"
 region = "us-east-1"
 use_lockfile = true
 }
}

Pulumi defaults to its managed service, Pulumi Cloud, which handles state storage, locking, and a change history out of the box and is free for individuals. You can also point Pulumi at a self-managed backend such as S3, Azure Blob, GCS, or the local filesystem. One practical difference: Pulumi encrypts secret values inside the state file by default using a per-stack encryption key, while Terraform stores values in plaintext within state, so protecting the backend itself is non-negotiable.

For day-to-day work the experience is similar. The contrast is mostly about defaults: Terraform expects you to stand up and secure a backend, whereas Pulumi gives you a working managed backend immediately and lets you opt out. If you self-manage Terraform state, locking deserves real attention as the team grows; see our guide to Terraform state locking.

Core Workflow Commands

The day-to-day loop is the same shape in both tools: preview a diff, then apply it.

# Terraform
terraform init
terraform plan -out=tfplan
terraform apply tfplan

# Pulumi
pulumi preview
pulumi up

Terraform separates plan and apply into two artifacts, which suits a pull request gate where the saved plan is reviewed before it runs. Pulumi folds preview and apply into pulumi up, with pulumi preview available when you want the diff alone.

Provider Ecosystem and Modules

Terraform's provider ecosystem is its strongest asset. The Registry hosts thousands of providers and a large catalog of reusable modules, many maintained by the cloud vendors themselves. For almost any service you want to manage, a mature, well-documented provider already exists.

Pulumi reaches the same breadth by bridging Terraform providers, so the underlying coverage is comparable. On top of that, Pulumi ships native providers for the major clouds that track the upstream APIs closely. Reuse in Pulumi happens through ComponentResources, which are just classes or functions in your language, so you package and version them like any other library through pip, npm, or Go modules rather than through a separate module registry.

A note on the registry split: after HashiCorp's license change, the OpenTofu project forked Terraform and runs its own provider registry. If you adopt OpenTofu as a drop-in replacement, you draw from that registry instead, though it mirrors most of the same providers.

Testing and CI/CD

Testing is where Pulumi's language choice pays off most clearly. Because your infrastructure is a normal program, you test it with the frameworks you already use: pytest for Python, Jest for TypeScript, or Go's testing package. You can write fast unit tests with mocked resources and full integration tests that provision real infrastructure and tear it down.

import pulumi

@pulumi.runtime.test
def test_bucket_has_name():
 def check(args):
 assert args[0] is not None
 return logs.bucket.apply(check)

Terraform added a native terraform test framework that runs .tftest.hcl files against your configuration, plus checks and assertions inside config. It covers plan-level and applied assertions and has improved steadily, but it is narrower than a general test framework, and many teams still reach for Terratest (Go) or policy-as-code tools like OPA, Sentinel, or Checkov. For a deeper look at structuring those layers, see Terraform testing best practices.

In CI/CD, both fit the standard plan-then-apply gate. Terraform's plan output is a familiar artifact for pull request review. Pulumi's pulumi preview plays the same role, and because the program is code, you can also lint and type-check it in CI before any cloud call happens.

Learning Curve and Hiring

HCL is quick to pick up. An engineer with no prior exposure can read and write basic Terraform in a day, and the constrained syntax limits how badly a configuration can go wrong. That low floor is a real advantage for teams with mixed backgrounds or heavy operations rather than software focus.

Pulumi's learning curve depends entirely on the language. A team already fluent in TypeScript or Python is productive immediately and brings existing habits with them. A team without that background has to learn both Pulumi's model and the host language, which is a steeper climb.

Hiring follows the same logic. Terraform skills are widespread, and the volume of tutorials, Stack Overflow answers, and example modules is much larger, so unblocking a stuck engineer is usually faster. Pulumi has a smaller but growing community, and you are effectively hiring for the language plus infrastructure knowledge rather than a single dedicated skill.

Licensing

Licensing changed the conversation in August 2023. HashiCorp moved Terraform from the MPL 2.0 open-source license to the Business Source License (BSL) 1.1. Terraform stays free for the vast majority of users, but the BSL restricts using it to build a competing commercial product, and the source no longer meets the open-source definition.

That change prompted the community to fork the last MPL-licensed version into OpenTofu, now governed by the Linux Foundation and still MPL 2.0. OpenTofu is largely a drop-in alternative to the Terraform CLI for teams that need a fully open-source license.

Pulumi is Apache 2.0, a permissive open-source license, with no equivalent usage restriction. If license terms are a hard requirement for your organization, that distinction matters, though for most teams the practical day-to-day difference is small.

When to Choose Each

Reach for Terraform when your infrastructure is mostly declarative, when you want the deepest provider and module ecosystem, and when easy hiring and abundant community answers matter more than language flexibility. Its low learning curve makes it a strong default for teams that are not primarily software engineers, and the wider talent pool reduces ramp-up risk.

Reach for Pulumi when your team already lives in Python, TypeScript, or Go and wants infrastructure in the same language and tooling as the application. It shines when you need genuine programming constructs, loops, conditionals, shared abstractions, that would be painful in HCL, and when first-class unit testing is a priority. The permissive Apache 2.0 license is a bonus for organizations sensitive to the BSL terms.

For a team starting fresh with no strong language preference, Terraform's larger ecosystem and easier hiring make it the lower-risk choice. Pulumi earns its place when the infrastructure carries real logic or your engineers would rather write code than configuration.