Best Infrastructure as Code Tools in 2026

Last Updated: October 5, 2026 by DevTools Stack Review Editorial Team

IaC tools compared by layer, cloud coverage, state management, policy as code, and licence posture, including where Terraform and OpenTofu now stand.

Infrastructure as code (IaC) is not a single category. The tools that provision a multi-cloud network are not the same tools that configure OS packages on a fleet of VMs, and neither of those tools is interchangeable with the Kubernetes package manager your platform team uses to ship applications. This guide covers nine tools across the full IaC stack, multi-cloud declarative provisioning, cloud-vendor-native authoring, Kubernetes-native configuration, configuration management, and the Kubernetes control-plane layer, and compares them honestly on the dimensions that matter most in 2026: layer and scope, language model, state management, drift detection, policy as code, secrets handling, licence posture, and learning curve. One theme runs through every tool in this list: state management discipline causes more production incidents in this category than tool choice does. Keep that in mind as you evaluate.

Why the IaC Category Is More Complicated in 2026

The infrastructure-as-code landscape shifted materially in August 2023, when HashiCorp moved Terraform from the Mozilla Public License 2.0 to the Business Source License 1.1. IBM subsequently acquired HashiCorp and completed that acquisition in February 2025. In response, a coalition of companies and community contributors forked Terraform 1.5, the final MPL-licensed release, and launched OpenTofu under the Linux Foundation. OpenTofu joined the Cloud Native Computing Foundation at sandbox level in April 2025. These events made licence posture a genuine selection criterion for the first time in this category, and they are the primary reason teams evaluating IaC in 2026 face a materially different decision than teams did two years ago.

The Terraform licence change and its practical meaning for teams choosing today deserve an honest, factual treatment. We address it in the Terraform and OpenTofu entries below and in the FAQ section at the end. All licence terms, ownership details, pricing, and capability claims in this guide should be verified directly with each vendor before relying on them for a procurement or legal decision. This category changes fast, and a stale licence claim is the fastest way to lose confidence in a guide.

The IaC Category Split: Why These Tools Are Not Interchangeable

Before evaluating individual tools, it helps to understand which layer each tool occupies:

• Multi-cloud declarative provisioning: Terraform, OpenTofu, Pulumi, these tools provision resources across any cloud or SaaS provider by talking to provider APIs directly.
• Cloud-vendor-native: AWS CloudFormation, AWS CDK, Azure Bicep, these tools are tightly coupled to a single cloud provider's resource model and API lifecycle.
• Kubernetes-native configuration and delivery: Helm and Kustomize for workload packaging and manifest management; Crossplane for extending the Kubernetes control plane to manage cloud infrastructure.
• Configuration management on existing machines: Ansible, this tool configures operating systems and installs software on resources that already exist; it is often used alongside a provisioning tool rather than instead of one.
• Orchestration and platform layer: Terraform Cloud (HCP Terraform), Spacelift, Env0, Atlantis, these tools run IaC in CI with policy enforcement, state management, and team collaboration features; they are not standalone IaC engines and are not ranked in this list.

Teams frequently use tools from multiple layers together. Understanding the layer each tool occupies prevents the common mistake of comparing tools that solve different problems.

What to Look for in IaC Tools

Engineering and platform teams evaluating IaC tools in 2026 should assess each option against a consistent set of criteria. The weight of each criterion shifts depending on your cloud footprint, team composition, and compliance posture, but the following dimensions are consistently relevant across teams.

Key Evaluation Dimensions for IaC Tools

• Layer and scope: Does the tool provision resources, configure existing machines, manage Kubernetes workloads, or extend the control plane? A tool that operates at the wrong layer is not a gap in features, it is the wrong tool.
• Cloud and provider coverage: Multi-cloud tools like Terraform and Pulumi support thousands of providers. Vendor-native tools like CloudFormation and Bicep are scoped to a single cloud, which is appropriate if that cloud is your entire footprint.
• Language model and reviewability: HCL (Terraform, OpenTofu) is declarative and designed to be reviewed. General-purpose languages (Pulumi, AWS CDK) unlock loops, functions, and unit tests, but they also make it easy to write infrastructure logic that is difficult to review. YAML-based tools (CloudFormation, Crossplane, Helm) are verbose but are readable without a runtime.
• State management and locking: For tools that maintain explicit state files, concurrent applies without locking cause the most common category of production incident. State corruption does not always produce an obvious error; it produces a plan that proposes changes you did not intend, potentially including resource destruction.
• Drift detection: How does the tool surface discrepancies between desired state and actual infrastructure? Terraform and OpenTofu surface drift on every plan. CloudFormation and Bicep rely on on-demand drift detection. Crossplane reconciles continuously.
• Policy as code and guardrails: OPA, Sentinel (HCP Terraform), Checkov, and Pulumi CrossGuard are the primary options. Where the policy engine sits in the workflow, pre-plan, pre-apply, or asynchronously, affects how useful it is.
• Secrets handling: Terraform state files store sensitive values in plaintext unless encrypted. OpenTofu 1.7 introduced native client-side state encryption. Pulumi integrates secrets handling directly into the state model.
• Testing and plan preview quality: The quality of the plan or diff output is a safety mechanism. Pulumi's preview and Terraform's plan are roughly comparable. CDK diff compares templates, not live resource state; cdk drift adds live comparison.
• Module and provider ecosystem maturity: Terraform and OpenTofu share a provider ecosystem of 3,900-plus providers. Pulumi supports 100-plus providers via its own registry. CDK's Construct Hub and Helm's chart repositories are mature ecosystems for their respective layers.
• Licence and governance model: BSL (Terraform), MPL (OpenTofu), Apache 2.0 (Pulumi, CDK, Crossplane, Helm), MIT (Bicep), GPL 3.0 (Ansible). OSI-approved status, governing body neutrality, and commercial restriction scope all vary. Verify current terms directly.
• Learning curve: HCL has a shallow learning curve for operators. General-purpose languages have a shallow curve for developers and a steeper one for operators. YAML tools are immediately readable but verbose at scale.

Teams building internal developer platforms or abstraction layers used by many other teams should weight language expressiveness and testing capability highly. Teams with a large existing IaC estate should weight migration cost and compatibility carefully before changing tools.

How Platform and DevOps Teams Use IaC Tools

IaC tool selection rarely happens in isolation. The following strategies reflect how real teams combine tools across layers.

Multi-cloud provisioning with a declarative core: Terraform or OpenTofu as the provisioning layer, paired with an orchestration platform like Spacelift, Env0, or Atlantis that adds CI integration, policy enforcement, and state visibility. This is the most common production pattern for teams managing infrastructure across multiple clouds.

Developer-led infrastructure with general-purpose languages: Pulumi used to define infrastructure in TypeScript, Python, or Go, with CrossGuard policy packs enforced in the same language. Teams that already write application code in these languages report lower onboarding friction. The trade-off is that complex Pulumi programs can be harder to review than equivalent HCL, because the language permits imperative patterns that obscure what resources will be created.

AWS-native teams with a code-first preference: AWS CDK compiling to CloudFormation, with CDK's construct library providing L2 and L3 abstractions over raw resource definitions. CloudFormation manages state automatically, removing the state-file management overhead that causes many incidents in Terraform estates. The boundary is hard: this pattern only works for AWS resources.

Azure-only infrastructure: Bicep as the authoring layer over ARM, with Azure managing state. Microsoft's own documentation recommends Bicep over raw ARM JSON for new Azure-only work. As with CDK and CloudFormation, the absence of a separate state file removes a class of operational risk in exchange for vendor lock-in.

Kubernetes-native platform engineering: Crossplane extending the Kubernetes control plane to manage cloud resources, with Helm deploying third-party applications and Kustomize managing environment-specific overlays for first-party workloads. This pattern works well for teams already standardized on Kubernetes as their platform layer, where application teams can request infrastructure by applying Kubernetes manifests without learning a separate provisioning tool.

Configuration management alongside provisioning: Ansible running playbooks against existing compute resources after a provisioning tool has created them. Ansible and Terraform are frequently used together, not as alternatives: Terraform creates the VM, and Ansible configures the OS, installs packages, and manages ongoing configuration state.

Competitor Comparison: IaC Tools at a Glance

The table below summarizes how each tool compares across the key evaluation dimensions. Use it as a quick orientation, not a definitive scoring. Verify current licence terms, pricing, and capability claims directly before making a decision.

The comparison shows that no single tool covers every layer. Teams with multi-cloud requirements and mixed resource types typically run two or three tools from different layers. The state-management column is the one that most directly correlates with production incident frequency: tools with explicit state files require disciplined remote backend configuration, locking, and backup practices that tools backed by cloud-managed state do not.

Best Infrastructure as Code Tools in 2026

1. Terraform

Terraform remains the most widely deployed multi-cloud provisioning tool in 2026, with a provider ecosystem covering more than 3,900 providers and a community module registry that no competing tool matches in breadth. Its HCL language is declarative, human-readable, and reviewable without a runtime, which is why it became the default choice for infrastructure code review workflows. Understanding the current licence and ownership situation is necessary before selecting it for any new project.

Key Features:

• HCL language: Declarative, structured, and designed to produce diffs that non-authors can review in pull requests.
• Provider ecosystem: The largest provider ecosystem of any IaC tool, covering AWS, Azure, GCP, Kubernetes, and hundreds of SaaS platforms.
• Plan and apply workflow: terraform plan produces a human-readable diff before any change is applied; terraform apply executes against that plan.

Multi-Cloud Provisioning Offerings:

• Cloud provisioning across 3,900+ providers via the Terraform Registry
• HCP Terraform (formerly Terraform Cloud) for remote state, team management, and Sentinel policy enforcement
• Terraform Enterprise for self-hosted deployments with enterprise support
• Module registry for reusable infrastructure components

Pricing: The Terraform CLI is free. HCP Terraform offers a free tier (up to 500 managed resources), with paid tiers starting at $0.10 per managed resource per month (Essentials), $0.47 per resource per month (Standard, which adds audit logs and drift detection), and $0.99 per resource per month (Premium). Terraform Enterprise is quote-based. Verify current pricing directly with IBM/HashiCorp before budgeting.

Pros:

• Largest provider and module ecosystem of any IaC tool
• HCL is declarative and optimized for code review
• Drift detection on every plan via state refresh
• Strong community, tooling ecosystem, and third-party integrations
• HCP Terraform adds Sentinel policy enforcement, team management, and run coordination
• IBM/HashiCorp support available for enterprise deployments

Cons:

• No longer OSI-approved open source; BSL 1.1 restricts building competing commercial products on top of it
• Licence is now held by IBM following the February 2025 acquisition; roadmap and stewardship are corporate
• Explicit state file requires careful remote backend configuration, locking, and access control; state mismanagement is a leading cause of production incidents
• No native client-side state encryption in the open-source CLI (available on the HCP platform side)
• Sentinel policy enforcement is gated to HCP Terraform; OPA and Checkov are the practical alternatives for teams not on HCP
• Concurrent apply without locking corrupts the state file, a risk that persists regardless of tool version

Terraform's position in 2026 is complicated by the licence change and the IBM acquisition. For most engineering teams running Terraform internally, the BSL permits continued use without restriction. The licence becomes relevant for teams building managed services or platforms that embed Terraform. Teams with OSI-approved licence requirements in procurement or legal policy, including many regulated industries and public sector organizations, should evaluate whether the BSL satisfies those requirements. The HCP Terraform platform offers a strong managed experience, but its per-resource pricing model means costs scale with your infrastructure estate even in weeks when nothing changes. Terraform is the right default for teams already invested in it with no licence constraints, and it remains the reference point against which every other provisioning tool in this list is measured.

---

2. OpenTofu

OpenTofu is the MPL 2.0-licensed fork of Terraform, created in 2023 after HashiCorp's licence change, and hosted under the Linux Foundation. It joined the Cloud Native Computing Foundation at sandbox level in April 2025. For teams that need an OSI-approved open-source provisioning tool with the same HCL language and provider ecosystem as Terraform, OpenTofu is the lowest-migration-cost path.

Key Features:

• MPL 2.0 licence: OSI-approved open source with no commercial use restrictions.
• HCL compatibility: Reads the same HCL configuration language as Terraform, with growing divergence at the feature edges.
• Native state encryption: OpenTofu 1.7 introduced client-side AES-GCM state encryption, a feature absent from Terraform's open-source CLI.

Multi-Cloud Provisioning Offerings:

• Compatible with the Terraform provider ecosystem (same provider plugin protocol)
• Own public registry at registry.opentofu.org
• Native client-side state encryption (committed, one-way; enabling it makes state files unreadable to Terraform)
• Provider for_each (v1.9), early variable evaluation including backend configuration (v1.8), and the -exclude flag (v1.9), features not present in Terraform's open binary
• Supported by all major TACoS platforms: Spacelift, Scalr, Env0, Harness

Pricing: OpenTofu itself is free and open source. Teams pair it with a third-party orchestration platform (Spacelift, Scalr, Env0, Atlantis) or self-hosted remote state (S3 + DynamoDB) for team collaboration. There is no first-party paid platform equivalent to HCP Terraform.

Pros:

• OSI-approved MPL 2.0 licence; no commercial use restrictions
• Multi-vendor governance under the Linux Foundation and CNCF
• Same HCL language and provider ecosystem as Terraform, migration is largely a binary swap
• Native client-side state encryption not available in Terraform's open CLI
• Additional language features (provider for_each, early variable evaluation, -exclude flag) that have not shipped in Terraform's open binary
• Strong adoption signals: CNCF membership, Fidelity Investments migrated 50,000+ state files, GitLab deprecated its Terraform CI/CD templates over licensing concerns

Cons:

• No first-party managed platform equivalent to HCP Terraform; teams must pair it with a third-party TACoS or self-managed backend
• No Sentinel policy enforcement; teams use OPA, Checkov, or platform-native policy tools instead
• Configurations diverge from Terraform as both tools add unique features; forward compatibility is not guaranteed
• State files using OpenTofu's native encryption are not readable by Terraform, enabling encryption is a committed, one-way choice that makes migration back to Terraform harder
• OpenTofu-specific syntax (variables in backend blocks, provider for_each) fails on Terraform; the reverse is also true for HCP-only blocks
• Community governance means roadmap decisions move more slowly than a single-vendor tool, though multi-stakeholder input is a governance benefit for some teams

The migration path from Terraform to OpenTofu is genuinely low-cost for most configurations: install the tofu binary, run tofu init against your existing state, and verify with a small change. The HCL language, module format, and provider protocol are compatible at the Terraform 1.5 baseline. Divergence grows as both tools ship features the other does not support, so teams on recent Terraform versions should test their specific configuration before committing. For teams whose procurement policy, legal review, or compliance posture requires an OSI-approved licence, OpenTofu is the practical default for new multi-cloud provisioning work in 2026.

---

3. Pulumi

Pulumi is an infrastructure-as-code platform that lets teams define and manage cloud infrastructure using general-purpose programming languages, including Python, TypeScript, Go, C#, Java, and YAML. Its core is Apache 2.0-licensed. The key differentiation from Terraform and OpenTofu is that Pulumi programs run as real code through Pulumi's own deployment engine, producing a preview before apply in the same way Terraform produces a plan, but with the full expressiveness of a general-purpose language.

Key Features:

• General-purpose language support: Python, TypeScript, Go, C#, Java, and YAML, teams use the same language, IDE, test framework, and package manager for infrastructure and application code.
• CrossGuard policy as code: Policy packs written in the same language as the infrastructure, enforced before apply.
• Pulumi Cloud state management: Managed state with built-in locking and secrets handling, or self-managed backends.

Multi-Cloud Provisioning Offerings:

• 100+ cloud providers including AWS, Azure, GCP, and Kubernetes
• Pulumi CrossGuard for policy enforcement in the same language as the infrastructure code
• Pulumi ESC (Environments, Secrets, and Configuration) for secrets management across stacks
• Automation API for programmatic infrastructure management
• Pulumi Deployments for CI/CD-integrated runs with review workflows
• Pulumi Insights for cross-cloud resource visibility and compliance monitoring

Pricing: Free individual tier (1 user, unlimited stacks, up to 500 workflow minutes per month). Essentials from $40 per month (includes 40 credits; approximately 500 managed resources). Pro from $400 per month (400 credits; approximately 2,000 managed resources). Enterprise is custom-priced. Verify current pricing directly with Pulumi.

Pros:

• Apache 2.0 licence; OSI-approved open source with no commercial use restrictions
• Real programming languages bring IDE autocomplete, type checking, unit testing, and package management to infrastructure code
• CrossGuard policy packs are written in the same language as the infrastructure, reducing the policy toolchain overhead
• Built-in secrets handling in the state model, rather than requiring external configuration
• Native testing support using standard test frameworks (pytest, Jest, Go testing)
• HashiCorp's deprecation of CDKTF in December 2025 removed the primary competing tool in the general-purpose-language IaC category

Cons:

• General-purpose languages are more expressive and also easier to make unreviewable; a complex Pulumi program can obscure what resources will actually be created in ways that HCL cannot
• Smaller provider ecosystem than Terraform/OpenTofu (100+ vs. 3,900+), though coverage of major cloud providers and Kubernetes is strong
• Migration from a Terraform or OpenTofu estate requires rewriting infrastructure code in a new language, the switching cost is real
• Pulumi Cloud's credit-based pricing model can be difficult to forecast at scale; self-managed backends are an option but require operational overhead
• Requires software engineering skills that may not be present on operations-focused teams
• The Automation API and programmatic patterns are powerful but add complexity that YAML-based or HCL-based reviews do not carry

Pulumi is the strongest choice for developer-led teams that find HCL limiting and are willing to pay the rewrite cost to gain unit testability, type safety, and general-purpose language constructs. It is especially well-suited to teams building internal developer platforms or infrastructure abstractions used by multiple other teams, where the investment in a full programming language pays off over time. Be honest about the reviewability trade-off: the same expressiveness that makes Pulumi powerful makes it possible to write infrastructure logic that reviewers cannot easily validate without running it.

---

4. AWS CDK

AWS CDK (Cloud Development Kit) is an open-source framework for defining AWS infrastructure in general-purpose programming languages. CDK synthesizes the code into CloudFormation templates, then submits those templates to the CloudFormation API for deployment. It inherits CloudFormation's deployment model, including automatic rollback on failure, AWS-managed state, and on-demand drift detection.

Key Features:

• Language support: TypeScript, Python, Java, C#, Go, teams write constructs in familiar languages with full IDE support.
• Construct library: L1 (raw CloudFormation), L2 (opinionated defaults), and L3 (higher-level patterns) abstractions, plus community constructs on Construct Hub.
• CloudFormation state management: AWS manages stack state inside the AWS account; no separate state file to configure, lock, or secure.

AWS-Native Provisioning Offerings:

• AWS construct library with L1, L2, and L3 constructs for every AWS service
• CloudFormation-backed deployment with automatic rollback on failure
• cdk diff for template comparison before deploy
• cdk drift for live resource drift detection against deployed CloudFormation stacks
• Built-in unit testing via the CDK assertions module (Jest, pytest)
• StackSets for multi-account, multi-region deployment

Pricing: AWS CDK is open source (Apache 2.0) and free to use. CloudFormation itself has no additional cost beyond the AWS resources it manages. There is no managed platform equivalent to HCP Terraform.

Pros:

• No separate state file to manage; CloudFormation handles all state inside AWS
• Automatic rollback on stack failure, a safety mechanism absent from Terraform's open CLI
• Same-day support for new AWS services and features via L1 constructs
• Built-in unit testing with standard frameworks
• Apache 2.0 licence; OSI-approved
• Strong abstraction model via the construct library reduces boilerplate for common patterns

Cons:

• AWS-only; multi-cloud strategy requires a second tool
• CDK compiles to CloudFormation, so deployment speed is bounded by CloudFormation's speed, generally slower than Terraform's direct API calls
• The 500-resource-per-stack CloudFormation limit creates architectural constraints at scale
• CloudFormation drift detection is on-demand, not integrated into the normal deploy workflow the way terraform plan is
• CDK library updates occasionally introduce breaking changes to construct APIs
• General-purpose language expressiveness carries the same reviewability trade-off as Pulumi: complex CDK stacks can be hard to audit without running the synth
• Requires bootstrapping per AWS account and region before first use

CDK is the right choice for teams that are AWS-only, prefer programming languages over YAML templates, and want the operational simplicity of cloud-managed state. It is not suitable for multi-cloud environments or teams that need the flexibility of Terraform's state manipulation commands (terraform import, terraform state mv, terraform state rm).

---

5. AWS CloudFormation

AWS CloudFormation is the foundational declarative provisioning service for AWS. It uses JSON or YAML templates to define resources and manages all stack state inside AWS, removing the need for a separate state file. CloudFormation has same-day support for new AWS services and features, making it the most current option for AWS-only teams that use recently launched services.

Key Features:

• AWS-managed state: CloudFormation tracks every resource in a stack inside the AWS account; there is no state file to store, lock, or secure separately.
• Atomic stack operations: Create, update, and delete operations are atomic with automatic rollback on failure.
• StackSets: Deploy templates across multiple AWS accounts and regions from a single operation.

AWS-Native Provisioning Offerings:

• JSON and YAML template authoring for all AWS resource types
• AWS-managed state with automatic rollback
• On-demand drift detection for stack resources
• StackSets for multi-account and multi-region deployment
• Nested stacks for modular template reuse
• CloudFormation Guard for policy-as-code validation of templates
• Direct integration with AWS CDK as the CloudFormation synthesizer

Pricing: CloudFormation itself has no additional charge. Teams pay only for the AWS resources it manages. The CloudFormation service is included as part of AWS.

Pros:

• No state file management; AWS handles all state
• Same-day support for new AWS services, new features available immediately via CloudFormation before third-party providers update
• Automatic rollback on failure
• Zero tool installation required; accessible from the AWS console and CLI
• StackSets enable consistent multi-account governance
• Fully integrated with AWS Organizations, IAM, and CloudTrail for audit and access control

Cons:

• AWS-only; no multi-cloud capability
• JSON and YAML templates become verbose and hard to maintain at scale, CDK exists largely to address this limitation
• On-demand drift detection rather than drift-on-every-deploy like Terraform
• No native support for unit testing templates (CDK adds this)
• The 500-resource-per-stack limit requires architectural planning for large deployments
• Change sets require an additional review step compared to Terraform's inline plan output
• Slower deployments than direct-API provisioning tools in many common operations

CloudFormation is the right foundation for AWS-only teams that value AWS-managed state and same-day service support above all else. Most teams working at scale adopt CDK as an authoring layer on top of CloudFormation rather than writing CloudFormation JSON or YAML directly.

---

6. Azure Bicep

Bicep is Microsoft's domain-specific language for deploying Azure resources, designed as a cleaner authoring layer over Azure Resource Manager (ARM) templates. Bicep code compiles to ARM JSON before deployment, and Azure manages all deployment state inside the ARM layer, no separate state file is required. As of 2026, Bicep is the recommended standard for new Azure-only infrastructure work; ARM JSON is primarily used to maintain existing templates.

Key Features:

• Bicep DSL: Clean, readable syntax that compiles to ARM JSON, with strong typing and IntelliSense support in Visual Studio Code.
• Azure-managed state: ARM tracks all resource state inside Azure; no state file to configure or manage.
• Immediate Azure feature support: Bicep can provision any ARM resource, including those in private or public preview, on day one.

Azure-Native Provisioning Offerings:

• Bicep DSL for all Azure resource types, including preview resources
• ARM-backed deployment with full Azure portal and CLI integration
• What-If deployment preview (equivalent to terraform plan) before applying changes
• Native module support for code reuse across projects
• VS Code extension with type validation, IntelliSense, and refactoring support
• Azure Policy integration for governance and compliance enforcement
• Microsoft support included; Bicep is 100% free to use

Pricing: Free. Bicep is MIT-licensed and supported by Microsoft at no additional cost. Deployments consume Azure resources under the customer's Azure subscription.

Pros:

• MIT licence; permissive and OSI-approved
• No state file management; Azure handles all state via ARM
• Immediate support for all Azure resource types, including preview APIs
• Significantly cleaner syntax than raw ARM JSON
• VS Code tooling is mature, with IntelliSense and type checking
• Supported by Microsoft; 100% free to use
• What-If preview provides a Terraform-plan-equivalent before deployment

Cons:

• Azure-only; not suitable for multi-cloud environments
• Bicep DSL is a domain-specific language; teams must learn it even though it is simpler than ARM JSON
• No native unit testing framework for Bicep templates
• On-demand drift detection rather than continuous or plan-time drift surfacing
• Limited community ecosystem compared to Terraform; fewer community modules and third-party integrations
• Azure dependency means governance, roadmap, and feature availability are entirely at Microsoft's discretion

Bicep is the right choice for Azure-only teams that do not need multi-cloud capability and want the authoring ergonomics improvement over ARM JSON without introducing a general-purpose programming language. If your footprint expands beyond Azure, you will need to introduce a second tool.

---

7. Crossplane

Crossplane is a Kubernetes-native framework for infrastructure as code that extends the Kubernetes control plane to manage cloud resources as custom resources. Rather than running a CLI-driven apply cycle, Crossplane runs controllers inside a Kubernetes cluster that continuously reconcile declared resource state against actual cloud state. It graduated as a CNCF project in November 2025. Crossplane v2, released in 2025, made composite resources and managed resources namespaced by default and significantly reshaped how the tool models applications and infrastructure together.

Key Features:

• Kubernetes control-plane model: Cloud resources are defined as Kubernetes CRDs and managed by controllers, using the same GitOps, RBAC, and reconciliation patterns as application workloads.
• Compositions: Platform teams build self-service abstractions that let application teams request infrastructure (databases, buckets, queues) without learning cloud provider APIs directly.
• Continuous reconciliation: Crossplane detects and corrects drift continuously, without a separate plan-and-apply step.

Kubernetes-Native Provisioning Offerings:

• Provider packages for AWS, Azure, GCP, and other cloud platforms
• Composite resources (XRs) for building opinionated, reusable infrastructure APIs
• Continuous drift correction via Kubernetes controller reconciliation
• Native integration with ArgoCD, Flux, and other GitOps tooling
• OPA and Kyverno for policy enforcement via Kubernetes-native policy tools
• Multi-cloud orchestration through a single Kubernetes control plane

Pricing: Crossplane is Apache 2.0-licensed and free. Upbound (the primary commercial sponsor) offers a managed control plane product. Verify current commercial offerings with Upbound directly.

Pros:

• Apache 2.0 licence; CNCF graduated project with strong governance
• Continuous reconciliation catches and corrects drift without manual intervention
• Kubernetes-native model means platform teams can expose infrastructure as APIs to application teams using the kubectl workflow they already know
• No separate state file; Kubernetes etcd is the source of truth
• GitOps-native; integrates directly with ArgoCD and Flux
• Self-service infrastructure abstractions via Compositions reduce the surface area of cloud knowledge required from application teams

Cons:

• Steepest learning curve of any tool in this list; requires deep Kubernetes knowledge to operate and author Compositions effectively
• Requires a running Kubernetes cluster to host the control plane, adding operational overhead for teams that do not already run Kubernetes
• No explicit plan-before-apply workflow; drift correction is asynchronous, which can make change sequencing harder to reason about
• Provider ecosystem is narrower than Terraform/OpenTofu, though major cloud providers are well covered
• Crossplane v2 introduced breaking changes that require migration effort for existing installations
• Not the right tool for teams that want explicit diff-and-approve workflows before infrastructure changes apply

Crossplane is the right tool for teams building internal developer platforms on Kubernetes, where the goal is to let application teams request infrastructure through kubectl apply without touching a separate IaC engine directly. It is not the right tool for teams that want the explicit plan-and-apply workflow of Terraform or for teams that do not already operate Kubernetes at scale.

---

8. Ansible

Ansible is a configuration management tool maintained by Red Hat that configures operating systems, installs software, and manages ongoing state on existing machines using YAML playbooks over SSH. It is agentless: nothing needs to be installed on target machines. Ansible is frequently mischaracterized as a Terraform alternative, but the two tools solve different problems and are most commonly used together, Terraform or Pulumi provisions the resource, and Ansible then configures the OS and installed software.

Key Features:

• Agentless architecture: Connects to target machines over SSH using standard credentials; no agent or daemon required on managed hosts.
• YAML playbooks: Task-oriented, procedural playbooks describe configuration steps in a format that operations teams can read and write without software engineering background.
• Module library: Hundreds of modules for AWS, Azure, GCP, Kubernetes, network devices, databases, and more.

Configuration Management Offerings:

• Agentless SSH-based configuration management across Linux, Windows, and network devices
• Cloud provisioning modules for AWS, Azure, GCP, and OpenStack (though declarative provisioning tools are usually more appropriate for this layer)
• Event-Driven Ansible for reactive automation based on infrastructure events
• Ansible Automation Platform (Red Hat commercial product) adds RBAC, a visual dashboard, analytics, certified content collections, and SLA-backed support
• AWX (open-source upstream of Ansible Tower) for teams needing RBAC without commercial licensing

Pricing: Ansible core is free and open source (GPL 3.0). Red Hat Ansible Automation Platform uses node-based annual subscription pricing without published list prices; estimates suggest pricing starts at approximately $5,000 per year for 100 nodes, scaling with managed node count. Verify current pricing directly with Red Hat.

Pros:

• Agentless architecture eliminates agent management overhead
• YAML playbooks are readable by operators without software engineering background
• Largest community of any tool in this list, with a vast library of community roles and collections on Ansible Galaxy
• Works alongside provisioning tools (Terraform, Pulumi) rather than competing with them
• No persistent state file; idempotency is the consistency model
• GPL 3.0 core is OSI-approved and freely usable; AWX provides RBAC without commercial cost

Cons:

• Procedural, not declarative: playbooks describe steps rather than desired end state, which means ordering and idempotency must be managed explicitly
• No plan-before-apply equivalent; changes execute immediately unless you run in check mode
• Performance degrades with large host inventories; SSH-based connection overhead at scale requires tuning
• Ansible Automation Platform pricing is opaque; node-based commercial pricing can be expensive at scale compared to open-source alternatives
• Limited drift detection; Ansible can detect configuration drift only when a playbook is explicitly run against a host
• Cloud provisioning via Ansible modules is possible but less ergonomic and less production-proven than Terraform or Pulumi for resource lifecycle management

Ansible occupies a distinct and important layer: configuration management on existing machines. It is the right tool for managing OS configuration, software installation, and day-two operational tasks on compute resources that a provisioning tool has already created. Teams that try to use Ansible as a full substitute for a declarative provisioning tool typically encounter its procedural model's limitations when managing resource lifecycle at scale.

---

9. Helm and Kustomize

Helm and Kustomize occupy the Kubernetes workload configuration layer, they are not cloud-resource provisioning tools and should not be compared directly with Terraform, Pulumi, or CloudFormation. They solve the problem of how to package, customize, and deliver Kubernetes manifests consistently across environments. They are frequently used together rather than as alternatives: Helm to install and manage third-party applications, Kustomize to apply environment-specific overlays to first-party manifests.

Key Features:

• Helm: A Kubernetes package manager that uses Go-templated charts to parameterize and package applications. Helm manages release lifecycle, including installation, upgrade, rollback, and release history, through the helm CLI.
• Kustomize: A template-free configuration customization tool built into kubectl. Kustomize works with plain Kubernetes YAML base manifests and applies declarative overlays, patches, and transformations to produce environment-specific configurations without a separate templating language.

Kubernetes Configuration Layer Offerings:

• Helm: Chart packaging and distribution via OCI registries and HTTP repositories; release management with rollback (helm rollback); dependency management between charts; Artifact Hub for discovering and consuming community charts; Helm test for validating deployed releases; native HelmRelease CRD support in ArgoCD and Flux
• Kustomize: Base-plus-overlay model for environment-specific configuration without templating; built into kubectl (kubectl apply -k); native Kustomization CRD support in Flux; patch-based customization that keeps base manifests as valid Kubernetes YAML

Pricing: Both tools are free. Helm is Apache 2.0-licensed and a CNCF graduated project. Kustomize is built into kubectl and part of the Kubernetes project.

Pros:

• Helm: Largest Kubernetes application ecosystem (20,000-plus charts); built-in release versioning and rollback; dependency management; native support in ArgoCD and Flux HelmRelease
• Kustomize: Zero additional tooling (built into kubectl); keeps base manifests as plain, valid Kubernetes YAML; no templating language to learn; lower complexity than Helm for managing first-party manifests; excellent GitOps compatibility with plain YAML

Cons:

• Helm: Go template syntax is complex and error-prone at scale; helm upgrade can leave orphaned resources; no native drift detection; charts from the community vary significantly in quality and maintenance
• Kustomize: No packaging or distribution model; no release management or rollback; no conditional logic (cannot include or exclude resources based on conditions); complex patch sets become hard to follow; limited compared to Helm for distributing software to external teams
• Both: Neither tool provisions cloud resources; they operate only on Kubernetes manifests and require a separate provisioning tool for cloud infrastructure

For teams managing Kubernetes workloads, the practical recommendation is to use Kustomize for first-party application manifests where environment-specific overlays are the primary need, and Helm for installing and managing third-party applications where chart ecosystems, versioning, and dependency management matter. Many teams use both in the same cluster without conflict.

---

Research Methodology for IaC Tools in 2026

This comparison was developed by the DevTools Stack Review editorial team using a structured evaluation approach. Understanding the methodology helps readers apply the findings to their own context.

All tool capability claims, licence terms, and pricing data were verified against primary sources and recent community research during September and October 2026. This category changes rapidly. Teams should verify current licence terms, pricing, and feature availability directly with each tool's vendor or maintainer before making a decision. A stale licence claim is the fastest way to make a wrong decision in this space.

Why IaC Tool Selection Matters More Than Ever in 2026

The Terraform licence change in 2023 and the IBM acquisition in 2025 permanently altered the calculus for teams choosing a provisioning tool. Before 2023, the choice between Terraform, Pulumi, and CDK was driven almost entirely by team preference, cloud footprint, and ecosystem maturity. Today, licence posture, governance model, and commercial roadmap ownership are genuine selection criteria, not just considerations for legal review, but factors that affect the long-term viability and independence of the toolchain your team depends on.

The tools in this list span every layer of the IaC stack, and choosing correctly at each layer matters. The single most reliable way to reduce production incidents in this category is not to choose the right tool, it is to implement state management discipline with whichever tool you choose. Remote backends with locking, access controls on state storage, regular state backups, and documented recovery procedures for interrupted applies will prevent more outages than any feature comparison. Build that foundation first, then evaluate tool features.

For teams building new infrastructure from scratch in 2026, the practical starting points are: OpenTofu for multi-cloud declarative provisioning where an OSI-approved licence is required; Terraform where the HCP platform and IBM support are valued and BSL is acceptable; Pulumi where the team is developer-heavy and general-purpose language expressiveness justifies the migration cost; AWS CDK for AWS-only teams that want programming languages over YAML; Azure Bicep for Azure-only teams; Crossplane for Kubernetes-native platform engineering teams; Ansible for configuration management alongside a provisioning tool; and Helm with Kustomize for Kubernetes workload delivery.

FAQs About Infrastructure as Code Tools

What is infrastructure as code?

Infrastructure as code (IaC) is the practice of defining and managing infrastructure, cloud resources, network configuration, operating system state, and application configuration, in version-controlled files that can be reviewed, tested, and automated in the same way as application code. Tools like Terraform, OpenTofu, and Pulumi provision cloud resources declaratively or through general-purpose languages. Ansible manages configuration on existing machines. Helm and Kustomize package and deliver Kubernetes workloads. No single IaC tool covers every layer of this stack.

What are the best infrastructure as code tools in 2026?

The best IaC tool depends on which layer of the stack you are addressing. For multi-cloud declarative provisioning, Terraform and OpenTofu are the most widely deployed options, with OpenTofu now the default for teams requiring an OSI-approved licence. Pulumi is the strongest option for developer-led teams wanting general-purpose language expressiveness. AWS CDK and CloudFormation serve AWS-only teams, while Azure Bicep serves Azure-only teams. Crossplane is the right choice for Kubernetes-native platform engineering. Ansible handles configuration management on existing machines, and Helm with Kustomize manages Kubernetes workload configuration.

How does the Terraform licence change affect teams choosing today?

Terraform 1.6 and later versions ship under the Business Source License 1.1, which the Open Source Initiative does not recognize as open source. The BSL permits internal use, running Terraform in your own CI/CD pipelines to provision your own infrastructure is allowed. What it restricts is offering Terraform to third parties in a way that competes with IBM's commercial products. Teams with OSI-approved licence requirements in procurement policy, regulated industries, or public sector procurement should verify whether BSL satisfies those requirements. The licence is now held by IBM, which completed its acquisition of HashiCorp in February 2025. Verify current licence terms directly with IBM/HashiCorp before relying on any summary.

How hard is it to migrate from Terraform to OpenTofu?

For most configurations based on Terraform up to version 1.5, migration to OpenTofu is a binary swap: install the tofu CLI, run tofu init against your existing state and code, and verify with a small change. The HCL language, provider plugin protocol, and state file format are compatible at the Terraform 1.5 baseline. Divergence grows as both tools ship unique features. Enabling OpenTofu's native state encryption is a committed, one-way decision, those state files are unreadable by Terraform. Configurations that use OpenTofu-specific features (provider for_each, variables in backend blocks, the -exclude flag) will not run on Terraform. Test your specific configuration in a non-production environment before committing.

When should a team add an orchestration layer like Terraform Cloud, Spacelift, or Env0?

An orchestration layer becomes necessary when more than one person or CI system runs applies against the same infrastructure state. Without centralized run coordination, concurrent applies corrupt the state file, a failure mode that is expensive to recover from and produces infrastructure that neither apply correctly describes. Add an orchestration layer when your team has more than one engineer running applies, when infrastructure state is shared across teams, or when you need policy enforcement, audit logs, or approval workflows before applies reach production. The free tier of HCP Terraform, or a self-hosted Atlantis instance, provides the minimum necessary coordination for most small teams.

Why does state management cause more incidents than tool choice?

Every provisioning tool that maintains an explicit state file, Terraform, OpenTofu, and Pulumi with a self-managed backend, is vulnerable to the same class of failure: two applies running simultaneously against the same state produce conflicting changes; an interrupted apply leaves state partially updated; a state file stored locally is accidentally deleted or committed to a repository where it exposes sensitive values. These failures do not depend on which tool you use. They depend on whether remote backends with locking are configured, whether state access is restricted to authorized principals, and whether recovery procedures are documented before an incident occurs. State management discipline is the most important practice in this category, independent of tool choice.

Is Ansible a replacement for Terraform?

No. Ansible and Terraform solve different problems and are frequently used together. Terraform or OpenTofu provisions cloud resources, it creates VMs, networks, databases, and storage through cloud provider APIs and tracks their lifecycle in a state file. Ansible configures resources that already exist, it installs packages, manages OS configuration, and applies application settings via SSH. Ansible does ship cloud provisioning modules and can create resources, but its procedural design is less ergonomic for resource lifecycle management than a declarative provisioning tool. The typical production pattern is: provisioning tool creates the resource, Ansible configures the OS and software on it.