The State of Enterprise CI/CD 2026

Governance, compliance, and runner fleets at scale: how platform teams keep multi-org CI fast, auditable, and under a seven-figure budget.

Executive summary

At enterprise scale, CI/CD stops being a pipeline question and becomes a fleet question. A platform team is no longer choosing how one repository builds; it is operating shared runner capacity across dozens of organizations and hundreds of teams, under audit, with compliance boundaries that cannot leak and a budget large enough to attract finance scrutiny. The central challenge is keeping that fleet fast and reliable while proving, on demand, who ran what, where, and on which isolated capacity.

The data shows two recurring failure modes at this scale. The first is silent waste: large fleets carry significant idle capacity because they are provisioned for peak and run far below it most of the day, and that idle compute is pure cost that produces no signal until someone reconciles the bill. The second is governance drag, where ungoverned self-service runner sprawl creates an audit surface no single team fully owns, so every audit becomes a scramble to reconstruct a record that should have been a property of the platform.

This report quantifies both failure modes and shows how centralizing on managed, policy-bound runners recovers the idle spend, hardens the audit story, and removes transient-failure noise from the reliability picture at the same time. The recurring theme is that at enterprise scale the three concerns that look separate, cost, governance, and reliability, are solved by the same architectural move: one centralized, policy-bound, elastically-scaled runner layer that emits per-org usage as a first-class output.

We model the cost of a large fleet across runner tiers, the idle fraction that dominates the waste, the relative impact of the main cost-control levers, and the governance gaps platform teams most consistently report. The figures are a mix of cited public research on platform-team adoption and Latchkey modeled estimates of fleet economics, labeled throughout so the cited and the modeled are never confused.

For platform leaders the practical message is that a seven-figure CI bill is mostly addressable, but only after attribution and consolidation come first. You cannot reduce a cost you cannot attribute, and you cannot govern an estate you do not control, so the sequence matters: get one place to see and enforce, then reclaim the idle, then optimize the rest. The teams that follow that sequence turn enterprise CI from an opaque shared cost into a governed, attributable, defensible line item.

Platform teams own CI, but rarely own the whole fleet

Dedicated platform engineering is now standard at scale. The adoption curve climbs steeply with headcount, reaching the large majority of organizations past the thousand-engineer mark, so the existence of a platform team is no longer the differentiator. What differentiates is whether that team actually controls the runner estate it is accountable for.

Most platform teams inherit a runner estate they did not design: a mix of self-hosted pools stood up by individual product groups, hosted minutes billed to scattered cost centers, and at least one shadow fleet nobody fully tracks. This is the runner sprawl that platform teams most consistently name as their top governance gap, and it is the root cause from which the other gaps grow.

Consolidating that estate under a single managed runner layer with consistent policy is the highest-leverage move a platform team can make, because every downstream control, cost attribution, audit logging, isolation enforcement, image patching, depends on first having one place to enforce it. Without consolidation, each control has to be implemented N times across N fleets and verified N times at audit. The chart below shows sprawl as the most-cited gap, ahead of the audit, attribution, and isolation gaps it feeds.

• Platform-team existence is now standard at scale; control of the fleet is the real differentiator.
• The inherited estate is usually self-hosted pools, scattered hosted minutes, and a shadow fleet.
• Consolidation is the prerequisite for every downstream control, not one control among many.

Idle capacity is the largest line item nobody defends

Self-managed fleets are provisioned for peak and spend most of the day well below it, so a large share of paid capacity sits idle. Our modeling puts the idle and over-provisioned fraction at well over a third of total fleet capacity on an average day, which makes it the single largest non-productive slice of the bill.

Unlike a flaky test or a slow build, idle compute produces no signal until someone reconciles the invoice. A slow pipeline generates developer complaints; a flaky test generates red checks; idle capacity generates nothing but a number on a bill that arrives weeks later, which is why it survives so long and grows so quietly. It is the most expensive thing in the fleet that no one is paged about.

Managed runners that scale to actual demand convert that idle waste directly into savings, which is why managed migration shows up as the single largest cost-control lever in our modeling, ahead of right-sizing, caching, and matrix pruning. Those other levers matter, but they trim the productive portion of the bill, whereas reclaiming idle removes a slice that was never producing anything. The chart below ranks the levers by modeled impact, with managed migration well ahead.

Compliance turns runner choice into an audit requirement

For regulated organizations the question is not only what a runner costs but what it can prove. Auditors want to see isolated execution, controlled images, and a complete record of which job ran on which capacity under which policy. A runner that cannot produce that record is a finding waiting to happen, regardless of how cheap it is to operate.

Self-service runner sprawl makes that record nearly impossible to assemble after the fact. When jobs run across self-hosted pools stood up ad hoc by different teams, the audit evidence is scattered, inconsistent, and often missing, so the platform team spends the run-up to every audit reconstructing a history that should have been captured automatically. Inconsistent audit logging is the second most-cited governance gap precisely because the sprawl that causes it is the first.

A centralized, policy-bound runner layer makes governance a property of the platform rather than a per-team scramble before each audit. When every job runs through one layer that enforces isolation, pins images, and emits a complete execution record by default, the audit story shifts from reconstruction to retrieval. The evidence exists because the platform produced it, not because someone remembered to log it.

Reliability at scale is mostly transient failures

When you run millions of jobs a month, even a low transient-failure rate translates into thousands of red builds a week. At enterprise volume the absolute count of mechanical failures is large even when the rate is small, and most of those failures are environmental rather than logical: registry timeouts, network blips, out-of-memory kills, and cold-start races.

These are not test bugs and they do not need engineers. The test code is fine; the environment hiccuped. But at scale the noise from these mechanical failures swamps the signal from genuine regressions, so engineers learn to reflexively re-run red checks, which both wastes their time and erodes the trust that a red check means something real.

Runners that automatically heal transient failures remove the largest, noisiest category of enterprise CI failures without any change to application code or test suites. Retrying the failed step on a fresh environment when it matches a known-transient signal keeps the mechanical failures from ever reaching a developer, which restores the signal value of a red check and lets the organization hold change-failure rate in the elite 0-15% band at scale.

Multi-org cost control needs attribution before optimization

You cannot reduce a cost you cannot attribute. The enterprises that bring CI spend down first solve attribution, tagging every minute to an org, a team, and a runner tier, and only then optimize. Cross-org cost attribution is the third most-cited governance gap, and it sits upstream of every cost lever, because an unattributed bill cannot be assigned, defended, or reduced by the teams generating it.

Without attribution, CI is an opaque shared cost that no single team feels accountable for, which is the worst possible incentive structure: everyone consumes freely because no one owns the bill. The org that cannot see its own CI spend has no reason to prune its matrix or cache its dependencies, because the savings disappear into a shared pool rather than showing up on its own line.

A managed runner layer that emits per-org, per-tier usage as a first-class output collapses the attribution problem and turns CI from an opaque shared cost into a line item each org can see and own. Once each org sees its own number, the optimization levers, right-sizing, caching, matrix pruning, get adopted bottom-up because the teams now have a reason to care. Attribution is what makes the rest of the cost work self-propelling rather than centrally enforced.

Isolation and image control are a single boundary, not two

Secret and isolation boundaries and patch and image drift show up as separate governance gaps in the survey, but at the fleet level they are two faces of the same control: what runs where, on what image, with access to what. A job that runs on an unmanaged runner with a stale image and ambient credentials is both an isolation failure and a drift failure at once.

Self-managed fleets struggle with both because images drift the moment they are not centrally rebuilt and redistributed, and isolation erodes the moment a runner is reused across jobs or teams. Each reused, drifted runner is a place where one job can observe or poison the next, and where a known-vulnerable image keeps running because no central process replaced it. The two gaps compound: a drifted image on a shared runner is the worst of both.

A managed layer that provisions a fresh, controlled image per job closes both gaps with one mechanism. Every job gets a clean, current, single-use environment, so there is no drift to accumulate and no shared state to leak. This is the same per-job isolation that delivers the reliability and audit benefits, which is why isolation, patching, audit, and reliability all resolve to the same architecture at enterprise scale rather than to four separate programs.

• Secret/isolation and image-drift gaps are two faces of one control: what runs where, on what image.
• Reused, drifted runners are where one job can poison the next and stale images keep running.
• A fresh controlled image per job closes both gaps with a single mechanism.

The seven-figure bill is mostly addressable, in the right order

A 1,200-engineer organization can model annual CI compute spend approaching the low millions across all runner tiers, which is large enough that even modest percentage reductions are material in absolute dollars. At that scale CI is a finance-visible line item, and the platform team is increasingly asked to defend it with the same rigor as any other seven-figure spend.

The good news is that most of that spend is addressable, but the sequence matters. Attribution comes first, because nothing can be reduced before it can be assigned. Consolidation comes next, because the levers can only be enforced once there is one place to enforce them. Then the cost levers land in order of impact: reclaiming idle through demand-scaled managed runners, then caching and matrix pruning, then tier right-sizing.

Run out of order, the program stalls: optimizing before attributing means teams have no reason to adopt the savings, and optimizing before consolidating means implementing each lever N times across N fleets. Run in order, the largest lever, managed migration that reclaims idle, lands first and funds the rest, while attribution makes the downstream optimization self-propelling. The cost-lever chart reflects this, with managed migration the dominant single move.

Recommendations

Consolidate the runner estate onto one policy-bound layer

Inventory every runner pool, hosted cost center, and shadow fleet, then consolidate onto a single managed runner layer with consistent policy. This is the prerequisite move: cost attribution, audit logging, isolation enforcement, and image patching each depend on having one place to enforce them, and implementing them across a fragmented estate means doing the work N times and proving it N times at audit.

Solve attribution before you optimize

Tag every CI minute to an org, a team, and a runner tier before launching any cost-reduction effort. An unattributed bill is a shared cost no team owns, so the optimization levers never get adopted bottom-up. Emit per-org, per-tier usage as a first-class output so each org sees its own number and has a reason to prune its matrix and cache its dependencies.

Reclaim idle capacity with demand-scaled runners

The largest single lever on a seven-figure CI bill is the idle fraction, which exceeds a third of capacity on a self-managed fleet provisioned for peak. Migrate to managed runners that scale to actual demand so you stop paying for capacity that sits idle off-peak. Unlike right-sizing or caching, this removes a slice that was never productive rather than trimming the productive portion.

Make isolation and image control one per-job mechanism

Provision a fresh, centrally controlled image per job so isolation and image-drift gaps close together. A single-use environment per job means there is no shared state to leak between jobs and no stale image to accumulate vulnerabilities, which closes the secret/isolation and patch/drift governance gaps with one mechanism rather than two separate programs.

Auto-heal transient failures to restore signal at scale

At millions of jobs a month, mechanical failures swamp genuine regressions and train engineers to reflexively re-run red checks. Retry transient failures on a fresh environment automatically so the mechanical noise never reaches a developer, which restores the signal value of a red check and holds change-failure rate in the elite band without per-team firefighting or manual re-runs.

Outlook

Expect the gap between governed and ungoverned enterprise CI to widen through 2026 and into 2027. As regulatory and audit expectations tighten, the organizations that have consolidated onto a policy-bound runner layer will treat audits as retrieval while their peers keep scrambling to reconstruct evidence from fragmented self-hosted fleets. Governance maturity, not platform-team headcount, becomes the real dividing line, since the platform team itself is now near-universal at scale.

On cost, the direction is toward attribution-first programs that push optimization down to the orgs generating the spend. As per-org, per-tier usage becomes a standard output rather than a custom reporting project, the cost levers, idle reclamation, caching, matrix pruning, right-sizing, get adopted bottom-up because each org can finally see and own its own line. The platform team shifts from enforcing savings centrally to enabling them, which scales far better across hundreds of teams.

For most platform leaders the practical takeaway is that the seven-figure CI bill and the audit burden are the same problem viewed from two angles, and they have the same answer: one consolidated, attributed, policy-bound, demand-scaled, self-healing runner layer. The organizations that internalize that converge their cost, governance, and reliability programs onto a single architecture, and they spend the next two years treating enterprise CI as a controlled, defensible line item while their peers keep paying for idle capacity they cannot see and reconstructing audits they cannot find.

Methodology

This report synthesizes publicly available industry data (platform engineering and cloud-native surveys, the DORA State of DevOps research, and published runner pricing) with Latchkey's own analysis of enterprise runner-fleet economics. Figures labeled "modeled" are illustrative estimates derived from public pricing, typical enterprise fleet utilization, and observed multi-org CI patterns, not a primary survey; figures attributed to a named source reflect that source. The managed-migration saving reflects a roughly 70% modeled reduction versus hosted rates. 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

• CNCF Annual Survey
• DORA State of DevOps Report
• GitHub - Octoverse
• GitHub Actions - billing & pricing

More Latchkey reports