How to Choose an IaC Tool for Your Infrastructure

IaC tool choices are hard to reverse. You write modules, train your team, build CI/CD pipelines around your chosen tool — and switching costs accumulate quickly. It's worth thinking carefully before committing.

Here's the framework I'd use.

The constraint that narrows the field immediately

If you're AWS-only and your team writes TypeScript or Python: AWS CDK is worth serious consideration. It generates CloudFormation natively, you get full AWS API coverage on day zero, and your team uses a language they already know. No DSL to learn.

If you need to support multiple cloud providers: Terraform or OpenTofu. The provider ecosystem is unmatched. GCP, Azure, AWS, Kubernetes, Cloudflare, Datadog, GitHub — Terraform has providers for nearly everything. OpenTofu is the open source fork that diverged after HashiCorp's BSL license change; it's fully compatible with existing Terraform code and maintained by the Linux Foundation.

If your team is Kubernetes-native and thinks in YAML: Crossplane lets you manage cloud resources using Kubernetes-style CRDs. Your cloud infrastructure becomes just more YAML that kubectl can manage. Strong fit for platform engineering teams building on Kubernetes. Steeper learning curve if you're not already deep in Kubernetes.

If you need configuration management alongside infrastructure provisioning: Ansible. It's not purely IaC (it also handles software installation, configuration, OS-level tasks) but for teams that need to provision cloud resources and configure the servers that run on them, Ansible handles both in one tool.

If you want to write real programming logic: Pulumi lets you write infrastructure in TypeScript, Python, Go, C#, or Java. For-loops, functions, abstractions — you use the full language, not just a declarative config. Useful when your infrastructure has complex conditional logic that's awkward to express in HCL or YAML.

Terraform and HCL: the practical reality

Terraform is the safest choice for most teams, and not because it's the most technically elegant — it's not. It's safe because:

• The community is enormous. Most infrastructure patterns already have a Terraform module in the registry.
• Every cloud provider maintains an official Terraform provider.
• There are more engineers with Terraform experience on the job market than any other IaC tool.
• The tooling ecosystem is mature: Terragrunt for DRY configurations, Atlantis for GitOps workflows, Spacelift/env0 for enterprise management.

HCL (HashiCorp Configuration Language) has a learning curve but it's not steep. Most engineers are productive within a week or two.

The main Terraform frustration: state management. The state file tracks what Terraform thinks exists in your cloud. State conflicts in team environments, accidentally destroying infrastructure because state got out of sync, managing remote state — these are real operational concerns that don't exist in stateless approaches like AWS CDK.

OpenTofu: when to consider the fork

OpenTofu is worth choosing over Terraform if:

• Vendor lock-in risk concerns you (Terraform's BSL license restricts commercial use in some scenarios)
• You want an open source governance model
• You have existing Terraform code you want to continue using

It's not worth choosing over Terraform if:

• You need the latest provider versions (OpenTofu sometimes lags Terraform on provider updates)
• You need HashiCorp enterprise support
• Your team is already comfortable with Terraform and there's no license concern

For new projects in 2026, OpenTofu is a reasonable default if you want to stay fully open source. The compatibility with Terraform means you're not betting on an unproven ecosystem.

Pulumi: real programming vs. configuration

Pulumi's pitch is that real programming languages are more expressive than DSLs. For simple infrastructure, this is barely true — the difference between HCL and TypeScript for defining a VPC is minimal. For complex infrastructure, it's genuinely true: conditional resource creation, dynamic configurations, reusable components — these are awkward in HCL and natural in a real language.

The trade-off: Pulumi's state service (Pulumi Cloud) has a free tier but the enterprise features are paid. Self-hosting the state backend is possible but adds operational complexity. The community and module ecosystem is smaller than Terraform's.

Choose Pulumi if: your team is engineer-heavy and frustrated by HCL's limitations, or you have infrastructure logic complex enough that a real programming language actually helps.

Management platforms: Spacelift, Atlantis, env0

Once you have IaC running, you need something to run it in CI/CD. Three main options:

Atlantis — open source, self-hosted, runs terraform plan on every PR and requires approval before apply. Simple, reliable, free. The standard for teams that don't need enterprise features. Runs well as a Kubernetes deployment or a small VM.

Spacelift — enterprise IaC management platform with policy enforcement (OPA), drift detection, audit logs, SSO, and support for Terraform, OpenTofu, Pulumi, and Kubernetes. More expensive but significantly more capable than Atlantis for complex environments.

env0 — similar to Spacelift, with a stronger focus on cost visibility and governance. Popular in larger organizations that need IaC lifecycle management with compliance reporting.

For most teams, start with Atlantis. It covers the core GitOps IaC workflow at zero cost. Move to Spacelift or env0 when you need enterprise governance features.

Getting state management right

State management is where most Terraform operational problems start. Do this from day one:

• Use remote state — Terraform Cloud, S3 + DynamoDB locking, or GCS. Never keep state files locally or in git.
• Use workspaces carefully — or better, use separate state files per environment rather than Terraform workspaces, which have footguns around variable management.
• Lock state during operations — remote backends with locking prevent concurrent applies from corrupting state.
• Backup state — if you're using S3, enable versioning. You'll need it eventually.

Pulumi and AWS CDK manage state differently (Pulumi Cloud or self-hosted backend; CDK uses CloudFormation stacks), which removes some of the state management complexity but replaces it with other operational concerns.

Practical recommendation

For most teams in 2026:

1. Default to Terraform or OpenTofu unless a specific constraint points elsewhere
2. Use Atlantis for GitOps CI/CD integration from day one
3. Keep state in remote storage from the first deployment
4. Start with official modules from the Terraform Registry rather than writing everything from scratch
5. Use Terragrunt once your module structure gets complex enough to need DRY configurations across environments

If you're AWS-only and your team knows TypeScript: evaluate AWS CDK seriously — the developer experience is genuinely better and there's no state management overhead.

If you're Kubernetes-native: Crossplane is worth a serious look for cloud resource management, especially if you want to give application teams self-service infrastructure through Kubernetes.