The State of the CI/CD Tooling Landscape 2026

CI adoption has saturated, so the platform question has quietly become a runner-economics question: once every push triggers a pipeline, compute is the line item that scales.

Executive summary

CI/CD has crossed from optional discipline to default infrastructure. The large majority of professional teams now run automated pipelines on every push, and the open question is no longer whether to adopt CI but which platform carries it. The center of gravity in 2026 has moved decisively toward repo-native CI, where the pipeline definition lives next to the code as a file in the repository rather than on a separate server a platform team has to babysit.

That shift reframes what the platform decision actually is. When standing up a pipeline meant provisioning and maintaining a dedicated CI server, the platform was the hard part and the compute underneath it was an afterthought. When the pipeline is a file and runners attach with no server to manage, the platform becomes the easy part and the compute becomes the line item that scales. Once every push triggers a pipeline, the dominant variable cost is runner minutes, not seats or licenses, which is why a landscape report in 2026 has to talk about runners as much as platforms.

This report is careful about its sourcing, because the landscape is an area where confident-sounding numbers are often invented. Public developer research points clearly at the direction of travel, toward integrated, repo-native CI, without publishing precise vendor market share. So we separate the two cleanly. Adoption direction is cited to the Stack Overflow Developer Survey and GitHub Octoverse. Platform-by-platform share is presented as Latchkey modeled estimates derived from those public signals and observed pipeline mix, and it is labeled modeled everywhere it appears, never attributed as a vendor-reported figure.

Three numbers frame the year, with their sourcing made explicit. Roughly three quarters of professional developers report using CI/CD, a figure cited to public survey research. A modeled majority of CI usage runs on repo-native platforms, an estimate rather than a measured share. And integrated CI has been adopted at a modeled multiple of the rate of standalone CI servers since 2022, again an estimate of direction rather than a precise count. The first number is cited; the second and third are clearly labeled estimates.

The throughline is that platform and runner are separable choices, and the teams that separate them spend less. A team can run its pipelines on the platform its code already lives on while sourcing the actual compute from whichever runner layer is cheapest and most operationally sane for each workload. The platform war and the runner war are not the same war, and the most interesting movement in the 2026 landscape is happening underneath the platform logos, in the quieter decision about where the minutes are actually billed.

Repo-native CI is the default for new pipelines

The clearest signal in the public data is directional rather than precise: teams adopting CI today overwhelmingly start where their code already lives. When the pipeline definition is a file in the repository and runners attach with no separate server to provision, the time from an empty repository to a first green build collapses from days to minutes. There is no server to stand up, no agent to install, no platform team to file a ticket with, just a configuration file committed alongside the code.

The where-new-pipelines-start chart captures this in its modeled split. A clear majority of newly created pipelines this year land on repo-native platforms, with the remainder divided among standalone CI servers, cloud CI SaaS, and in-house scripting. The exact percentages are estimates and labeled as such, but the direction is well supported by the public adoption research: new pipelines gravitate to where the code is.

Standalone CI servers are not disappearing, and it would be wrong to read this as an obituary for them. They remain the platform of incumbency, carrying enormous amounts of existing pipeline logic that works and that nobody is rushing to rewrite. But they are increasingly the platform of record rather than the platform of first choice, and that distinction matters for the landscape: the installed base is large and durable, while the flow of new adoption points elsewhere.

• Repo-native pipelines collapse time-to-first-green-build from days to minutes, with no server to provision.
• A modeled majority of new pipelines this year start on repo-native platforms.
• Standalone CI servers persist as the platform of incumbency, not the platform of first choice.

Adoption has saturated, so the frontier is cost and speed

With the large majority of professional teams already on CI, the competitive frontier has moved. Vendors no longer win primarily by convincing teams to run pipelines at all, because nearly everyone already does. They win on how fast and how cheaply those pipelines run at scale, which is a fundamentally different axis of competition than the adoption-era pitch of getting teams onto CI in the first place.

This is the single most important consequence of saturation, and it reframes platform selection as a compute decision. Once every push triggers a pipeline, the dominant variable cost of CI is runner minutes. Seat counts and license tiers still matter at the margins, but they are roughly fixed against headcount, while runner minutes scale with the codebase, the branch count, the test suite, and the matrix. The bill that grows is the compute bill, so the choice that most affects the bill is the runner choice, not the platform logo.

The adoption-by-org-size chart, drawn from public survey direction, shows why the frontier has moved. Adoption climbs steeply with headcount and approaches the ceiling for organizations of any real size, which means there is very little adoption headroom left to compete over. When almost everyone already runs CI, the question stops being who runs pipelines and becomes whose pipelines are fast and cheap at scale, and that is a question about runners.

Platform share is consolidating, but Jenkins persists in the enterprise

Our modeled platform mix shows integrated, repo-native platforms leading new adoption while a substantial installed base of self-managed CI servers remains. The single largest modeled share sits with the dominant repo-native platform, GitLab CI holds a meaningful integrated slice, and a notable share remains on Jenkins, concentrated in larger and regulated organizations where the migration cost of moving years of accumulated pipeline logic is genuinely high. These figures are estimates and labeled modeled; they are not vendor-reported market share, and no precise share is attributed to any named vendor.

The honest reading of the platform-share chart is that it describes direction and rough proportion, not a measured census. What it shows fairly is a landscape in transition rather than a settled one: integrated platforms growing through new adoption, a large and sticky self-managed base that is shrinking only slowly, and a long tail of other tools. The pattern is a steady shift rather than a cliff, and the self-managed base is durable precisely because the work to migrate it is real.

Jenkins deserves a fair hearing here rather than a dismissal. It persists in the enterprise not out of inertia alone but because it is enormously flexible, deeply integrated into existing toolchains, and already working for pipelines that would be expensive and risky to rewrite. Most large organizations run more than one CI system at once during the transition, keeping the self-managed pipelines running while new work lands on integrated platforms, and that coexistence is the realistic shape of the landscape rather than a clean winner-takes-all.

Runner choice is the hidden axis of the landscape

Beneath the platform logos sits a quieter and increasingly consequential decision: where the compute actually comes from. The same platform can run its jobs on hosted runners, on self-hosted runners, or on managed runners, and that choice, not the platform brand, is what most determines the per-minute economics of the pipeline at scale. The landscape conversation tends to focus on the visible platform layer and skip the runner layer underneath, which is where the money increasingly is.

The three runner models trade off cleanly. Hosted runners are the easiest start and the priciest per minute at scale, which is fine until volume makes the per-minute rate the dominant cost. Self-hosted runners trade that per-minute price for an ongoing operational burden of patching, scaling, image maintenance, and security hardening that competes with shipping product. Managed runners aim to keep most of the per-minute savings of self-hosting while removing the ops, attaching to the existing platform rather than replacing it.

This is precisely why the platform war and the runner war are not the same war. A team can keep its pipelines on the repo-native platform its code already lives on and still change where the minutes are billed, swapping the runner layer underneath without touching the platform above. Latchkey sits in that managed lane, attaching to existing platforms rather than competing to be the platform, and targeting roughly 70 percent below hosted rates. The decision that moves the bill is the runner decision, and it is largely orthogonal to which platform logo sits on top.

• Hosted runners are the easiest start and the priciest per minute once volume scales.
• Self-hosted runners trade per-minute price for continuous patching, scaling, and image maintenance.
• Managed runners keep most of the savings without the ops and attach to the existing platform.

The fastest-moving teams treat CI as a portfolio, not a religion

Top-performing organizations in the public delivery research do not zealously standardize on one tool overnight, and they do not treat their CI platform as an identity to defend. They route workloads pragmatically, keep legacy pipelines running while new ones land on integrated CI, and move the expensive legs of the pipeline, the matrix builds and the heavy test suites, onto the cheapest viable runners regardless of which platform orchestrates them.

That portfolio mindset is what lets these teams avoid the two failure modes the landscape encourages. The first is a forced big-bang migration that rewrites years of working pipeline logic to chase a platform trend, paying enormous switching cost for marginal gain. The second is the opposite, freezing on an incumbent platform and its expensive default runners out of inertia, paying a compute premium indefinitely. The pragmatic path is neither: let new work flow to integrated CI naturally while optimizing the runner layer underneath everything.

The lesson of the 2026 landscape is therefore that platform and runner are separable choices, and the teams that separate them spend less without disruptive migrations. They keep the platform decision low-stakes by letting it follow where the code lives, and they keep the runner decision high-leverage by treating it as the cost lever it actually is. Treating CI as a portfolio of workloads on a mix of platforms and runners, rather than a single religion to convert to, is what the fastest-moving teams have in common.

Integrated CI makes pipelines cheap to start and compute the thing that scales

It is worth making explicit the mechanism that connects the adoption story to the cost story, because it is the engine of the whole landscape shift. Integrated, repo-native CI makes pipelines trivial to create: a file in the repository, runners that attach automatically, a green build in minutes. That ease is exactly why adoption saturated, and it is also why compute became the scaling cost, because when pipelines are nearly free to start, teams start a lot of them.

Cheap-to-start pipelines proliferate. A monorepo grows a pipeline per service, a team adds matrix dimensions because adding one is a one-line change, every branch gets full validation because the cost of triggering it is invisible at the point of authoring. None of these are mistakes; they are the natural behavior when the friction to create a pipeline approaches zero. But each of them adds runner minutes, and runner minutes are the cost that scales with the codebase rather than the headcount.

So the same property that made integrated CI win, frictionless pipeline creation, is the property that makes runner economics the central question of the landscape. The platform got so good at making pipelines cheap to start that it shifted the entire cost burden onto compute. A team that understands this stops shopping for a cheaper platform and starts managing its runner layer, because that is where the bill that actually grows is being written.

Migration is gradual and coexistence is the norm

The landscape data consistently shows transition rather than replacement, and that has practical consequences for how teams should think about platform choice. Large organizations rarely move from one CI system to another in a single decisive cut. They run the old and the new side by side for a long time, sometimes years, keeping the self-managed pipelines that work while new services and new teams default to integrated CI.

This coexistence is not a transitional inconvenience to be minimized; it is the steady state for most of the enterprise. A regulated organization with a large Jenkins estate and a growing repo-native footprint is not failing to migrate, it is rationally keeping working pipelines working while letting new adoption flow to the lower-friction option. The cost of forcing convergence usually exceeds the cost of running both, which is why both keep running.

For the runner layer, coexistence is actually an opportunity rather than a complication, because a managed runner can attach across multiple platforms at once. A team running both an incumbent CI server and a repo-native platform does not have to pick a single runner strategy per platform; it can route the expensive legs from either platform onto the same cheaper managed compute. The separability of platform and runner is what makes a gradual, coexisting migration affordable, because the cost optimization does not have to wait for the platform consolidation to finish.

Recommendations

Let the platform decision follow where the code lives

Keep the platform choice low-stakes by defaulting new pipelines to the repo-native option your code already sits in. Time-to-first-green-build collapses, there is no server to provision, and you avoid spending switching cost chasing a platform trend. The platform is no longer the hard part, so do not treat it as the expensive decision; the expensive decision is underneath it.

Treat the runner layer as the real cost lever

Once every push triggers a pipeline, runner minutes are the variable cost that scales, not seats. Separate the runner decision from the platform decision and optimize it deliberately: hosted for easy starts, self-hosted only where its ops burden is justified, managed to keep the savings without the ops. The bill that grows is the compute bill, so manage compute.

Do not force a big-bang platform migration

Coexistence is the steady state for most large organizations, not a failure to converge. Keep working pipelines on the incumbent platform while new work flows to integrated CI, and let the migration be gradual. The cost of forcing convergence usually exceeds the cost of running both, especially when a managed runner can serve both platforms at once.

Optimize the expensive legs onto the cheapest viable runners

Matrix builds and heavy test suites are where the minutes concentrate, regardless of which platform orchestrates them. Route those legs onto the cheapest runner that can run them correctly, and reshape OS-agnostic work off the expensive runner classes. This is a per-workload optimization that does not require changing platforms at all.

Run CI as a portfolio, not a single standard

The fastest-moving teams route workloads pragmatically across a mix of platforms and runners rather than converting everything to one tool. Keep legacy pipelines running, let new ones land on integrated CI, and standardize on the runner economics rather than the platform brand. Separating the two choices is what lets a team spend less without a disruptive migration.

Outlook

Expect the platform layer to keep commoditizing while the runner layer becomes the contested ground. As repo-native CI becomes the unremarkable default for new work, the platform decision will feel less and less like a strategic choice and more like picking the obvious option attached to your code host. The competition that remains will be about speed and cost at scale, and those are runner properties, which is why the runner war will outlast the platform war.

Coexistence will remain the norm rather than resolving into a single winner. The large self-managed installed base, concentrated in regulated and enterprise environments, will shrink slowly because migration cost is real, and most large organizations will continue running more than one CI system at once for years. The practical implication is that runner strategies which work across multiple platforms, rather than locking to one, will fit the actual landscape better than platform-specific ones.

For most teams the practical takeaway is to stop treating the platform as the expensive decision and start treating the runner as the one that scales. Default the platform to where the code lives, keep migrations gradual and coexisting, and put the real optimization effort into the runner layer where the growing bill is actually written. The organizations that internalize that platform and runner are separable choices will spend the next two years with cheaper, faster CI than their peers who keep fighting the wrong war.

Methodology

This report synthesizes publicly available adoption research, the Stack Overflow Developer Survey and GitHub Octoverse, for the direction of CI/CD adoption, combined with Latchkey analysis of observed pipeline and runner mix. Platform share figures are modeled estimates, not vendor-reported numbers, and are labeled as such throughout; no precise market-share percentage is attributed to any named vendor or survey. 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

• Stack Overflow Developer Survey
• GitHub - Octoverse
• JetBrains Developer Ecosystem Survey
• GitHub Actions documentation

More Latchkey reports