Top 5 Infrastructure as Code Provisioning Tools of 2026: Terraform vs OpenTofu vs Pulumi vs CDK vs Ansible
The tools that actually provision your infrastructure, Terraform, OpenTofu, Pulumi, AWS CDK, and Ansible, compared on licensing, language, state management, and real production trade-offs. Not a scanner or policy-enforcement comparison.
Quick Comparison
| Platform | Best For | Language / Format | License | Pricing |
|---|---|---|---|---|
| Terraform | Multi-cloud provisioning at scale with the widest provider ecosystem | HCL (declarative DSL) | BSL v1.1 (source-available, converts to MPL 4 years after each release) | Open source to self-host; HCP Terraform free tier covers 500 managed resources, paid tiers above that |
| OpenTofu | Terraform-compatible provisioning without the BSL terms | HCL, Terraform-compatible | MPL 2.0 (Linux Foundation / CNCF) | Free and open source; no vendor managed-cloud arm from the project itself |
| Pulumi | Infrastructure written in a real programming language with existing test tooling | TypeScript, Python, Go, Java, .NET, plus YAML/HCL | Apache 2.0 (CLI and SDKs) | Free forever for individuals (500 deployment min/month); Team tier from 150,000 free Pulumi Cloud credits/month |
| AWS CDK | AWS-only teams who want typed constructs instead of hand-written CloudFormation | TypeScript, Python, Java, C#, Go | Apache 2.0 | Free and open source; you pay only for the AWS resources it provisions |
| Ansible | Configuring and patching hosts after something else provisions them | YAML playbooks (imperative, agentless) | GPLv3 (ansible-core); Automation Platform is commercial | ansible-core free; Red Hat Ansible Automation Platform is a paid subscription by managed node count |
Terraform
- Best For
- Multi-cloud provisioning at scale with the widest provider ecosystem
- Language / Format
- HCL (declarative DSL)
- License
- BSL v1.1 (source-available, converts to MPL 4 years after each release)
- Pricing
- Open source to self-host; HCP Terraform free tier covers 500 managed resources, paid tiers above that
OpenTofu
- Best For
- Terraform-compatible provisioning without the BSL terms
- Language / Format
- HCL, Terraform-compatible
- License
- MPL 2.0 (Linux Foundation / CNCF)
- Pricing
- Free and open source; no vendor managed-cloud arm from the project itself
Pulumi
- Best For
- Infrastructure written in a real programming language with existing test tooling
- Language / Format
- TypeScript, Python, Go, Java, .NET, plus YAML/HCL
- License
- Apache 2.0 (CLI and SDKs)
- Pricing
- Free forever for individuals (500 deployment min/month); Team tier from 150,000 free Pulumi Cloud credits/month
AWS CDK
- Best For
- AWS-only teams who want typed constructs instead of hand-written CloudFormation
- Language / Format
- TypeScript, Python, Java, C#, Go
- License
- Apache 2.0
- Pricing
- Free and open source; you pay only for the AWS resources it provisions
Ansible
- Best For
- Configuring and patching hosts after something else provisions them
- Language / Format
- YAML playbooks (imperative, agentless)
- License
- GPLv3 (ansible-core); Automation Platform is commercial
- Pricing
- ansible-core free; Red Hat Ansible Automation Platform is a paid subscription by managed node count
Terraform
Best OverallBest for: Multi-cloud provisioning teams that need the largest provider ecosystem and the biggest hiring pool
“Terraform is still the default choice for most teams provisioning infrastructure across more than one cloud, and that has not changed since HashiCorp moved it to the Business Source License in August 2023 or since IBM completed its acquisition of HashiCorp in February 2025. The provider registry, the module ecosystem, and the pool of engineers who already know HCL are larger than any competitor on this list, and the BSL does not restrict the normal case of running terraform apply against your own infrastructure. Pick it as the default unless the license itself, not just the code, is a problem for what you're building.”
Pros
- Largest provider and module registry of any IaC tool, with official and community providers for effectively every major cloud, SaaS platform, and on-prem system
- HCP Terraform's free tier covers up to 500 managed resources with state locking and remote state storage, no separate backend to run yourself
- Biggest hiring pool and largest body of existing modules, Stack Overflow answers, and internal company runbooks to draw from when something breaks at 2am
- Mature surrounding tooling: Terragrunt for DRY multi-environment configs, Atlantis and Spacelift for PR-based apply workflows, Terratest for automated testing
Cons
- BSL v1.1 forbids building a competing commercial offering on top of Terraform; each release only converts to MPL four years after it ships, so the binaries you run today stay source-available, not truly open source, for years
- No native state file encryption; protecting state at rest depends on your backend (S3 with SSE, Azure Blob encryption, etc.) rather than anything Terraform itself provides
- IBM now owns the roadmap. Feature and pricing decisions for HCP Terraform now run through IBM's enterprise sales motion rather than HashiCorp's original open-source-first culture
What the BSL Actually Restricts
HashiCorp's August 2023 license change moved Terraform from MPL 2.0 to Business Source License v1.1. The BSL's operative restriction targets organizations that would embed or resell Terraform as a competing commercial product, not organizations that run it against their own infrastructure. Each versioned release converts to MPL 2.0 automatically, but only four years after that specific release shipped, so there is no single date on which the whole project becomes MPL again; older releases convert on a rolling basis while the newest release you're likely running stays BSL for years. IBM's acquisition, completed in February 2025, has not changed the license terms, and public statements suggest IBM has no plan to relicense back to MPL.
Why Terraform Still Wins on Breadth
Terraform's provider registry is the deepest in the industry because it was first, and because OpenTofu, Pulumi, and other tools were built to be compatible with that same registry rather than build a competing one from scratch. For a platform team standing up infrastructure across AWS, Azure, GCP, Datadog, PagerDuty, and a dozen other SaaS tools in one state graph, Terraform (or a fork that reuses its providers) is still the practical starting point. That breadth, not the license, is what keeps Terraform at rank one on this list.
Open source (BSL v1.1) is free to self-host and run yourself. HCP Terraform's free tier covers up to 500 managed resources with one concurrent run; paid Standard and Plus tiers add per-resource and per-user pricing on top, with custom Enterprise pricing above that.
OpenTofu
Best Open SourceBest for: Teams that want Terraform's workflow and provider ecosystem without the BSL terms
“OpenTofu is the direct open-source answer to Terraform's 2023 license change: a Linux Foundation and CNCF-governed fork under MPL 2.0, compatible with existing Terraform configuration and state in the overwhelming majority of cases. It is not a rewrite or a reimagining, it is the same workflow with a different license and a governance model that no single vendor controls. The honest reason it's not rank one is adoption: most teams already running Terraform haven't switched, not because OpenTofu is worse, but because migrating a large existing state and CI pipeline for a license issue that doesn't affect their day-to-day usage is a hard sell to get prioritized.”
Pros
- MPL 2.0 licensed under Linux Foundation and CNCF governance, so the license and the roadmap aren't controlled by a single commercial vendor the way Terraform now is under IBM
- Compatible with most existing Terraform configurations and state files; migrating is typically swapping the terraform binary for tofu, with the state's terraform_version marker updating on first apply
- Ships client-side state encryption (AES-GCM, added in v1.7) as a first-class feature, something mainline Terraform has never shipped despite the request dating back to 2016
- Provider and module ecosystem largely inherited from Terraform's own registry via a compatible provider protocol, so you aren't starting from a thin catalog
Cons
- No managed-cloud arm from the OpenTofu project itself; teams that relied on Terraform Cloud's hosted state and run management need a third-party platform (Spacelift, env0, Scalr) for the equivalent
- Smaller job market specifically for OpenTofu experience compared to Terraform, even though the skills transfer almost completely
- New HashiCorp-authored provider features and some ecosystem tooling still land on Terraform first, with OpenTofu compatibility following after
What OpenTofu Actually Forked
OpenTofu started as OpenTF, a community response to the BSL announcement, and moved under the Linux Foundation before being accepted into the CNCF, which granted a special exception letting the project keep MPL 2.0 rather than forcing a switch to the CNCF's default Apache 2.0. The fork happened at the last MPL-licensed Terraform commit, and the project has since diverged with its own features, state encryption being the clearest example of something OpenTofu shipped that Terraform still hasn't.
The Real Migration Path
For most users, moving to OpenTofu is replacing the terraform binary with tofu and pointing existing scripts at it; module syntax and provider configuration are unchanged because OpenTofu deliberately maintains compatibility with Terraform's HCL and state format. The friction shows up in secondary tooling: CI pipeline scripts, Terraform Cloud-specific integrations, and any Sentinel policies, since Sentinel is proprietary to HashiCorp and doesn't run on OpenTofu. Teams heavily invested in HCP Terraform's paid enforcement layer have more to replace than teams running plain open-source Terraform with a self-managed backend.
Free and open source under MPL 2.0. There is no OpenTofu-branded managed cloud service; commercial platforms like Spacelift, env0, and Scalr add OpenTofu support at their own separate pricing.
Pulumi
Runner UpBest for: Engineering teams that want infrastructure defined in a real programming language with existing test and IDE tooling
“Pulumi lets you write infrastructure in TypeScript, Python, Go, Java, or C# instead of a purpose-built DSL, which means loops, conditionals, functions, and classes work exactly like they do in application code, and your existing test framework, linter, and IDE autocomplete apply without a separate plugin. It's the right pick for a software-engineering-heavy team that wants infrastructure code to look and behave like the rest of their codebase. It's rank three, not one, because that same flexibility is also where teams get into trouble.”
Pros
- Full general-purpose languages (TypeScript, Python, Go, Java, .NET) mean real loops, functions, and abstractions, not HCL's limited expression syntax, and your existing unit test framework works on infrastructure code without a bespoke test harness
- IDE support comes from the language itself: type checking, inline documentation, and refactoring tools in VS Code or any language-aware editor work the same way they do for application code
- Individual tier is free forever with 500 Pulumi Cloud deployment minutes per month and no credit card required to start
- Reaches the same underlying Terraform and OpenTofu provider ecosystem through bridged providers, so most cloud resources are available without Pulumi needing its own separate integration for each one
Cons
- Defaults to hosted Pulumi Cloud for state; self-hosting state to S3, GCS, or Azure Blob is supported but requires deliberate setup that teams often skip, which quietly reintroduces the vendor dependency some pick Pulumi to avoid
- Writing infrastructure in a Turing-complete language reintroduces application-code failure modes: unbounded loops, non-idempotent logic, and code review that requires understanding control flow instead of reading a flat resource diff
- Smaller hiring pool and far fewer existing example programs to copy from than Terraform's module ecosystem, for the same target resource
- Team-tier pricing is credit-based ($0.0005/credit after 150,000 free credits/month), which is harder to forecast at scale than Terraform's flat per-resource pricing
Real Languages, Real Trade-offs
Pulumi programs are ordinary code: a TypeScript for-loop that creates ten S3 buckets is a for-loop, not a count meta-argument bolted onto a resource block. That buys real abstraction (shared functions, classes, package imports from npm or PyPI) at the cost of infrastructure code being exactly as easy or hard to reason about as the rest of your codebase. Teams that already enforce strong code review and testing discipline on application code tend to extend that discipline to Pulumi programs without much friction. Teams without that discipline sometimes get infrastructure sprawl that's harder to audit than an equivalent Terraform plan.
State and the Bridged Provider Model
Pulumi's provider model wraps Terraform's own providers for the majority of cloud resources, so day-one coverage of AWS, Azure, and GCP resources is broad without Pulumi needing to write and maintain each integration independently. State defaults to Pulumi Cloud, which includes free encryption and history, but teams wanting to avoid a hosted dependency can point pulumi login at a self-managed backend, at the cost of losing some of the managed collaboration features.
Free forever for individuals, including 500 Pulumi Cloud deployment minutes per month. Team tier includes 150,000 free Pulumi Cloud credits per month with additional usage billed at $0.0005 per credit; custom Enterprise and Business Critical pricing above that. The CLI and providers are open source (Apache 2.0) regardless of which state backend you choose.
AWS CDK
Best Free OptionBest for: AWS-only teams that want typed infrastructure constructs without paying anything beyond the AWS resources themselves
“AWS CDK synthesizes TypeScript, Python, Java, C#, or Go code into CloudFormation templates and deploys through CloudFormation's own engine, which means it costs nothing beyond the AWS resources it provisions: no CLI paywall, no managed-service tier, no per-resource fee. For a team whose infrastructure lives entirely in AWS, CDK's L2 and L3 constructs remove a meaningful amount of CloudFormation boilerplate. The moment infrastructure needs to leave AWS, this tool stops being a candidate, by design, not as an oversight.”
Pros
- Genuinely free forever: CDK generates CloudFormation templates and AWS doesn't charge separately for CloudFormation, so there's no vendor SaaS layer, no per-resource fee, and no paid tier to eventually hit
- L2 and L3 constructs encode AWS best practices directly, for example a Bucket construct defaults to blocking public access and enabling encryption, cutting the boilerplate a hand-written CloudFormation template or a bare Terraform aws_s3_bucket resource requires to reach the same secure default
- Same real-language ergonomics as Pulumi (TypeScript, Python, Java, C#, Go), with tighter integration into existing AWS-native tooling like the SAM CLI, CodePipeline, and cdk diff
- Drift detection and rollback inherit directly from CloudFormation's mature stack engine, which AWS support already understands deeply since it underlies most of the console's own resource management
Cons
- AWS-only by design; there is no path to Azure, GCP, or on-prem resources, so any team managing more than one cloud needs a second tool regardless of how much they like CDK
- Inherits CloudFormation's operational limits, including a 500-resource-per-stack ceiling, which forces manual stack-splitting on large deployments that Terraform's flatter state model doesn't require
- cdk synth output is a large, verbose CloudFormation JSON document that doesn't map cleanly line-by-line back to the source construct, making PR review of the actual infrastructure change harder than reading a Terraform plan
- Smaller cross-cloud provider ecosystem than Terraform, OpenTofu, or Pulumi, since integrating non-AWS services has never been a CDK design goal
Constructs Over Raw Templates
CDK's construct library ships in three levels: L1 constructs are a 1:1 mapping to raw CloudFormation resources, L2 constructs add sane defaults and helper methods (an L2 Bucket construct is a few lines instead of a full CloudFormation resource block with every property spelled out), and L3 constructs (patterns) assemble multiple resources into a common architecture, like a load-balanced Fargate service, in a handful of lines. This layering is CDK's actual value proposition over hand-written CloudFormation, not a marketing feature, since the L2/L3 defaults measurably cut the lines of configuration needed to reach a secure baseline.
Where It Fits Next to Terraform
Teams running mixed AWS-and-multi-cloud environments sometimes use CDK for the AWS-specific pieces where L2/L3 constructs save real time, while using Terraform or OpenTofu for the cross-cloud state graph that ties everything together. CDK for Terraform (CDKTF) exists as a middle path, letting you write CDK-style TypeScript or Python that synthesizes to Terraform's JSON configuration instead of CloudFormation, though it's a separate project with its own maturity curve, not the same tool as CDK proper.
Free and open source (Apache 2.0). There is no CDK-specific charge; you pay only for the AWS resources it provisions, and standard CloudFormation stack limits and quotas apply.
Ansible
Honorable MentionBest for: Configuring, patching, and deploying onto hosts that something else already provisioned
“Ansible is on this list because most real infrastructure stacks pair it with a provisioning tool rather than choosing between them, not because it competes directly with Terraform, OpenTofu, Pulumi, or CDK. It's agentless configuration management: SSH into a host, run a playbook, converge it to a described state. That's a genuinely different job from standing up the VM or cluster in the first place, and treating Ansible as a drop-in Terraform alternative sets it up to fail a comparison it was never built for.”
Pros
- Agentless by design: works over plain SSH or WinRM with no daemon to install, register, or keep alive on every managed node, unlike agent-based configuration tools
- ansible-core is fully free and open source under GPLv3, with no feature gate between the free engine and the free engine used inside the paid Automation Platform
- Ansible Galaxy's existing role and playbook ecosystem for OS hardening, package management, and application deployment has no real equivalent in Terraform, OpenTofu, Pulumi, or CDK, none of which are designed to configure an already-running host
- Event-Driven Ansible extends it beyond scheduled or manually triggered playbook runs into reactive automation triggered by monitoring alerts or webhooks
Cons
- Not a declarative resource graph: playbooks are procedural, so idempotency is the playbook author's responsibility to write correctly, not something the engine guarantees the way Terraform's plan/apply model does
- No built-in state file and no equivalent of terraform plan; there's no single command that shows exactly what a playbook run will change before it runs
- Red Hat Ansible Automation Platform is priced by managed node count with no published list price, and community-reported entry pricing for the features organizations actually need (RBAC, analytics, support) starts well above what a small team budgets for tooling
- Execution slows down on large inventories (thousands of hosts) compared to configuration tools built around persistent agents rather than per-run SSH connections
Configuration Management, Not Provisioning
Ansible playbooks describe the desired state of an already-running host: which packages are installed, which config files exist, which services are running. That's a different problem from Terraform's job of deciding whether a VM or a load balancer exists in the first place. Ansible does have cloud modules capable of creating cloud resources, but doing that at scale means giving up the declarative plan/apply guarantees that make Terraform, OpenTofu, Pulumi, and CDK predictable, which is why most teams that use both tools draw a hard line: Ansible configures, it doesn't provision.
The Common Pairing Pattern
A typical stack provisions a VM or Kubernetes cluster with Terraform or OpenTofu, then triggers an Ansible playbook (often through the same CI pipeline) to install the runtime, configure the application, and register it with monitoring. Ansible's dynamic inventory plugins can read the freshly provisioned hosts directly from cloud provider APIs, so the handoff doesn't require manually copying IP addresses between tools. This pairing, not a head-to-head replacement, is the realistic way Ansible shows up in an IaC stack in 2026.
ansible-core is free and open source under GPLv3. Red Hat Ansible Automation Platform is a paid annual subscription priced by managed node count, with no published list price; community-reported entry pricing starts above $5,000/year depending on node count and support tier.
Which One Should You Pick?
| Use Case | Our Recommendation |
|---|---|
| I manage infrastructure across AWS, Azure, and GCP and need one tool with the broadest provider support | Terraform, for the provider ecosystem and hiring pool, unless the BSL license itself is a blocker for your organization, in which case OpenTofu gives you the same breadth under MPL 2.0. |
| My team already runs Terraform, but legal or procurement flagged the BSL license as a real problem for what we're building | OpenTofu. Migration is typically a binary swap for existing configuration and state, and the license concern that's blocking you goes away. |
| My engineers want infrastructure written in TypeScript or Python with the same tests, linters, and IDE tooling they already use for application code | Pulumi. Just budget for the code review discipline that comes with infrastructure defined in a Turing-complete language, not a limited DSL. |
| We deploy exclusively to AWS and want to eliminate licensing cost from the infrastructure tooling decision entirely | AWS CDK. It's free with no paid tier, and the L2/L3 constructs cut real boilerplate versus hand-written CloudFormation, as long as you're confident you'll stay AWS-only. |
| We already provisioned the servers or cluster and now need to install packages, patch the OS, and deploy the application onto them | Ansible, paired with whichever provisioning tool stood the infrastructure up. It's not a Terraform replacement, it's the next step after provisioning. |
How we evaluated
This comparison covers the tools that actually create your infrastructure: Terraform, OpenTofu, Pulumi, AWS CDK, and Ansible. It's a different category from our Infrastructure as Code security tools comparison (Checkov, Sentinel, tfsec, Regula, Snyk IaC), which covers scanners and policy engines that read your IaC configuration for misconfigurations. Provisioning tools decide what infrastructure exists; scanners decide whether what you're about to provision is safe. A mature pipeline uses one tool from each category, not one instead of the other.
Each tool was assessed on the criteria that decide real outcomes, the same dimensions you see in the comparison table above:
- Best fit: what kind of provisioning problem the tool is actually built to solve, and where that breaks down.
- License and governance: who controls the project, what the license actually restricts in practice, and whether that changed recently.
- Language and workflow: whether infrastructure is defined declaratively in a DSL, in a general-purpose language, or configured imperatively after the fact.
- State and ecosystem maturity: how state is stored and protected, and the depth of the provider or module ecosystem available on day one.
- Pricing model: how cost scales, and what's free vs paid.
What we reviewed
This comparison draws on official documentation and publicly posted pricing, the licensing history that shaped this market in 2023-2025 (HashiCorp's move to the Business Source License, the OpenTofu fork, and IBM's acquisition of HashiCorp), and hands-on evaluation where access was available. It reflects the market as of August 2026 and is refreshed as tools ship and reprice.
Editorial independence: this is a vendor-neutral comparison with no paid placements, sponsorships, or affiliate links. Rankings reflect fit for the stated use cases, not commercial relationships.
Frequently Asked Questions
Terraform vs OpenTofu: which one should I use?
Is Terraform still safe to use after the 2023 license change?
What's the difference between an infrastructure provisioning tool and an IaC security scanner like Checkov or Sentinel?
Can I use Pulumi and Terraform together in the same organization?
Is Ansible a replacement for Terraform?
Does AWS CDK cost anything to use?
Related Comparisons
API Testing & Development
Top 5 API Testing and Development Tools of 2026: Postman vs Bruno vs Insomnia and More
5 tools compared
Data Pipeline / ETL
Top 5 Data Pipeline & ETL Tools of 2026: Fivetran vs Airbyte vs dbt vs Airflow vs Dagster
5 tools compared
Feature Flag Management
Top 5 Feature Flag Management Platforms of 2026: LaunchDarkly, GrowthBook, and More
5 tools compared
Static Site Hosting
Top 5 Static Site Hosting and Jamstack Platforms of 2026: Vercel vs Netlify vs Cloudflare Pages vs Render vs GitHub Pages
5 tools compared