The State of Infrastructure as Code 2026

IaC has moved into the pipeline, which is what makes it trustworthy and what makes the runner behind plan and apply a first-class reliability problem.

Executive summary

Infrastructure as code is now the default way serious teams manage cloud resources, and in 2026 the interesting movement is happening at the edges rather than in the center. The center, that infrastructure should be declared in version-controlled configuration rather than clicked together in a console, is settled. The edges are where the story is: a real fork in the tooling between Terraform and the OpenTofu community alternative, and a steady maturing of how IaC actually runs inside continuous integration.

The most consequential shift is that plan and apply have left the laptop. The era of an engineer running apply from a local terminal against production is fading fast, replaced by pipelines where plan runs on every pull request, apply runs only after review and policy gates pass, and every change leaves an audit trail. This is unambiguously the right direction, because it brings the same review discipline to infrastructure that teams have long applied to application code, and it makes infrastructure changes legible to people who did not make them.

But moving IaC into CI turns infrastructure changes into a first-class pipeline workload, with its own distinctive failure modes. A plan job can be slow against a large state file, an apply can hang waiting on a provider, and a transient cloud-API blip can fail a run that would pass cleanly on retry. When the gate that stands between an engineer and a needed infrastructure change is slow, queue-bound, or flaky, the predictable human response is to route around it, and routing around the gate is exactly how out-of-band changes and configuration drift creep back in.

Drift is the rule rather than the exception. Most long-lived environments carry at least one drifted resource at any given moment, the accumulated residue of console hotfixes, manual scaling during an incident, and emergency changes made under pressure. The teams that keep drift low are not the teams with the strictest policies on paper; they are the teams running continuous plan and drift-detection checks in CI, so divergence surfaces as a failing check on a normal day rather than as a surprise during the next incident.

Policy-as-code is climbing the same maturity curve. Nearly every IaC team runs format and validate, the cheap table-stakes checks, but the frontier is the heavier guardrails: security policy via OPA-style rules, cost estimation before apply, and automated drift detection. These are the steps that turn IaC from documentation into enforcement, and every one of them runs in the pipeline, which means pipeline reliability is not a side concern. It is the precondition that decides whether IaC functions as a genuine guardrail or degrades into a rubber stamp that teams have learned to bypass.

The Terraform and OpenTofu fork is now a real planning question

Terraform remains the dominant declarative IaC tool by a clear margin, but OpenTofu has crossed the line from curiosity to a genuine adoption track. A meaningful share of teams are running it in production or piloting it alongside Terraform, and that share is large enough that tooling choice is now a forward-looking planning question rather than a settled default. The fork is real, and ignoring it is itself a decision.

For most organizations the practical impact is reassuring rather than disruptive, because the two tools share the same workflow and the same CI shape. Both run an init, a plan, and a gated apply; both consume the same provider ecosystem; both produce a state file that a pipeline manages. A team that invests in a solid plan-and-apply pipeline is investing in something that carries over regardless of which side of the fork it eventually lands on, which lowers the stakes of the choice considerably.

Where the fork does matter is in the details that touch the pipeline: provider availability, registry sources, and the version-pinning discipline that keeps a plan reproducible. The teams that handle the fork well treat the tool as a swappable engine behind a stable pipeline contract, rather than baking tool-specific assumptions deep into their automation. That posture keeps the option open and makes the eventual decision a low-drama one.

Plan and apply have moved into CI

The clear majority of teams now run both plan and a gated apply through CI rather than from a laptop, and the chart of where plan and apply run captures the migration. A shrinking minority still run no automation or a local laptop apply, a transitional group runs plan in CI but applies locally, and the largest and growing segment runs both plan and a gated apply entirely in the pipeline. The direction of travel is unmistakable.

The reason is that CI is what brings the things infrastructure changes most need. Review, because a plan posted to a pull request is something a second engineer can actually read and reason about. Policy enforcement, because automated gates can block a change that violates a rule before it ever reaches the cloud. And an audit trail, because every change is tied to a commit, a reviewer, and a pipeline run rather than to someone's memory of what they typed into a terminal last Tuesday.

But the move is only as good as the pipeline behind it, and this is the crucial caveat. A slow or unreliable plan-and-apply job does not just waste time; it actively undermines the discipline it was meant to enforce. When the gated path is painful, engineers facing a production incident will reach for the console instead, and every out-of-band change made that way is a future drift entry. The pipeline's reliability is therefore not a quality-of-life concern, it is what determines whether the gate holds.

• CI brings review, policy enforcement, and an audit trail to infrastructure changes that a laptop apply cannot.
• The largest and growing segment runs both plan and a gated apply entirely in the pipeline.
• A slow or flaky gated path pushes engineers back to the console, which is the source of future drift.

Drift is the rule, not the exception

Most long-lived environments carry at least one drifted resource at any given moment. Drift is not a sign of a careless team; it is the natural residue of operating real infrastructure under real pressure. A console hotfix during an outage, a security group rule widened to unblock a launch, a manual scale-up that was never folded back into configuration, each is individually reasonable and collectively they ensure that the declared state and the actual state quietly diverge over time.

The danger of drift is not the divergence itself but when it is discovered. A team that learns about a drifted resource during the next incident, when an apply suddenly wants to revert a manual fix or a plan shows a change nobody made, is discovering it at the worst possible moment. Drift that surfaces in the middle of an emergency turns a routine infrastructure change into a frightening one, and it is a major reason teams lose confidence in running apply at all.

The teams that keep drift low run continuous plan and drift-detection checks in CI on a schedule, not just on pull requests. A scheduled plan against the live environment surfaces divergence as a failing check on an ordinary Tuesday, when there is time to investigate and reconcile it calmly, rather than as a surprise during an incident. Drift detection is the cheapest insurance policy in IaC, and the modeled adoption numbers show it remains underused relative to its value.

Policy-as-code is climbing from format checks to real guardrails

Nearly every IaC team runs format and validate, because they are cheap, fast, and uncontroversial, the linting tier of infrastructure. The maturity frontier is the heavier gates that the policy-gate chart tracks: security policy enforced through OPA-style rules, cost estimation that surfaces the dollar impact of a change before it applies, and automated drift detection. These are the steps that move IaC from documentation that describes intent to enforcement that prevents mistakes.

Each of these heavier gates is a step up in both value and operational weight. A security policy that blocks a publicly exposed storage bucket, a cost gate that flags a plan that would triple the monthly bill, a drift check that catches an out-of-band change before it compounds, these are the guardrails that justify having moved IaC into CI in the first place. Without them, the pipeline is a place where applies happen; with them, it is a place where bad applies are stopped.

The catch that ties this finding to the rest of the report is that every one of these gates runs in the pipeline, which makes pipeline reliability a precondition for trusting any of them. A policy gate that flakes intermittently teaches engineers to re-run until it passes, which is functionally the same as not having it. A drift check that is too slow to run on every schedule gets disabled. The value of policy-as-code is bounded above by the reliability of the runner it executes on.

Provider init and plan dominate the pipeline clock

The pipeline-time split shows where an IaC run actually spends its wall-clock, and the answer surprises teams who assume apply is the expensive part. Provider initialization and plan together are the largest slice at roughly 36 percent, the apply against the cloud API is about 28 percent, policy and drift checks are around 21 percent, and queue plus cold start is the remaining 15 percent or so. The plan, not the apply, is the heavyweight, and it is the phase that runs most often because it runs on every pull request.

Provider init is a particular and often overlooked cost. Every cold pipeline run downloads and initializes the providers the configuration needs, and on a runner with no cached provider plugins that download is paid fresh every time. For a configuration that spans several providers, the init alone can be a substantial fraction of a short plan run, and it is pure overhead that contributes nothing to the actual change being evaluated.

The queue-plus-cold-start slice is the other piece of avoidable overhead, and it is exactly the part that a warm, elastic runner removes. On hosted runners an IaC pipeline that runs frequently pays a fresh provisioning penalty on every plan, and against a large state file with many providers that fixed cost is not trivial. Caching provider plugins and removing the cold-start penalty attacks the two phases, init and queue, that contribute least to the change and most to the wait.

Large state files turn plan into a slow, serialized step

As an environment grows, its state file grows with it, and a plan must refresh and diff every resource that state tracks. A plan against a small state file is quick; a plan against a state file with thousands of resources spends real time refreshing each one against the live cloud, and that refresh is largely serialized by the provider's rate limits and the dependency graph. The plan that gates every pull request gets slower precisely as the infrastructure it manages becomes more important.

This creates a quiet pressure that works against the discipline IaC is supposed to enforce. When a plan takes long enough, engineers batch changes to avoid waiting through it repeatedly, and large batched changes are harder to review and riskier to apply than small ones. The slow plan does not just cost minutes; it pushes teams toward exactly the large, infrequent, hard-to-review changes that good infrastructure practice tries to avoid.

The structural fixes are splitting monolithic state into smaller, independently planned units and targeting plans to the parts of the configuration a change actually touches. Both reduce the work a single plan must do, and both pair naturally with a fast runner that caches providers and does not re-pay a cold start, so the per-plan overhead is low enough that engineers are willing to plan often and keep their changes small.

Reliable runners decide whether IaC is a guardrail or a rubber stamp

This is the finding the rest of the report builds toward. IaC pipeline runs spend real time on provider init, plan, policy checks, and apply, and they are exposed at every step to the outside world: a cloud-API rate limit, a provider timeout, a registry blip during init. Any of these can fail a run that has nothing wrong with the configuration and would pass cleanly on a retry. On an unreliable runner, that transient failure rate is a constant low-grade tax on every infrastructure change.

When the gate is flaky or queue-bound, teams route around it, and routing around the gate is the origin story of most drift. An engineer who has watched a plan fail twice on transient cloud-API errors during an incident will make the change in the console and tell themselves they will reconcile it later, and later rarely comes. The unreliable pipeline does not just slow infrastructure changes; it quietly trains engineers to bypass the very controls the pipeline exists to enforce.

Managed, self-healing runners that scale instantly and recover from transient failures keep plan and apply fast and trustworthy, at roughly 70% less than GitHub-hosted compute. When a plan fails on a cloud-API rate limit, the platform retries it on a fresh environment automatically rather than surfacing a red check that an engineer has to interpret and re-run. The gate stays fast enough to keep changes small and reliable enough to keep engineers inside it, which is what keeps the guardrail a guardrail rather than a rubber stamp.

• IaC runs are exposed to cloud-API rate limits, provider timeouts, and registry blips at every phase.
• A flaky or slow gate trains engineers to make out-of-band console changes, which is the main source of drift.
• Self-healing runners retry transient cloud-API failures automatically, keeping the gate fast and trusted.

Recommendations

Run drift detection on a schedule, not just on pull requests

Most long-lived environments carry drift at any given moment, and the danger is discovering it during an incident. Run a scheduled plan against the live environment so divergence surfaces as a failing check on an ordinary day, when there is time to reconcile it calmly. It is the cheapest insurance policy in IaC and the modeled adoption shows it is underused.

Treat the tool as a swappable engine behind a stable pipeline

Terraform and OpenTofu share the same workflow and CI shape, so keep tool-specific assumptions out of your automation and let the engine be swappable behind a stable plan-and-apply contract. This lowers the stakes of the fork and means your pipeline investment carries over whichever side you eventually choose.

Split large state and target plans to the change

A plan against a huge state file is slow and serialized, which pushes teams toward large, infrequent, hard-to-review changes. Split monolithic state into smaller independently planned units and target plans to the parts of the configuration a change touches, so plans stay fast and changes stay small.

Cache providers and remove the cold-start penalty

Provider init and queue plus cold start are pure overhead that contribute nothing to the change being evaluated. Cache provider plugins across runs and use a warm, elastic runner so a frequently running plan does not re-pay provisioning and provider download on every pull request.

Auto-heal transient cloud-API failures so the gate stays trusted

Cloud-API rate limits, provider timeouts, and registry blips fail runs that would pass on retry, and a flaky gate trains engineers to bypass it. Retry transient failures on a fresh environment automatically so a red check from a rate limit never reaches an engineer, and the gate stays reliable enough that nobody routes around it into the console.

Outlook

Expect the Terraform and OpenTofu fork to stay a live question through 2026 and into 2027 without becoming a crisis for most teams, precisely because the shared workflow makes the tool swappable behind a stable pipeline. The organizations that treated their plan-and-apply pipeline as the durable investment, rather than betting everything on a specific binary, will navigate the fork as a low-drama configuration change while others agonize over a decision that matters less than they fear.

Policy-as-code will keep climbing from the format-and-validate baseline toward the heavier security, cost, and drift gates, and as it does, the reliability of the runner those gates execute on becomes the binding constraint. A gate is only as trustworthy as the pipeline it runs in, so the teams that pair ambitious policy-as-code with reliable, self-healing compute will get real enforcement while teams that bolt heavy gates onto a flaky runner will watch their engineers learn to re-run until green, which is enforcement in name only.

The throughline for the next two years is that IaC's value is now bounded by pipeline reliability rather than by tooling sophistication. The configuration languages, the providers, and the policy engines are mature; what decides whether IaC functions as a guardrail or a rubber stamp is whether plan and apply stay fast, cheap, and trustworthy enough that engineers stay inside the gate. The teams that build IaC on warm, elastic, self-healing runners will keep the guardrail intact; the teams that do not will keep rediscovering their drift during incidents.

Methodology

This report synthesizes publicly available infrastructure-as-code adoption data with Latchkey's own analysis of IaC pipeline timing and CI/CD runner economics. Figures attributed to a named source reflect that source's published findings. Figures labeled modeled are illustrative estimates derived from typical Terraform and OpenTofu pipelines, drift patterns, and policy-gate adoption, not a primary survey, and are intended to show direction and magnitude rather than a precise population value. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• HashiCorp
• Stack Overflow Developer Survey
• CNCF Annual Survey
• GitHub - Octoverse

More Latchkey reports