Infrastructure as Code in 2026: The Post-Fork Landscape and What Actually Matters

Updated (February 2026): Complete rewrite replacing generic IaC overview with current analysis of the post-fork landscape, tool comparisons with real adoption data, policy-as-code and drift detection tooling, AI-assisted IaC developments, and practical structuring guidance.

The IaC Landscape Has Fractured

Two events reshaped Infrastructure as Code more than any technology development: HashiCorp's switch to the Business Source License (BSL) in August 2023, and IBM's $6.4 billion acquisition of HashiCorp completed in February 2025.

The BSL change triggered the OpenTofu fork within weeks — the fastest meaningful open-source fork in cloud infrastructure history. The OpenTF Manifesto gathered 33,000 GitHub stars and pledges from over 140 companies before the Linux Foundation formally accepted the project. The IBM acquisition consolidated Terraform, Vault, and Consul under corporate ownership, further motivating the open-source ecosystem to diversify.

The result is an IaC landscape that looks fundamentally different from the Terraform-dominant world of 2022. Organizations now choose between Terraform (IBM/HashiCorp, BSL), OpenTofu (Linux Foundation, MPL 2.0), Pulumi (programming languages over HCL), Crossplane (Kubernetes-native), and AWS CDK (AWS-only). Each has distinct strengths, and multi-tool adoption is becoming the norm rather than the exception.

Terraform vs OpenTofu: Where Things Stand

The fork that everyone thought might fizzle has matured into a legitimate alternative. OpenTofu is approaching 10 million GitHub release downloads, and the feature sets are diverging in meaningful ways.

Terraform Under IBM

Terraform remains the most widely adopted IaC tool by installed base. IBM's ownership hasn't slowed development — Terraform 1.14.x is current with 1.15.0 in alpha. The ecosystem of providers, modules, and tooling built over a decade isn't easily replicated.

Key recent additions include write-only attributes (February 2025), the Terraform MCP Server for AI integration, and Project Infragraph connecting infrastructure data with IBM's watsonx AI platform. The most significant ecosystem event was the deprecation of CDKTF (CDK for Terraform) in December 2025 — HashiCorp acknowledged it "did not find product-market fit at scale."

The BSL license prohibits using Terraform in competing products but allows standard infrastructure management use. For most organizations, the license isn't a practical constraint on day-to-day usage. The concern is strategic: depending on a single-vendor BSL-licensed tool for critical infrastructure creates a lock-in risk that some organizations find unacceptable.

OpenTofu's Divergence

OpenTofu has moved beyond feature parity into genuine differentiation. Several capabilities are available in OpenTofu that don't exist in Terraform:

State file encryption at rest (since v1.7) — supports PBKDF2, AWS KMS, GCP KMS, and OpenBao key providers with AES-GCM encryption. Terraform requires third-party tooling or Terraform Cloud for state encryption.

Early variable and locals evaluation (v1.8) — use variables in backend configurations and module source paths. This solves a long-standing pain point where backend configuration couldn't reference variables.

Provider for_each (v1.9) — dynamically instantiate provider configurations, enabling patterns like per-region deployments without code duplication.

S3 conditional writes for state locking (v1.10) — eliminates the need for a separate DynamoDB table when using S3 backends, simplifying state management infrastructure.

Ephemeral resources (v1.11) — work with temporary credentials and transient data without persisting them to state files. Critical for security-conscious organizations that want to avoid storing secrets in state.

Beyond HCL: The Multi-Tool Reality

The Terraform-or-nothing era is over. The Firefly State of IaC 2025 survey found that organizations are increasingly multi-tool, and the fastest-growing alternatives bring genuinely different approaches.

Pulumi

Pulumi has crossed 100 million downloads with 167 percent growth in contributions — outpacing both Terraform and OpenTofu in contribution velocity. Over 3,000 customers including Nvidia, BMW, and Unity use Pulumi in production.

The core proposition is writing infrastructure in real programming languages (TypeScript, Python, Go, C#, Java) instead of HCL. This eliminates the "two-language problem" where infrastructure engineers write HCL and application engineers write TypeScript, creating a gap in skills and tooling. With Pulumi, the same language, IDE, debugger, and testing framework work for both infrastructure and application code.

Pulumi's most strategic move: native HCL support (private beta, GA expected Q1 2026) and the ability to manage Terraform and OpenTofu state in Pulumi Cloud. This positions Pulumi as a platform on top of existing Terraform investments rather than a replacement requiring full migration.

Crossplane

Crossplane graduated from the CNCF on October 28, 2025 — a significant milestone signaling production readiness. With over 3,000 contributors from 450+ organizations, it ranks in the top 10 percent of all CNCF projects.

Crossplane's approach is fundamentally different: it extends Kubernetes with custom resource definitions (CRDs) for cloud infrastructure. Teams define infrastructure using the same Kubernetes API and tooling they use for application deployments. This eliminates a separate IaC workflow for organizations already invested in Kubernetes.

The dominant use case is as the backbone of internal developer platforms, exposing custom Kubernetes APIs (Environment, Application, DatabaseService) while compositions handle the underlying cloud provisioning. The Firefly survey found 40 percent of respondents currently use Crossplane and 60 percent plan to adopt it.

AWS CDK

AWS CDK remains actively developed with significant 2025 improvements including the new CDK Refactor command for safe renaming without resource replacement and early validation to reduce dev-test cycles. CloudFormation continues as the underlying deployment engine.

The CDKTF deprecation forces a clear choice: CDK for AWS-only infrastructure, or Terraform/OpenTofu/Pulumi for multi-cloud. Teams that were bridging both worlds with CDKTF need to pick a side.

Policy-as-Code and Security Scanning

Writing infrastructure as code solved the consistency problem. The next challenge is ensuring that code meets security, compliance, and cost standards before it creates real resources.

Checkov (Palo Alto/Bridgecrew) provides open-source static analysis with over 1,000 built-in policies across Terraform, CloudFormation, Kubernetes, Helm, and ARM templates. It supports custom rules in Python and Rego, making it extensible for organization-specific standards.

Trivy (Aqua Security) has absorbed tfsec and become the unified open-source scanner for IaC files, container images, file systems, and Kubernetes clusters. All new tfsec development happens in Trivy — teams still using tfsec should migrate.

OPA (Open Policy Agent) with Rego provides vendor-neutral policy enforcement. As a CNCF graduated project, OPA works across tools and platforms. HashiCorp's Sentinel is the proprietary alternative, tightly integrated with HCP Terraform but locked to the HashiCorp ecosystem.

Infracost handles the cost dimension — providing cost estimates for Terraform resources before deployment, evaluating FinOps best practices, and integrating into CI/CD pipelines to show the cost impact of changes in pull requests.

The mature pattern is a testing pyramid: terraform validate (syntax) then terraform plan (preview) then Checkov/Trivy (security) then Infracost (cost) then Terratest (integration). Each layer catches different categories of issues, and the entire pipeline runs in CI before any infrastructure changes are applied.

Drift Detection: The Underestimated Problem

Drift — the divergence between your IaC definitions and actual infrastructure state — has emerged as a critical concern. The Firefly survey found that less than one-third of organizations continuously monitor drift. Most are reactive, discovering drift only when something breaks.

The problem is more pervasive than teams realize. Only 6 percent of organizations report full infrastructure codification. Most operate with 40-60 percent of infrastructure managed through IaC, meaning a large surface area exists outside code control where manual changes go undetected.

Enterprise solutions include HCP Terraform (24-hour health checks), env0 (AI-powered drift analysis with "Cloud Compass"), ControlMonkey (one-click remediation dashboard), and Scalr (automated scheduled drift detection).

Open-source approaches include Terragrunt's built-in drift detection and scheduled terraform plan runs in CI/CD pipelines that alert on unexpected changes.

The AI-powered approaches are genuinely useful here. NLP models that understand change context from commit messages and automatically classify drift as intentional versus accidental reduce the noise that makes manual drift monitoring impractical at scale.

AI-Assisted IaC

AI integration in IaC has moved from novelty to genuine utility, but the appropriate role is "fast assistant, not autopilot."

Terraform MCP Server (HashiCorp, open-source) implements the Model Context Protocol, exposing real-time Terraform Registry data — provider schemas, module metadata, resource definitions — to LLMs. Demonstrated with GitHub Copilot at Microsoft Build 2025, it enables AI assistants to generate contextually correct Terraform code using current provider documentation rather than potentially outdated training data.

Spacelift Intent takes a more ambitious approach: codeless, natural-language provisioning built on Terraform providers. Platform teams define guardrails and policies, while developers describe infrastructure needs in plain language. The system generates and executes the underlying IaC.

IDE-integrated AI (GitHub Copilot, Cursor, Amazon CodeWhisperer) generates Terraform, Pulumi, and CDK code with increasing accuracy. The practical value is strongest for boilerplate — resource definitions, module scaffolding, provider configuration — where patterns are well-established and errors are easily caught by validation.

The critical principle: AI-generated IaC must pass through the same linters, policy-as-code checks, plan reviews, and CI gates as human-written code. The speed benefit of AI generation is only valuable if the review pipeline catches the errors that AI inevitably introduces.

Structuring IaC at Scale

How you organize IaC matters more than which tool you choose. Poor structure creates the same problems regardless of whether you're writing HCL, TypeScript, or YAML.

Module Design

Effective modules follow a consistent pattern: main.tf (resources), variables.tf (inputs), outputs.tf (outputs), README.md (documentation), and an /examples directory. Modules should have focused scope — a module that provisions a VPC and a database and a Lambda function and an API Gateway is doing too much. Each module handles one concept with parameterized inputs and semantic versioning.

Multi-Environment Strategy

Directory-based separation (environments/production/networking/) is generally preferred over Terraform workspaces for production environments because it provides better isolation and flexibility. Workspaces work when environments are truly identical. Terragrunt excels at DRY multi-environment configuration at scale, reducing duplication while maintaining environment isolation.

Monorepo vs Polyrepo

The choice depends on team size and organizational structure:

Monorepo works best for small-to-medium teams that want a single source of truth. It simplifies onboarding, makes cross-cutting changes easier, and keeps all infrastructure visible. The trade-off is slower CI/CD and complex permissions as the codebase grows.

Polyrepo suits large organizations with distinct business units, strict security boundaries, or highly autonomous teams. It requires internal module registries and orchestration tooling but provides better isolation and independent release cycles.

Most large organizations land on a hybrid approach: polyrepos for distinct domains, a shared monorepo for common modules, and an internal registry for distribution.

Platform Engineering Integration

IaC tools are increasingly consumed through platform engineering layers rather than directly by application developers. Gartner predicts 80 percent of software development companies will use internal developer platforms by 2026.

The pattern: platform teams build self-service interfaces (Backstage portals, custom CLIs, Kubernetes-native APIs via Crossplane) that abstract IaC complexity. Application developers request infrastructure through these interfaces. The platform handles module selection, policy enforcement, cost controls, and state management transparently.

Commercial platforms like Spacelift, env0, and Scalr provide managed orchestration with policy-as-code integration, drift detection, and multi-IaC support (Terraform, OpenTofu, Pulumi, CloudFormation, Ansible). For teams building their own platform layer, our guide on platform engineering covers the organizational and architectural patterns.

GitOps adoption has reached roughly two-thirds of surveyed organizations, with over 80 percent of adopters reporting higher infrastructure reliability and faster rollbacks. The convergence of GitOps workflows with IaC tooling means infrastructure changes follow the same pull request, review, and merge process as application code — creating a unified development workflow.

Making the Right Choice

For teams evaluating their IaC strategy in 2026, the decision framework is clearer than the noise suggests:

If you're starting fresh, evaluate Pulumi and OpenTofu first. Pulumi's programming language approach eliminates HCL as a learning requirement and unifies infrastructure and application tooling. OpenTofu provides the familiar HCL experience with open-source licensing and features Terraform lacks.

If you're already on Terraform, there's no urgent reason to migrate unless BSL licensing conflicts with your organization's policies. When you do evaluate alternatives, OpenTofu is the lowest-friction migration path (near-complete compatibility), while Pulumi offers a more transformative change.

If you're Kubernetes-native, Crossplane deserves serious evaluation as your primary IaC tool. Managing infrastructure through the same Kubernetes API and tooling used for application deployments reduces operational complexity and enables platform engineering patterns naturally.

Regardless of tool choice, invest in policy-as-code (Checkov or OPA), drift detection (scheduled plans or managed platforms), cost visibility (Infracost), and a testing pipeline that validates changes before they reach production. The tooling around IaC matters as much as the IaC tool itself.

The IaC landscape in 2026 is richer and more competitive than at any point in its history. The Terraform monoculture has given way to genuine choice. For organizations, that means more options but also more decisions. The winners will be teams that pick tools matching their specific constraints — licensing requirements, cloud strategy, team skills, platform maturity — rather than defaulting to whatever was dominant three years ago.