Infrastructure as Code in 2026: Choosing the Right Tool

The infrastructure as code services market – tools and platforms for managing cloud infrastructure through code – is no longer one vendor's monopoly in 2026. It's a competitive ecosystem where several strong solutions address genuinely different pain points.

The turning point was 2023: HashiCorp's BSL license change shook the trust of the open source community and opened the door for alternatives that had long been waiting for their moment.

Read on to learn how to choose the right IaC tool for your context – not just the one everyone else picked.

Terraform arrived in 2014 at exactly the right moment. Cloud infrastructure was already complex – multiple providers, hundreds of services, constant change – but IaC tooling barely existed. CloudFormation only covered AWS, while Puppet and Chef were built for OS configuration rather than cloud infrastructure. Terraform filled a real gap and became the first widely adopted infrastructure as code tool with multi-provider support.

HCL proved to be a smart choice: it made IaC declarations readable and writable for a broad range of engineers, giving teams a declarative configuration language that didn't require a programming background. Teams could finally do infrastructure code review in a single PR instead of emailing YAML files back and forth.

But the real lock-in came from the provider ecosystem. The ecosystem grew to include thousands of providers – from AWS and GCP to GitHub, Datadog, and Cloudflare. A classic network effect: the more teams use this IaC tool, the more providers build support for it, and the harder it becomes to justify switching to something else.

Over time, an "interview effect" took hold: "we use Terraform" became the standard answer to any question about IaC stack – not because teams had evaluated alternatives, but because everyone around them was doing the same thing.

It didn't win a competition between tools. It won a moment – and lived off that for a long time.

The monopoly wasn't broken by a single event. It was eroded by three distinct forces – each with its own logic and its own consequences for the market.

The 2023 BSL License

In August 2023, HashiCorp changed Terraform's license from the Mozilla Public License to the Business Source License. Formally, the BSL only affected companies building commercial products on top of Terraform – but the community's reaction revealed something deeper. The context became even more significant when IBM announced the acquisition of HashiCorp for $6.4 billion in April 2024 - a deal that closed in February 2025 after regulatory review in both the US and UK: Terraform is now developed inside a large corporation, not an independent company.  For anyone evaluating long-term vendor lock-in risks, this materially changes the picture.

OpenTofu – a fork under the Linux Foundation – appeared just a month later. It's worth noting that most teams were not legally affected by the BSL. But in open source, trust is everything. When a maintainer starts treating a project as a commercial product rather than a community tool, people start looking for a fallback – even with no direct risk to themselves. That's rational hedging, not panic.

Pulumi Reached Maturity

Pulumi had been around since 2017 but lived in the "interesting experiment for developers" category for a long time.

The shift came in 2024–2025, when:

- Large companies started migrating real production infrastructure to it

- The first credible case studies from serious players emerged

- The tool stabilized enough to underpin long-term architectural decisions

Pulumi's core advantage: you write infrastructure automation in the same language you use for everything else. TypeScript, Python, Go – familiar IDEs, refactoring, unit tests, CI/CD pipelines, code review in the same repo as your product code. For product-oriented teams where developers are increasingly involved in infrastructure work, this fundamentally changes how responsibilities are divided.

Platform Engineering as a Discipline

Around 2023–2024, Platform Engineering solidified into a distinct discipline with its own tooling, metrics, and expectations. With it came a distinct role: the platform engineer – someone who builds infrastructure abstractions for other developers, not just keeps servers running.

Crossplane brought an idea that sounds unfamiliar in the Terraform world: infrastructure as Kubernetes Custom Resources. A developer runs kubectl apply and gets a database – no direct access to the cloud provider console, no need to know HCL or AWS IAM.

Crossplane's CNCF graduated status signals to enterprises that it's a safe long-term investment.

In the Platform Engineering era, choosing an IaC tool increasingly comes down to who's on your team and what kind of platform you're building – not just technical specs.

OpenTofu

Best for: teams already on Terraform that don't want a major migration – or those who want the HCL approach without vendor dependency.

OpenTofu started as a Terraform 1.5-compatible fork but has since gone its own way. As of June 2026, the current stable release is v1.12.3 with over 3,900 providers and 23,600+ modules.

In April 2025, CNCF officially accepted OpenTofu into its ecosystem at the Sandbox maturity level – a meaningful governance signal, though distinct from the graduated status that Crossplane holds. Key technical differences from Terraform include:

- Native state file encryption at the backend level (since v1.7)

- Improved variable handling via provider-defined functions (since v1.7)

- A more open RFC process where the community genuinely shapes the roadmap

- Early variable evaluation – allowing variables to be used when configuring backends and modules in ways Terraform still doesn't support

This is no longer just "Terraform without HashiCorp" – it's a tool with its own development trajectory under the Linux Foundation.

If you have a large IaC state and an existing HCL codebase, migration is typically a matter of hours for most teams – swapping the binary and running tofu init. State management is identical, and all existing modules keep working. The open license significantly reduces vendor lock-in risk.

OpenTofu doesn't solve the fundamental problems of the HCL approach – testing is still painful, infrastructure code still lives separately from product code. It gives you stability and licensing peace of mind – and for many teams, that's enough.

If you're staying on Terraform, it's worth noting its direction: HashiCorp (now part of IBM) is developing Terraform Stacks and expanding integration with the HCP AI Ecosystem.

Pulumi

Best for: product-oriented teams where developers actively write or read infrastructure code.

Imagine your IaC living in the same repo as your product code, going through the same code reviews, and being tested through the same CI/CD pipeline. Developers don't learn a new declarative language from scratch – they work with TypeScript or Python they already know. That's what Pulumi delivers: declarative infrastructure through familiar programming languages, real unit tests, refactoring in a familiar IDE. Pulumi's own concepts (Stack, Resource, Output) still need to be learned, but the entry barrier for a developer is significantly lower than with HCL. Note that Pulumi's provider registry, while growing, is significantly smaller than the Terraform/OpenTofu ecosystem – worth checking coverage for your specific stack before committing.

So why isn't everyone using it? Because ops engineers without a programming background often find it harder to learn than HCL. The added abstraction also makes provider-level debugging more difficult. If your team is mostly sysadmins rather than developers, expect some onboarding friction.

Crossplane

Best for: platform teams building an Internal Developer Platform with a mature Kubernetes culture.

Crossplane gives platform teams the ability to build true self-service infrastructure: a developer runs kubectl apply on a custom resource and gets a database or message queue – no direct access to the cloud console, no need to know any specific IaC tool. An IDP built on Crossplane is infrastructure automation that looks to the developer like an ordinary K8s resource. CNCF graduated status confirms it's a safe long-term investment.

Crossplane requires a mature Kubernetes operational culture before you start layering cloud infrastructure on top. Cluster problems and cloud infrastructure problems now live in the same place. For a team still finding its footing with K8s, that's a double hit on complexity.

AWS CDK / Azure Bicep 

Best for: teams that are deliberately and permanently committed to a single cloud provider.

Native CDKs offer the deepest integration: new provider services are available immediately without waiting for a community provider, documentation is always current. AWS CDK is especially strong where complex cross-service AWS integrations are involved – things that require workarounds in Terraform resolve natively here. Azure Bicep solves the same problem for the Microsoft stack: declarative infrastructure without an extra abstraction layer.

Worth noting: Google Cloud has no official CDK equivalent to AWS CDK or Azure Bicep. For GCP-heavy teams looking for a similar developer experience, CDK for Terraform (CDKTF) is worth considering – it brings the imperative programming model to any provider, including GCP, without locking you into a single cloud.

Vendor lock-in here isn't a mistake – it's a conscious trade-off. If you're on AWS and planning to stay, that's a fair deal and a real advantage. But if there's any hint of a multicloud strategy, or your cloud provider could change in three years, exiting a native CDK will be expensive and painful. Rewriting infrastructure from AWS CDK to anything else isn't refactoring – it's a full migration.

Terragrunt

Best for: teams on Terraform or OpenTofu that need better orchestration without changing their core tool.

Terragrunt often flies under the radar in IaC discussions, yet for many teams it's the most practical intermediate step. It doesn't replace Terraform or OpenTofu – it extends their capabilities through:

- Automated state management across environments

- DRY configuration (no copy-paste)

- A clean structure for modular monorepos

If your main pain isn't the tool's language but the organization of a large HCL codebase, Terragrunt should be your first consideration.

Need help choosing and implementing IaC for your project? Learn about our Infrastructure as Code services.

Question 1: Who writes infrastructure on your team?

If it's mostly ops engineers or a tech lead with a systems background – the familiar declarative logic of HCL and its low entry barrier make the choice straightforward.

If developers are actively involved in DevOps and infrastructure code lives alongside product code – a tool built on a real programming language significantly reduces friction.

Question 2: Single cloud provider or multicloud?

If the answer is "100% AWS and that's not changing for at least 3 years" – native CDKs are worth serious consideration, the advantages are real.

If you're running two or more providers, or have plans to diversify – multi-provider tools give you considerably more flexibility. Multicloud without abstraction is operational pain that compounds over time.

Question 3: Large legacy Terraform state or starting from scratch?

With a large state and years of accumulated legacy infrastructure – OpenTofu is the least painful path forward, migration takes days, not months. Starting from zero gives you genuine freedom of choice, and that's exactly where it's worth spending a week on the right decision rather than defaulting to the familiar out of inertia.

Question 4: Are you building an Internal Developer Platform?

If the goal is giving developers self-service access to infrastructure through abstraction, and your team already has Kubernetes maturity – Crossplane is worth considering as the foundation for your IDP.

If platform engineering is on the roadmap but not your current reality – don't over-engineer prematurely.

Choosing a tool based on GitHub stars or what candidates put on their resumes

Popularity and fit for your team are two different things. Terraform has millions of users – but if your team is five developers and nobody knows HCL, that's not an argument for using it.

The question is always the same: what works best for us, not what's popular.

One big state file for all your infrastructure

It starts out convenient. It ends with an IaC plan that takes 20 minutes to run and a single failed apply that can take everything down.

State management needs to be designed around isolated contexts from day one – separate boundaries for:

- Networking

- Databases

- Applications

This isn't overengineering – it's basic hygiene. Especially critical for OpenTofu and Terraform, where a monolithic state is the most common source of operational pain.

"We'll add modules later"

Copy-pasting infrastructure code across environments is debt that compounds. Three environments, five services – fifteen places where you need to make one change. Later never comes.

Ignoring infrastructure testing

Terratest for HCL stacks, the Pulumi testing framework, checkov for static analysis – these aren't a luxury. A CI/CD pipeline with no infrastructure checks is automated chaos. The blast radius when things break is bigger than with product code.

Not thinking about drift from day one

Drift detection needs to be part of the process from the start – not something you add after the first incident.

Someone goes into the console and manually changes a parameter. A script adds a resource outside IaC. A month later you no longer know what's real and what's in the state file.

Automatic drift detection isn't built into any tool by default – it's always a deliberate operational decision.

OpenTofu and Terraform remain a valid IaC choice for a large number of teams in 2026. If you have a stable HCL codebase, mature processes around state management, and a team that knows the tool well – there's no reason to migrate for the sake of migrating.

But choosing them because "that's what we've always done" is no longer a sufficient reason. The infrastructure as code services market has produced real alternatives that address real pain points better in specific contexts.

Pulumi doesn't exist to replace the HCL approach – it exists because there are teams for whom HCL is an unnecessary barrier between developers and infrastructure.

Crossplane doesn't exist to become the new IaC standard – it exists because there are platform teams for whom self-service infrastructure through the K8s API feels more natural than any other DevOps tool.

The right IaC approach in 2026 is the one that fits your team, your stack, and your plans. Not the most popular one, and not the one you saw on the last candidate's resume.

What tool did your team choose, or is it just a matter of habit?