2026 Cloud Solutions Report, #4: Infrastructure as Code

Terraform’s BSL flip in 2023 redrew the IaC map. AI agents are about to redraw it again.

By 2026, Infrastructure as Code (IaC) is the grammar of cloud operations — the assumed default, not a forward-looking practice. The era of configuring servers by hand is long gone. The workflow of declaring infrastructure in HCL (HashiCorp Configuration Language) — introduced by HashiCorp’s Terraform — and having a CI/CD pipeline deploy it has been the enterprise standard for years. The global IaC market is projected to grow from $1.3B in 2025 to $9.4B by 2034 [1], and the practical reality is that most cloud users practice IaC in some form.

But the IaC area differs fundamentally from the observability and security areas covered earlier in this series. Tools like Datadog and CrowdStrike were born as commercial SaaS. Enterprises adopted them under the assumption of “this is something we pay for,” accepting vendor lock-in possibilities as part of the bargain. IaC’s core tools — Terraform, Ansible, Kubernetes — started as open source and became industry standards. Enterprises built up years of infrastructure code, state files, module libraries, and team expertise on top of the premise “this belongs to the community, so it’s safe.”

But when that premise breaks, the impact is much larger than in other domains. Replacing an observability tool is like changing a window. The window is different, but the house’s structure is unchanged — reconfigure the dashboards and alerts and you’re done. Replacing an IaC tool is closer to replacing the blueprint and the structural frame of the house. You migrate the state file that records the entire current infrastructure, rewrite tens of thousands of lines of infrastructure definition code, redesign the CI/CD pipelines that drive it all, and retrain the skillset the team has accumulated over years. That high switching cost is the structural reason license and vendor strategy changes in IaC create disproportionate shockwaves.

In August 2023, HashiCorp switched Terraform’s license from MPL 2.0 (Mozilla Public License — an OSI-approved open source license) to BSL 1.1 (Business Source License 1.1, SPDX identifier BUSL-1.1 — a “source-available” license that is not OSI-approved). Source code stays public and internal use stays free. But hosting Terraform and selling it as a competing managed service is prohibited under the “Additional Use Grant” clause, and going beyond that for commercial provision requires a separate commercial contract with HashiCorp.

One notable clause: the “Change Date.” HashiCorp stipulates that each Terraform release automatically converts to MPL 2.0 four years after its public release. This distinguishes BSL from source-available licenses with permanent restrictions (SSPL, Elastic License 2.0). It also serves as a time-bound mechanism that allows OpenTofu to legally absorb that version’s Terraform snapshot once the window opens.

This wasn’t unique to Terraform. The pattern repeats: MongoDB (SSPL, 2018), Elasticsearch (SSPL/Elastic License, 2021), Redis (SSPL/RSALv2, 2024). A company grows an ecosystem on open source, large cloud providers monetize it as managed services, the company restricts the license, and the community responds with a fork. (Elasticsearch and Redis later added AGPL as an option, partially restoring the open-source path.) But because of IaC’s high switching cost as described above, Terraform’s BSL transition created a shock deeper and longer-lasting than any prior case.

The three years since have unfolded unusually fast and across multiple layers. Just one month after the BSL announcement, in September 2023, OpenTofu was forked under the Linux Foundation, declaring it would preserve the original open-source license. In April 2024, IBM announced a $6.4B acquisition of HashiCorp. Regulatory approval completed in February 2025, putting Terraform under one roof with Red Hat’s Ansible and OpenShift. Through 2025, IBM-Red Hat portfolio integration accelerated. Pulumi pivoted toward “embrace both sides,” declaring it would natively support Terraform’s HCL on its own platform. By 2026, every major vendor announced AI agents as a core IaC strategy. The competitive axis has shifted from “license wars” to “AI agent wars.”

In the middle of this upheaval, CIOs and CTOs face two questions. First: who owns our infrastructure code? — a question about license terms, depth of vendor lock-in, and whether an exit strategy exists. Second: when AI writes infrastructure code, who verifies it? — a question about governance, policy enforcement, and accountability in the AI agent era. These two questions go beyond tool selection. They define the organization’s philosophy of infrastructure automation.

This report is the process of finding those answers. It analyzes the six vendors and projects making up the 2026 IaC ecosystem — Terraform, OpenTofu, Pulumi, Crossplane, Spacelift, Ansible — and addresses why CSP-native IaC tools like AWS CDK and Azure Bicep never became the industry standard.

Three Tensions Shaping 2026

Before going vendor by vendor, three macro forces frame the 2026 IaC market. The era of choosing tools by feature checklist is over. In 2026, different questions come first: under whose rules will we operate?, is the code-writer human or AI?, and is what the cloud provider offers natively enough?

After the License Divide: Three Paths and the Era of Dual Engines

The earlier section covered the background and shock of the BSL transition. Here, the question is how enterprises have actually responded.

The split Terraform’s license transition triggered has settled into three paths by 2026.

The first path is the IBM/HashiCorp camp. After the acquisition, IBM is combining Terraform with Red Hat’s Ansible, OpenShift, and watsonx to build a “one-stop portfolio” for hybrid cloud automation. The division of labor: Terraform provisions infrastructure (Day 0, initial build), Ansible automates configuration and operations on top (Day 1–2, run-and-manage), watsonx supports intelligent decision-making. The appeal is covering the entire lifecycle of infrastructure automation under one vendor relationship. The trade-off is correspondingly deep vendor lock-in.

The second path is OpenTofu. Originating under the Linux Foundation, the project joined the CNCF (Cloud Native Computing Foundation) Sandbox in April 2025, securing institutional legitimacy. Registry usage has grown more than 300% year-over-year, with substantial real-world adoption [2]. The fact that major vendors like Oracle and VMware have declared transitions to OpenTofu is also notable [3]. The project leads with community-driven open governance, while maintaining technical differentiation through features OpenTofu shipped first — state file encryption, ephemeral resources, and more.

The third path is Pulumi’s “embrace the ecosystem” strategy. Pulumi keeps its distinctive approach of defining infrastructure in general-purpose languages like Python and TypeScript, while as of Q1 2026 also supporting Terraform’s HCL as a first-class language and managing Terraform/OpenTofu state files directly in Pulumi Cloud. The program transferring remaining HashiCorp contract value as Pulumi credits is built to actively absorb Terraform-exit demand.

The interesting reality: most enterprises don’t pick just one of these three paths. Building on a mature community (roughly 25,000 GitHub stars, 70+ active contributors [16]), the field is seeing the spread of a “dual engine” strategy — legacy stays on Terraform, greenfield runs on OpenTofu. Continued price hikes on HCP Terraform (formerly Terraform Cloud) are accelerating the spread. The rise of orchestration platforms — Spacelift, Scalr, env0 — designed to manage both engines from a single console is a direct consequence of this context.

AI Agents Write Infrastructure Code: The Era of “More IaC”

If license fragmentation reshaped the political landscape of the IaC ecosystem, the arrival of AI agents is restructuring the technical landscape from the ground up. In the 2026 IaC market, AI is no longer a vendor marketing slogan. It’s a core feature in production.

Here’s a counterintuitive fact worth surfacing first. As AI takes a central role in infrastructure automation, the natural question becomes: do we still need IaC? If AI agents call cloud APIs directly to spin up servers and configure networks, why go through Terraform code? The industry’s answer is the opposite. AI agents calling cloud APIs directly mean no audit trail, no rollback strategy, and no governance. IaC, in the AI era, becomes more essential — as the governance layer or verification layer of autonomous infrastructure management. (Note: “governance layer” here is distinct from the Kubernetes-style “runtime control plane” addressed later in the Crossplane section.) AI-generated infrastructure code still has to pass through IaC’s safety net: version control, code review, policy validation, state management. AI doesn’t replace IaC. It produces more IaC, which means more deployments, more drift potential (drift = real infrastructure diverging from declared state), and a wider governance surface.

On top of this realization, every IaC vendor in 2026 rolled out an AI agent strategy. Pulumi’s Neo positions itself as the industry’s first IaC-specific AI agent. IBM/HashiCorp’s Project Infragraph claims “autonomous infrastructure” through watsonx-powered agentic automation. Upbound’s Crossplane 2.0 promotes an “intelligent control plane” where AI agents interact with infrastructure through the Kubernetes API. Spacelift launched Spacelift Intent — natural-language infrastructure provisioning — while maintaining a dual model that keeps IaC as the “system of record.” Red Hat’s Ansible Lightspeed is a generative-AI assistant for writing Ansible playbooks, with a BYOM (Bring Your Own Model) approach supporting multiple external models. The vendor-specific details come in the vendor analysis below. This is the front line of the “AI agent war” succeeding the “license war.”

The shared challenge across all of these AI agents is the governance paradox. According to Google Cloud’s 2025 DORA (DevOps Research and Assessment) report, 90% of developers already use AI tools and spend roughly a quarter of their work time collaborating with AI assistants (cited via [9]). The speed at which AI writes infrastructure code already overwhelms the speed at which humans can review it. So policy-as-code, automated drift detection, and guardrails that constrain agent execution scope become preconditions, not optional features, for AI agent adoption. The more IaC AI produces, the more sophisticated the governance has to be — that paradox is the core tension of the 2026 IaC market.

Why CSP-Native IaC Never Became the Standard

When IaC comes up, one question always follows: why not just use the cloud provider’s own tools? AWS has CDK (Cloud Development Kit). Azure has Bicep. GCP has Config Connector. Each is optimized for its own cloud, and CDK in particular — letting you define infrastructure in general-purpose languages like TypeScript or Python — offers a developer experience that isn’t bad.

But the reason none of these became industry standards is simple and decisive: they don’t work for multi-cloud. A typical enterprise runs something like 70% AWS, 20% Azure, 10% GCP. Using CSP-native tools means operating three different languages, three state management systems, three deployment pipelines. Terraform became the de facto IaC standard precisely because it delivered the value of “one tool to manage every cloud” — a value CSP tools structurally can’t provide. GCP’s Cloud Deployment Manager is effectively being deprecated, and GCP itself being the CSP that most actively supports Terraform demonstrates the reality.

That said, CSPs aren’t meaningless in the IaC ecosystem. They’re closer to “kingmakers.” No IaC tool works without the providers (plugins) supplied by CSPs. AWS and Google Cloud declaring initial support for OpenTofu right after the fork was also a strategic move that doubled as a hedge against single-vendor HashiCorp dependency. And for organizations fully committed to one cloud, native tools’ strengths — CDK’s type safety and compile-time validation — remain valid. The judgment is straightforward. Single-cloud strategy: CDK or Bicep can be on the table. Multi-cloud or any meaningful chance of future migration: cloud-neutral IaC tools — Terraform, OpenTofu, Pulumi, Crossplane — are effectively required.

The Six Vendors: A Deep Look

This section analyzes the six vendors and projects making up the 2026 IaC ecosystem. Before placing all six on the same axis, an important framing: they actually move on two distinct axes. One is the lifecycle axis, separating Day 0 (provisioning — “build”) from Day 1–2 (configuration management — “operate”). The other is the execution model axis, splitting “imperative execution” (humans or CI triggering commands) from “declarative reconciliation” (controllers continuously aligning state). Placing the six vendors on these two axes:

• Day 0 × Imperative: Terraform, OpenTofu, Pulumi — the three-way IaC engine contest
• Day 0 × Declarative Reconciliation: Crossplane — extending the Kubernetes control plane to infrastructure
• Day 1–2 × Imperative: Ansible — the original of configuration management, now the execution layer for agentic AI
• The wrapper layer: Spacelift — engine-neutral orchestration platform

These vendors don’t compete on one layer. They cover different roles in the IaC ecosystem. In practice, enterprises use 2–3 of them together. The analysis below should be read with the question “which tool solves which problem for our organization?” — not “which tool is best overall.”

Terraform: The Empire’s Consolidation, the Freedom’s Contraction

Terraform still holds the lead in the 2026 IaC market. The depth of the ecosystem accumulated over more than a decade since HashiCorp first released it in 2014 is an asset that’s hard to replace. A provider ecosystem covering 3,000+ cloud services, hundreds of thousands of community modules, and an accumulated talent pool that makes “Terraform engineer” a distinct job category — these are the structural reasons enterprises don’t easily exit Terraform.

But the 2026 Terraform is no longer an independent open-source tool. Following the IBM acquisition described earlier, Terraform is in the process of integrating into Red Hat’s automation portfolio. Within the previously-mentioned Terraform-Ansible division of labor, Terraform takes the Day 0 (provisioning) engine role. Official support for the Red Hat Ansible Provider for Terraform and end-to-end integration via HCP Terraform Actions are on the roadmap.

AI strategy: Project Infragraph. Terraform’s AI strategy is an ambitious construct cutting across IBM’s entire software portfolio. Previewed in September 2025 [4], Project Infragraph is a real-time infrastructure graph and the foundation for agentic automation, connecting HCP (HashiCorp Cloud Platform) with IBM’s major software — Ansible, OpenShift, watsonx Orchestrate, Concert (application risk observability), Turbonomic (resource optimization), Cloudability (cost management). IBM’s stated vision: bind infrastructure, applications, services, and ownership into a single relational graph, secure the “single system of record” for state, and on top of that have AI infer the current state of infrastructure and propose and execute runbooks and configuration changes — implementing “autonomous infrastructure.” Combine Vault’s secrets data with watsonx’s reasoning capabilities, and closed-loop automation that minimizes operator intervention becomes possible.

If this vision lands, Terraform elevates from “a provisioning tool” to a core axis of IBM’s hybrid cloud strategy. But the corresponding depth of vendor lock-in is a cost that has to be considered with clear eyes.

Where it hurts. The biggest anxiety for Terraform users is the legal ambiguity BSL introduced. Questions like “Can we embed Terraform in our product?” and Does an MSP providing a Terraform-based service to customers count as a ‘competing service’? still have no clear answers. Continued price hikes on HCP Terraform and dropped support for external programming languages post-acquisition add to the complaints. Whether IBM’s portfolio integration translates into real customer value or deeper vendor lock-in remains an open question.

OpenTofu: The Community Fork That Became the Enterprise Alternative

Forked in September 2023, one month after the BSL announcement, OpenTofu began as a declaration: we will keep the promise Terraform was supposed to keep. In 2026, that declaration has become real across three axes: institutional legitimacy, technical differentiation, and substantive enterprise adoption.

The real differentiation is technical. Forked from Terraform v1.5.x code, OpenTofu maintains “drop-in replacement” compatibility while shipping features Terraform didn’t implement or rejected. The standout example is state file encryption. Terraform’s state file stores sensitive information like database passwords and API keys in plaintext. OpenTofu added native state file encryption through external key management services in earlier versions, and the latest v1.11 went further by introducing ephemeral resources — designed so that single-execution-scope sensitive information like temporary tokens isn’t stored in the state file at all [11]. The shift — from “protect stored secrets” to “design so secrets aren’t stored at all” — has become the core driver for choosing OpenTofu in heavily regulated finance and healthcare industries.

Enterprise adoption supports this. Fidelity, the large U.S. asset manager, publicly disclosed migrating 50,000+ state files and 4 million+ resources from Terraform to OpenTofu [15]. At Spacelift, roughly half of all deployments now run on OpenTofu. Oracle replaced Terraform with OpenTofu in the latest version of its enterprise product, E-Business Suite Cloud Manager. This isn’t “a possibility of an alternative.” It’s an in-progress migration that’s become real.

Where it hurts. OpenTofu’s biggest weakness is the absence of an official managed service. Without a vendor-operated unified platform like HCP Terraform, enterprise deployment requires choosing a third-party platform. The hiring market is also still thin on “OpenTofu experienced” listings — even when the actual skill gap is small, it can be a hurdle for organizational adoption arguments. And the CNCF Sandbox stage status leaves some conservative enterprises with questions about long-term durability.

Pulumi: Embracing Even the Enemy’s Language

Pulumi reopens an existential question about IaC. Why does the language for defining infrastructure have to be a dedicated language like HCL? Terraform’s HCL has its strengths — declarative, easy to learn — but it hits expressiveness limits when conditional logic gets complex or dynamic configuration is needed. Pulumi confronts this head-on. Infrastructure can be defined in general-purpose programming languages developers already know — Python, TypeScript — and conditionals, loops, functions, classes, and test frameworks all just work. Because infrastructure code lives in the same language, same IDE, same test tools as application code, the line between “infrastructure engineer” and “developer” blurs.

Two strategic moves define the 2026 Pulumi. One is the Terraform-ecosystem embrace described in the macro section. Targeting general availability in Q1 2026, Pulumi Cloud directly manages Terraform/OpenTofu state files and supports HCL as a first-class language [5]. The framing is notable: Pulumi calls this “coexistence, not lift-and-shift.” The `pulumi convert — from terraform` command converts code, but the message isn’t “abandon your Terraform investment all at once.” It’s “take Pulumi’s strengths gradually in a hybrid environment.”

AI strategy: Pulumi Neo — the industry’s first IaC AI agent. The second strategic move is the AI agent. Announced in September 2025, Pulumi Neo positions itself as the industry’s first IaC-specific AI agent. CEO Joe Duffy has reallocated a substantial share of company headcount to Neo development — a strategic bet baked thick into the product. Neo isn’t a simple code-generation assistant. It aims to be a “digital platform engineer” that grasps infrastructure dependencies, executes changes, monitors outcomes, and maintains compliance autonomously across the full process.

Early results are notable. According to Pulumi, U.S. logistics company Werner Enterprises shortened infrastructure provisioning time from 3 days to 4 hours after adopting Neo, and improved feature deployment speed by 75% while maintaining SOC 2 compliance. Beta customers report achieving 10x infrastructure delivery with existing team size, and a 90% reduction in policy violations [6]. (Note: these figures come from Pulumi and have not been independently verified.) Pulumi’s next-generation governance features — AI-driven automated remediation, pre-built compliance packs, Policy Findings hub — integrate with Neo to form a closed loop where policy violations trigger automated remediation. Neo also integrates directly with developer tools like Cursor, VS Code, and Claude Code via Model Context Protocol (MCP) servers. During preview, Neo is free for all Pulumi users. The “bring the IaC agent into the developer’s editor” approach blurs the line between infrastructure work and application development even further.

Where it hurts. Pulumi’s freedom is double-edged. The ability to define infrastructure in general-purpose languages also means the same infrastructure can be written ten different ways. As team size grows, code convention management becomes a real challenge. The provider ecosystem is also a concern. Terraform providers are usable via Bridge, but compatibility issues occasionally surface, and native providers don’t yet cover as much ground as Terraform’s. Neo is currently in public preview, and Pulumi being at startup scale compared to Terraform’s ecosystem leaves questions about long-term durability.

Crossplane: The Control Plane — A Completely Different Path

The three vendors above — Terraform, OpenTofu, Pulumi — share one quiet commonality: they’re all CLI-based “run-and-exit” models. An engineer runs `terraform apply` or `pulumi up`, the tool provisions infrastructure, updates the state file, and the process exits. If someone manually changes a resource in the AWS console (drift), the change goes undetected until the next run. Crossplane confronts this fundamental limit directly.

Crossplane extends the Kubernetes control plane to infrastructure management. Declare infrastructure as Kubernetes resources, and a controller continuously watches the actual cloud state (Observed State) against the declared state (Desired State), running a constant reconciliation loop. When someone changes a resource manually, the controller detects it immediately and automatically restores the original state.

To be fair, Terraform’s `apply` is logically a form of reconciliation too — comparing the state file with real infrastructure to produce a diff. The difference is who triggers it, and when. Terraform waits for an explicit human or CI command. The Crossplane controller runs the loop continuously and autonomously. The approach moves from “humans run plan→apply” to “declare it and the system keeps it that way” — applying the same mechanism Kubernetes uses to constantly reconcile Pod state to the entire cloud infrastructure layer.

The drift-response-time gap is also decisive. Terraform detects and fixes at the next `apply`. Crossplane auto-recovers in seconds to minutes.

In November 2025, Crossplane reached CNCF Graduated status, joining the maturity level of Kubernetes, Prometheus, and Envoy. This isn’t just a title. CNCF graduation requires passing rigorous review on operational maturity, broad adoption, and robust governance models. The Crossplane community holds 3,000+ contributors and 450+ participating companies [7]. Nike, NASA Science Cloud, and SAP are representative production users. Upbound reports Crossplane has been adopted by 1,000+ cumulative organizations and downloaded over 100 million times [12].

Where Crossplane shines brightest is platform engineering. When a platform team uses Crossplane’s Composition feature to define organization-fit custom APIs — like ‘Environment’, ‘Application’, ‘DatabaseService’ — developers can provision resources just by calling those APIs, without understanding the infrastructure underneath. “Call an API instead of filing an infrastructure ticket.” That’s the operating model. Reusing Kubernetes RBAC (Role-Based Access Control) to manage fine-grained team access across one control plane is also attractive at the enterprise level.

AI strategy: Upbound Crossplane 2.0 — a control plane for AI agents. Upbound’s commercial product, built on open-source Crossplane 2.0, positions itself as an “intelligent control plane.” The core idea: provide a consistent control point where AI agents interact with infrastructure through the Kubernetes API. Crossplane 2.0 integrates Claude and OpenAI models directly into infrastructure operations via MCP, and provides intelligent controllers for natural-language policy-based compliance audits, issue detection with recommended fixes, and dynamic resource scaling based on performance patterns. Upbound’s argument: “AI agents can’t move between fragmented systems the way humans do. They need a unified control point where declared state, actual state, policy, and knowledge all live in one place” [12].

This vision is already reaching the field. At KubeCon EU in March 2026, Portugal’s Millennium bcp bank shared a case study on “self-healing infrastructure in banking” — a symbolic reference showing Crossplane has reached mission-critical territory in financial services, not just developer tooling.

Where it hurts. Crossplane’s biggest entry barrier is the learning curve. Deep understanding of Kubernetes itself — CRDs (Custom Resource Definitions), controllers, reconciliation loops, RBAC — is a prerequisite. For organizations that haven’t adopted Kubernetes, getting started is hard. Composition authoring also draws reviews calling it “harder than writing Terraform modules.” In enterprise reality, the typical pattern isn’t “Crossplane instead of Terraform” as a substitution. It’s a complementary relationship: Terraform manages base infrastructure while Crossplane delivers developer self-service. That proves Crossplane’s value while also adding one more tool’s worth of complexity.

Spacelift: From BSL Casualty to Beneficiary of the Split

If the vendors discussed so far answered “what language and what approach do you define infrastructure in?”, Spacelift answers a different question: “once you’ve defined the infrastructure code, how do you control it across multiple tools?” Terraform, OpenTofu, Pulumi, CloudFormation, Ansible — orchestrating all these IaC tools from a single platform is Spacelift’s reason to exist.

Get Chaesang Jung’s stories in your inbox

The positioning matters especially in the context of the “dual engine” era described earlier. For an organization running Terraform on legacy, OpenTofu on new projects, and Pulumi on developer-driven projects, a layer that manages all those stacks from one dashboard, applies unified policy, detects drift, and produces audit logs is not optional — it’s required. The Series C that raised $51M in July 2025 [8] shows investor conviction about this market’s growth potential.

Spacelift’s own history is a microcosm of the IaC license wars. Spacelift built its business model providing managed services on top of Terraform, which made it directly affected by the BSL transition. But the response was fast. Native support for OpenTofu, a migration guide from Terraform to OpenTofu, and ultimately repositioning as a vendor-neutral platform that can manage any IaC engine. A platform that was a casualty of the BSL transition became a beneficiary of the ecosystem split.

AI strategy: Spacelift Intelligence. Spacelift Intelligence, announced in March 2026 [9], consists of two components. First, Spacelift Intent — natural-language infrastructure provisioning, already in general availability (GA). Type “spin up a PostgreSQL RDS in us-west-2,” and Intent provisions the resource. The key: this doesn’t replace existing IaC pipelines — it complements them. Spacelift positions Intent as a fast deployment path for prototyping and experimentation, while clearly stating that IaC code remains the “system of record” in production. The dual model: “build fast with AI, manage safely with IaC.”

Second, the AI Assistant — a general-purpose AI interface for natural-language infrastructure state queries, policy generation, drift diagnosis, and guided onboarding. The context for shipping this feature is clear: “developers’ code-writing speed has exploded with AI tooling, and traditional IaC pipeline speed hasn’t kept up.”

Where it hurts. “Yet another layer” is the most fundamental criticism Spacelift faces. Adding a management platform on top of the IaC engine increases architectural complexity, and for small teams it can be over-investment. Lower brand recognition versus HCP Terraform or the IBM brand, and a pricing model that requires sales conversations rather than published prices, are also friction points. The paradox can’t be ignored either: an orchestration platform adopted to avoid vendor lock-in can become a new lock-in point itself.

Ansible: The Guardrail for Agentic AI

Ansible is the only one of the six vendors in this report that isn’t classified as a “pure IaC tool.” Where Terraform and OpenTofu answer what should we build? (Day 0, infrastructure provisioning), Ansible answers once it’s built, how do we configure and operate it? (Day 1–2, configuration management and operational automation). Installing packages on servers, applying security configurations, deploying patches, automating routine operations — that’s Ansible’s home territory. So why include Ansible in an IaC report? Two reasons.

First, Ansible’s automation scope increasingly overlaps with IaC. Ansible also handles infrastructure provisioning through AWS, Azure, and GCP cloud modules, and has modules for managing Kubernetes resources. The structural absence of a state file means it can’t replace Terraform, but for lightweight provisioning, it’s used enough.

Second, more importantly: Ansible has formed an official division of labor with Terraform under IBM. In the Day 0 / Day 1–2 split discussed earlier, Ansible owns the back half — configuration management and operational automation. The combination is a core axis of IBM’s hybrid cloud strategy to cover the entire infrastructure lifecycle under one vendor relationship.

Ansible’s architectural strength is its agentless design. No separate agent installation on target servers — connect via SSH or WinRM and execute. That means automation reach extends beyond Kubernetes to VMs, bare metal servers, network equipment, even storage arrays — the broadest scope among the tools in this report. Ansible Automation Platform 2.6, released in October 2025 [10], includes Event-Driven Ansible, a self-service automation portal, and an automation value measurement dashboard.

AI strategy: Ansible Lightspeed. Ansible Lightspeed, jointly developed by Red Hat and IBM Research, is a generative-AI-based playbook authoring assistant. Ask in natural language — “Install nginx and open firewall port 80” — and Lightspeed generates the Ansible playbook that performs the task. The notable element here is the BYOM (Bring Your Own Model) approach. Lightspeed currently supports Red Hat AI, OpenAI, and Azure OpenAI models, with IBM watsonx.ai and Google Gemini on the roadmap. The design fits enterprise demand for AI capability without lock-in to a specific AI vendor.

But more strategically important than Lightspeed is the new positioning Red Hat is presenting. Red Hat defines Ansible as the “Trusted Execution Layer” for agentic AI systems, building an architecture where AI agents don’t directly access production systems — they work through Ansible, via verified workflows [13]. The concrete result of this vision is the MCP server included as tech preview in Ansible Automation Platform [14]. The design pattern: rather than running a persistently-exposed MCP server, the implementation operates as a bridge between the MCP client and the existing execution environment, with role-based access control limiting agent-specific permissions. The approach reduces the persistent attack surface that always-on MCP servers can create — a fit for security-conscious enterprise environments. Red Hat’s message is simple: AI agents can “drive” infrastructure, but only inside Ansible as the “guardrail.”

Where it hurts. The confusion Ansible users complain about most often is the blurry boundary with IaC. Ansible can also provision cloud resources, but the absence of a state file means current infrastructure state can’t be tracked, and idempotency guarantees vary by module. The question where does Ansible end and Terraform begin? keeps recurring without a clean answer. SSH-based execution speed in large-scale inventories also draws criticism. The feature gap between free Ansible and commercial Automation Platform — Event-Driven Ansible, the self-service portal, Lightspeed, and other core features are commercial-only — leaves Red Hat/IBM lock-in as another open question. Finally, defining complex workflows in YAML has fundamental limits — readability drops sharply as logic complexity grows. The same problem Pulumi raised about HCL (“why does infrastructure have to be defined in a dedicated language?”) repeats in Ansible’s YAML.

A Closing Note for CIOs and CTOs: IaC Strategy in 2026

The 2026 IaC ecosystem looks completely different than it did three years ago. The era when a single Terraform standard dominated is over. License fragmentation and the arrival of AI agents are happening simultaneously, and while the number of options has grown, so has the complexity of decision-making. The six vendors analyzed in this report don’t compete on one layer — they cover different stages and roles of infrastructure automation. So the more productive question isn’t “which tool is best?” — it’s “what layer does our organization need, and what’s the best choice for each layer?”

Recommendation 1: Pick IaC tools layer by layer.

Resist the temptation to solve all of infrastructure automation with a single tool. The 2026 IaC ecosystem has clearly differentiated into layers, and combining the best tools per layer is the realistic approach.

• Provisioning engine (Day 0): Terraform, OpenTofu, Pulumi territory. If Terraform investment runs deep, keep Terraform but pair OpenTofu for new projects — a realistic dual-engine strategy. For developer-led teams, Pulumi’s general-purpose-language approach deserves consideration.
• Configuration and operational automation (Day 1–2): Ansible territory. Especially for organizations with significant infrastructure outside Kubernetes (VMs, bare metal, network equipment), Ansible’s agentless architecture delivers value hard to replicate with other tools.
• Developer self-service platform: Organizations with mature Kubernetes adoption can evaluate Crossplane as the backbone of platform engineering. It’s the lever for converting infrastructure-ticket culture into API culture.
• Orchestration layer: For single-engine operations (Terraform only), HCP Terraform is the economical choice. For multi-engine environments, engine-neutral Spacelift is the natural fit. Either way, it has to become the center of governance and visibility.

That said, combination has costs. The following five things must be designed together when planning a combination strategy:

• Single source of state: When multiple engines contend for ownership of the same resource, drift becomes infinite.
• Policy engine duplication: Sentinel, CrossGuard, OPA, Kyverno repeat at each layer.
• RBAC fragmentation: If HCP, Kubernetes, Spacelift, AAP permission systems don’t converge through SSO/IdP, permission attribution becomes untraceable.
• Secret distribution path fragmentation: Each engine routes through separate paths, so rotation and revocation policies stay inconsistent.
• Dependency graph disconnect: Within-engine DAGs and across-engine couplings have no type-safety binding.

Every vendor will tell you “we’re enough on our own.” The reality is that a combination of 2–3 tools is optimal in most cases.

Recommendation 2: Manage license risk like technical debt.

The lesson from Terraform’s BSL transition is clear. Open-source tool license changes can arrive without notice and apply retroactively to existing users. This isn’t just Terraform’s problem. It’s a repeating pattern — after MongoDB, Elasticsearch, Redis — and no one knows which tool gets added to that list next.

So review the license terms of core IaC tools at least once a year, and prepare transition scenarios (migration playbooks) for the major tools in advance. The Terraform-to-OpenTofu transition is relatively smooth thanks to compatibility, but even it involves state file migration, CI/CD pipeline modification, and team training.

One useful indicator for preemptively evaluating the possibility of another license change is the project’s copyright concentration. Projects with copyright concentrated in a single vendor through a Contributor License Agreement (CLA) can change license again. Projects like the Linux kernel, where copyright is distributed across all contributors, effectively cannot be relicensed again. When renewing commercial contracts, explicitly negotiating a “Grandfather clause” — confirming that existing usage rights remain at the contract-time terms even if the license changes later — is a practical safeguard.

The assumption that “it’s open source, so it’s free, and because it’s free, it’s forever safe” is no longer valid. Only organizations that manage license risk at the same level as technical debt will keep the initiative through the next license change.

Recommendation 3: Adopt AI IaC agents — but design the guardrails first.

Pulumi Neo’s customer case (provisioning 3 days → 4 hours), Spacelift Intent’s natural-language deployment, Ansible Lightspeed’s playbook auto-generation — the productivity gains from AI IaC agents are already being demonstrated. Ignoring this flow is the same as inviting competitive decline.

But deploying “AI-generated infrastructure code” to production without verification is dangerous. AI produces plausible-looking code quickly, but can make subtle security group misconfigurations or resource sizing mistakes that trigger cost explosions. So the order of AI agent adoption is clear. First, build policy-as-code. Policy engines like OPA (Open Policy Agent), Sentinel, and Pulumi CrossGuard need to become the safety net that automatically validates AI-generated code.

Next, expand AI agent execution scope tier by tier:

• Tier 1 — Code generation assistant: In development environments, AI suggests IaC code; human engineers review and approve.
• Tier 2 — Staging auto-deploy: In staging, AI autonomously deploys changes that have passed policy validation. Production still requires human approval.
• Tier 3 — Production autonomous operation: Drift detection and rollback, autonomous execution of non-urgent changes delegated to AI. Requires the strictest guardrails, auditing, and kill switches as a precondition.

The dual model Spacelift proposes — “build fast with Intent, manage safely with the IaC pipeline” — is a good reference for the space between Tier 1 and Tier 2.

Recommendation 4: Prepare an answer to “can’t we just use our cloud provider’s tools?”

This question will come up — from executives, from CSP sales. As discussed in the main text, single-cloud strategies can put CSP-native tools on the table. But for multi-cloud, or any meaningful chance of future migration, cloud-neutral IaC tools are essential.

What matters more is having this judgment criterion documented in advance. That way, the unproductive back-and-forth that recurs every time tool selection comes up gets shortened. Having an organizational consensus answer to “why do we use Terraform (or OpenTofu, or Pulumi)?” is the starting point of IaC governance.

Back to the two questions from the opening. Who owns our infrastructure code? And when AI writes infrastructure code, who verifies it? Three years ago, the first answer would have been “the community, obviously,” and the second would have been “a story for the distant future.” In 2026, the answers are much more complex. Ownership has become something to negotiate inside license terms and portfolio strategy. The party verifying AI-written code is now the organization’s governance design capability itself. In the end, IaC is no longer an engineering tool-selection problem. It’s the management question of under what discipline does the organization operate its own infrastructure? Only organizations that can answer those two questions will navigate the next three years of upheaval with the initiative in hand.

References

[1] Precedence Research, “Infrastructure as Code Market Size to Reach USD 9.40 Bn by 2034.” https://www.precedenceresearch.com/infrastructure-as-code-market

[2] Matt Asay, “OpenTofu becomes the real deal,” InfoWorld. https://www.infoworld.com/article/3852167/opentofu-becomes-the-real-deal.html

[3] DevPro Journal, “The OpenTofu Switch Trend: Are Industry Players Abandoning the Terraform Ship?” https://www.devprojournal.com/technology-trends/open-source/the-opentofu-switch-trend-are-industry-players-abandoning-the-terraform-ship/

[4] IBM Newsroom, “HashiCorp Previews the Future of Agentic Infrastructure Automation with Project Infragraph,” September 25, 2025. https://newsroom.ibm.com/2025-09-25-hashicorp-previews-the-future-of-agentic-infrastructure-automation-with-project-infragraph

[5] Pulumi Blog, “Pulumi for All Your IaC — Including Terraform and HCL.” https://www.pulumi.com/blog/all-iac-including-terraform-and-hcl/

[6] PR Newswire, “Introducing Pulumi Neo, the Industry’s First AI-Powered Platform Engineer,” September 16, 2025. https://www.prnewswire.com/news-releases/introducing-pulumi-neo-the-industrys-first-ai-powered-platform-engineer-302556718.html

[7] InfoQ, “Crossplane Reaches Production Maturity by Graduating CNCF,” November 2025. https://www.infoq.com/news/2025/11/crossplane-grad/

[8] PR Newswire, “Spacelift Raises $51M Series C to Redefine Enterprise Infrastructure Automation,” July 10, 2025. https://www.prnewswire.com/news-releases/spacelift-raises-51m-series-c-to-redefine-enterprise-infrastructure-automation-302501578.html

[9] PR Newswire, “Launch of Spacelift Intelligence Brings New, AI-Enhanced Operating Model to Drowning Infrastructure Teams,” March 18, 2026. https://www.prnewswire.com/news-releases/launch-of-spacelift-intelligence-brings-new-ai-enhanced-operating-model-to-drowning-infrastructure-teams-302717517.html

[10] Red Hat Blog, “What’s new in Red Hat Ansible Automation Platform 2.6,” October 2025. https://www.redhat.com/en/blog/whats-new-in-ansible-automation-platform-2.6

[11] OpenTofu, “What’s new in OpenTofu 1.11.” https://opentofu.org/docs/intro/whats-new/

[12] Upbound Blog, “Introducing Upbound Crossplane 2.0 — The AI-Native Control Plane for the Agentic Era.” https://www.upbound.io/blog/introducing-upbound-crossplane-2-0

[13] Techzine Global, “Red Hat makes Ansible the execution layer for agentic AI systems,” March 5, 2026. https://www.techzine.eu/blogs/infrastructure/139296/red-hat-makes-ansible-the-execution-layer-for-agentic-ai-systems/

[14] Red Hat Blog, “IT automation with agentic AI: Introducing the MCP server for Red Hat Ansible Automation Platform,” February 2, 2026. https://www.redhat.com/en/blog/it-automation-agentic-ai-introducing-mcp-server-red-hat-ansible-automation-platform

[15] OpenTofu Blog, “Fidelity Investments Shares Its Migration Story from Terraform to OpenTofu.” https://opentofu.org/blog/fidelity-investment-migration/

[16] Scalr, “From Fork to Future: How OpenTofu’s Community-First Approach is Reshaping Infrastructure as Code.” https://scalr.com/learning-center/from-fork-to-future-how-opentofus-community-first-approach-is-reshaping-infrastructure-as-code-2/

Part of the 2026 Cloud Solutions Report — an ongoing series on the 2026 cloud tooling landscape. See the full series →

Originally published in Korean by NIA Digital Service Issue Report, April 2026. Written as Distinguished Engineer at MegazoneCloud.

Korean version on Brunch: brunch.co.kr/@chaesang/173