12 Infrastructure as Code Tools Ranked for DevOps
12 infrastructure as code tools ranked and compared: Terraform, OpenTofu, Pulumi, CloudFormation, CDK, Bicep, Crossplane, Ansible and more, with licenses.
The infrastructure as code tools most DevOps teams use are Terraform and its open source fork OpenTofu for multi-cloud provisioning, Pulumi for teams that prefer general-purpose languages, CloudFormation, AWS CDK and Bicep for single-cloud work, Crossplane for Kubernetes-based control planes, and Ansible for configuration. The right pick depends on your cloud, language and licensing needs.
This ranking compares twelve tools on what they manage, the language you write, where state lives and the license, so you can choose without wading through marketing pages. Licenses and project status were checked against official sources in November 2026. Two tools from older lists are gone: CDK for Terraform was archived in December 2025, and Google Cloud Deployment Manager reached end of support on 31 March 2026.
Key takeaways
- Terraform is still the most widely used multi-cloud provisioning tool, but since version 1.6 it is licensed under the Business Source License 1.1, not an open source license. IBM now owns HashiCorp.
- OpenTofu is the MPL 2.0 fork of Terraform, run under the Linux Foundation and accepted into the CNCF Sandbox in April 2025. It reads the same HCL and adds features such as client-side state encryption.
- Pulumi (Apache 2.0) lets you write infrastructure in TypeScript, Python, Go, C#, Java or YAML.
- CloudFormation, AWS CDK and Azure Bicep keep state inside the cloud provider, so there is no state file to protect, but they only manage one cloud.
- Crossplane, a CNCF graduated project since November 2025, manages cloud resources through the Kubernetes API.
- Ansible is mainly a configuration management tool. Most teams pair it with Terraform or OpenTofu instead of choosing one over the other.
How we ranked the tools
The order reflects how often each tool appears in DevOps job descriptions and real projects, how many clouds it covers, how healthy its project is, and how useful it is to learn first. It is an opinion, not a market share survey. If you are new to the topic, read declarative vs imperative IaC first, because most tools below are declarative: you describe the end state and the tool works out the steps.
IaC tools comparison table
| Rank | Tool | Main job | Language | State | License | Clouds |
|---|---|---|---|---|---|---|
| 1 | Terraform | Provisioning | HCL | State file (local, remote backend or HCP Terraform) | BSL 1.1 (v1.6 and later) | Any, through providers |
| 2 | OpenTofu | Provisioning | HCL | State file, optional client-side encryption | MPL 2.0 | Any, through providers |
| 3 | Pulumi | Provisioning | TypeScript, JavaScript, Python, Go, C#, Java, YAML | Pulumi Cloud or self-managed backend (S3, Azure Blob, GCS, local) | Apache 2.0 (engine and SDKs) | Any, through providers |
| 4 | AWS CloudFormation | Provisioning | YAML or JSON | Managed by AWS (stacks) | Proprietary AWS service | AWS |
| 5 | AWS CDK | Provisioning (synthesizes CloudFormation) | TypeScript, JavaScript, Python, Java, C#, Go | Managed by AWS through CloudFormation | Apache 2.0 | AWS |
| 6 | Azure Bicep | Provisioning (compiles to ARM JSON) | Bicep DSL | No state file; Azure Resource Manager is the source of truth | MIT | Azure |
| 7 | Crossplane | Provisioning through Kubernetes | Kubernetes YAML, compositions and functions | Kubernetes API objects, reconciled continuously | Apache 2.0 | Any, through providers |
| 8 | Ansible | Configuration management, some provisioning | YAML playbooks | No state; checks the target each run | GPL v3 (ansible-core) | Any, agentless over SSH or WinRM |
| 9 | Terragrunt | Wrapper for Terraform and OpenTofu | HCL | Uses Terraform or OpenTofu state | MIT | Same as the wrapped tool |
| 10 | Google Cloud Infrastructure Manager | Managed Terraform runs on Google Cloud | HCL | Managed by Google Cloud | Proprietary Google Cloud service | Google Cloud |
| 11 | Puppet and OpenVox | Configuration management | Puppet DSL | Agent catalogs and reports | Apache 2.0 source; Perforce ships new Puppet builds under a EULA; OpenVox is the community fork | Servers, any cloud |
| 12 | Chef Infra | Configuration management | Ruby DSL | Chef Infra Server node data | Apache 2.0 source; Progress binaries under the Chef EULA | Servers, any cloud |
1. Terraform
Terraform describes infrastructure in HashiCorp Configuration Language (HCL) and talks to clouds and SaaS products through providers published on the Terraform Registry. The workflow is terraform init, terraform plan to preview changes and terraform apply to make them. It records what it created in a state file, which teams keep in a remote backend such as Amazon S3 or in HCP Terraform (the service formerly called Terraform Cloud).
resource "aws_s3_bucket" "logs" {
bucket = "myorg-app-logs"
}
resource "aws_s3_bucket_versioning" "logs" {
bucket = aws_s3_bucket.logs.id
versioning_configuration {
status = "Enabled"
}
}
License note: Terraform 1.6.0 and later are under the Business Source License 1.1. You can use it freely for your own infrastructure; the restriction targets products that compete with HashiCorp. Each version converts to MPL 2.0 four years after release. IBM completed its acquisition of HashiCorp in February 2025.
Best for: multi-cloud and hybrid teams, and anyone building job-ready IaC skills. Start with how Terraform fits into the DevOps workflow.
2. OpenTofu
OpenTofu forked from Terraform 1.5 (the last MPL release) in 2023 after the license change. It is a Linux Foundation project, joined the CNCF as a Sandbox project in April 2025, and stays licensed under MPL 2.0. Most Terraform configurations and providers work unchanged; you run tofu init, tofu plan and tofu apply.
OpenTofu has added features of its own, including client-side encryption of state and plan files, and early variable evaluation in places such as backend blocks. Because the two projects now develop separately, check compatibility notes before mixing them in one codebase.
Best for: teams that need an open source license, vendors building products on top of the engine, and anyone who wants Terraform skills without BSL questions.
3. Pulumi
Pulumi lets you define infrastructure in a general-purpose language, so you get loops, functions, classes, package managers, unit tests and IDE support. It still works declaratively: your program builds a desired-state graph and pulumi preview and pulumi up compare it with the stored state.
import pulumi
import pulumi_aws as aws
bucket = aws.s3.Bucket("logs")
pulumi.export("bucket_name", bucket.id)
State lives in Pulumi Cloud by default, or in a self-managed backend such as S3, Azure Blob Storage, Google Cloud Storage or a local directory. The engine and SDKs are Apache 2.0; Pulumi Cloud is a commercial service with a free tier.
Best for: developer-heavy teams that want infrastructure in the same language as the application.
4. AWS CloudFormation
CloudFormation is the native AWS service for IaC. You write templates in YAML or JSON, and AWS manages the stack state for you, with change sets to preview updates, drift detection, rollback on failure and StackSets for many accounts and regions. New AWS features often reach CloudFormation quickly, and there is no state file to secure.
Best for: AWS-only organisations that want everything inside AWS, and anyone preparing for AWS certifications.
5. AWS Cloud Development Kit (CDK)
The AWS CDK lets you write TypeScript, JavaScript, Python, Java, C# or Go and synthesizes CloudFormation templates from it. Higher-level constructs bundle sensible defaults, so a few lines can create a load-balanced service with its IAM roles and networking. Common commands are cdk synth, cdk diff, cdk deploy and cdk destroy.
Best for: AWS teams that prefer code over YAML. Because CDK deploys through CloudFormation, it inherits CloudFormation's state handling and limits.
6. Azure Bicep
Bicep is a domain-specific language that compiles to Azure Resource Manager (ARM) JSON templates. It is far shorter than raw ARM JSON, supports modules, and has a what-if operation to preview changes. There is no state file: Azure Resource Manager itself is the record of what exists. Bicep is open source under the MIT license.
az deployment group what-if --resource-group rg-app --template-file main.bicep
az deployment group create --resource-group rg-app --template-file main.bicep
Best for: Azure-only teams. Pair it with deployment stacks if you need Azure to clean up resources that are removed from a template.
7. Crossplane
Crossplane extends Kubernetes so that cloud resources (databases, buckets, networks) become Kubernetes objects. Controllers reconcile them continuously, which corrects drift without a separate plan and apply cycle. Platform teams use compositions to offer self-service APIs such as "a Postgres database for my app" with guardrails built in. Crossplane is Apache 2.0 licensed and became a CNCF graduated project in November 2025.
Best for: platform engineering teams that already run Kubernetes and GitOps tools such as Argo CD. Read how Crossplane brings Kubernetes-native provisioning for a deeper look.
8. Ansible
Ansible configures servers and applications with YAML playbooks over SSH or WinRM, with no agent to install. It can create cloud resources through collections, but it keeps no state file, so it is weaker than Terraform at tracking and removing infrastructure. Most teams provision with Terraform or OpenTofu and configure with Ansible. Red Hat Ansible Automation Platform adds a supported, enterprise layer on top.
See Ansible playbooks used in production for real examples.
9. Terragrunt
Terragrunt is a thin wrapper from Gruntwork that keeps Terraform and OpenTofu code DRY across many environments and accounts. It generates backend configuration, passes outputs between modules and can run commands across a whole stack of units. It is MIT licensed.
Best for: organisations with dozens of environments where copying backend and provider blocks has become error prone.
10. Google Cloud Infrastructure Manager
Infrastructure Manager is Google Cloud's managed service for running Terraform, and it replaces the retired Deployment Manager. It stores state, runs plans and applies, and records deployment history. Its supported Terraform versions top out at 1.5.7, the last MPL-licensed release, so check the supported versions page before using newer language features.
Best for: Google Cloud teams that want managed Terraform runs without operating their own runners.
11. Puppet and OpenVox
Puppet is an agent-based configuration management tool with its own declarative language. It is still common in large server estates. In late 2024 Perforce, which owns Puppet, moved new official builds to a private repository under a EULA, and community maintainers started OpenVox, an open source fork, to continue public development.
Best for: organisations that already run Puppet at scale. New projects usually choose Ansible.
12. Chef Infra
Chef Infra, now owned by Progress, configures servers with a Ruby-based DSL in recipes and cookbooks. The source code is Apache 2.0, but the binaries Progress distributes fall under the Chef EULA, which you accept on first run. Chef InSpec, from the same family, is still widely used for compliance testing.
Best for: existing Chef shops. Like Puppet, it is rarely the first pick for new projects.
How to choose the right IaC tool
| Your situation | Good first choice | Often paired with |
|---|---|---|
| Multi-cloud or hybrid, want the most job openings | Terraform | Ansible, Terragrunt |
| Need an open source license or are building a product | OpenTofu | Terragrunt |
| Developers own infrastructure and dislike DSLs | Pulumi | Application CI pipeline |
| AWS only | CloudFormation or AWS CDK | Terraform for third-party services |
| Azure only | Bicep | Azure DevOps or GitHub Actions |
| Google Cloud only | Terraform or Infrastructure Manager | Cloud Build |
| Kubernetes platform team offering self-service | Crossplane | Argo CD or Flux |
| Configuring servers and middleware | Ansible | Terraform or OpenTofu for provisioning |
Whichever tool you choose, the same habits apply: keep code in Git, review every plan in a pull request, lock and back up state, scan code for misconfigurations, and watch for drift. Our guides to Terraform best practices in production and infrastructure drift cover those habits in detail. When you are ready for interviews, work through our Terraform interview questions.
For guided practice, the Terraform training and Ansible training courses run in Kharadi, Pune and live online across India.
Official references
- Terraform license (BSL 1.1)
- Terraform documentation
- OpenTofu documentation
- OpenTofu on the CNCF project page
- Pulumi documentation
- AWS CDK developer guide
- Bicep overview
- CNCF announces graduation of Crossplane
- CDK for Terraform repository (archived)
- Infrastructure Manager supported Terraform versions
- Chef licensing
FAQs
Which infrastructure as code tool should a beginner learn first?
Learn Terraform first. HCL is easy to read, the plan and apply workflow teaches good habits, and the same skills transfer directly to OpenTofu and Terragrunt. Add Ansible next for server configuration, then the native tool of whichever cloud you work on.
Is Terraform still open source?
No. Terraform 1.6.0 and later use the Business Source License 1.1, which is source-available but not an OSI open source license. Using it to manage your own infrastructure is allowed; offering a competing product is restricted. Each release converts to MPL 2.0 four years after publication.
What is the difference between Terraform and OpenTofu?
OpenTofu is a fork of Terraform 1.5 maintained under the Linux Foundation and licensed MPL 2.0. Both use HCL and the same provider protocol, so most code moves across unchanged. OpenTofu adds features such as state encryption, while Terraform adds features tied to HCP Terraform.
Is Ansible an infrastructure as code tool?
Yes, but mainly for configuration. Ansible playbooks describe how servers and applications should be set up, and they can create some cloud resources. Because Ansible keeps no state, most teams use Terraform or OpenTofu to provision and Ansible to configure.
Should I use Pulumi or Terraform?
Choose Pulumi if your team writes TypeScript, Python, Go or C# daily and wants tests, loops and shared libraries in infrastructure code. Choose Terraform if you want the larger hiring market, the most examples online and a language that operations engineers can review easily.
Is CDK for Terraform still supported?
No. HashiCorp archived CDK for Terraform on 10 December 2025 and stopped all updates. Existing projects can run cdktf synth --hcl to convert to HCL, or move to Pulumi or AWS CDK if they want to keep writing infrastructure in a general-purpose language.
What replaced Google Cloud Deployment Manager?
Google Cloud Deployment Manager reached end of support on 31 March 2026. Google points users to Infrastructure Manager, which runs Terraform as a managed service, or to other tools such as Terraform, OpenTofu or Pulumi run from your own pipeline.
Do CloudFormation and Bicep need a state file?
No. CloudFormation tracks resources in AWS-managed stacks, and Bicep deployments use Azure Resource Manager as the record of what exists. That removes the work of securing a state file, but both tools only manage their own cloud.
What's Your Reaction?
Like
0
Dislike
0
Love
0
Funny
0
Angry
0
Sad
0
Wow
0