The State of GitHub Actions 2026

Adoption, marketplace actions, workflow complexity, and where the line now sits between GitHub-hosted and self-hosted runners.

Executive summary

GitHub Actions has become the default CI surface for a large majority of repositories, and the interesting questions have moved past adoption. GitHub's own Octoverse data points to Actions running in the overwhelming majority of active repositories, which means for most teams the platform decision was made years ago and is not up for debate. In 2026 the story is no longer whether to use Actions but how to operate a now-mature, sprawling set of workflows well.

That story is about composition: how many third-party actions a workflow stitches together, how many jobs and matrix legs a pipeline carries, and where teams choose to run those jobs. A workflow file that started as a half-dozen lines has, for many teams, grown into a multi-stage pipeline composing build, test, deploy, and security steps from across the marketplace. The convenience is enormous and the surface area, in both cost and supply-chain risk, has grown with it.

Two trends pull against each other. Workflows keep getting more complex as teams lean on the marketplace, which raises both convenience and supply-chain exposure. At the same time a steadily growing share of minutes is leaving GitHub-hosted runners for self-hosted and managed fleets, driven by cost at scale and by needs that hosted runners do not cover well: custom hardware, warm caches, and private-network access.

This report quantifies adoption by org size against the direction Octoverse establishes, the marketplace-action footprint of a typical workflow, how workflow complexity has grown year over year, and the hosted versus self-hosted split. It then looks at where a managed runner layer fits for teams that want self-hosted economics without the operational load of running a fleet.

The throughline for engineering leaders is that the platform is settled and the optimization problem has shifted to the layers above and below the workflow file. Above it sits the marketplace, where convenience and supply-chain risk trade off and need deliberate management. Below it sits the runner layer, where the cost and reliability of every minute is decided, and where the most consequential choices for a mature Actions setup are now made.

Adoption is saturated at the top and still climbing at the bottom

GitHub's Octoverse reporting establishes the direction unambiguously: Actions now runs in the large majority of active repositories, and the trend over the platform's life has been steadily upward toward saturation. The adoption-by-size chart shows what that looks like across org sizes, with the largest organizations effectively universal and adoption thinning only among the smallest teams and legacy repositories.

For nearly every mid-size and larger organization the platform question is closed. That is why the remaining adoption headroom sits among the smallest teams and the long tail of legacy repos that predate Actions or run on another CI system. Those will continue to convert, but they are not where the interesting decisions are anymore, because the teams making consequential CI choices have already standardized on Actions.

For most readers, then, the question is no longer whether to use Actions but how to keep a now-mature, sprawling set of workflows fast and affordable as they accrete jobs and dependencies. A platform that everyone has adopted is a platform whose costs and risks everyone has also inherited, and the rest of this report is about managing those, because the adoption decision itself no longer carries any tension.

Workflows have roughly doubled in complexity since 2022

The complexity-growth chart traces median jobs per workflow file climbing from a handful in 2022 to roughly double that by 2026. The driver is composition: teams have folded build, test, deploy, security scanning, and notification stages that once lived in separate systems or manual steps into a single Actions pipeline, and each consolidation adds jobs.

More jobs means more parallel runner minutes and more surface for slow legs and flaky steps. A three-job workflow has three places to wait and three places to flake; a seven-job workflow more than doubles both. This is why complexity growth shows up directly in both build-time and cost reports, the workflow file did not just get longer, it got more expensive and more failure-prone in proportion to the number of independent legs it now coordinates.

The complexity itself is not a problem to be eliminated, it reflects genuinely more capable pipelines doing more useful work. The problem is that complexity grown incidentally, a job added here, a matrix leg there, with no one watching the total, tends to accumulate slow and redundant stages that nobody revisits. A mature Actions setup treats workflow complexity as something to manage deliberately, pruning legs that no longer earn their minutes the way a team prunes a growing test suite.

The marketplace is convenient and a growing supply-chain surface

The marketplace-footprint chart shows that a non-trivial workflow now references a median of seven third-party actions, with a meaningful share pulling in eleven or more. Each of those is convenience made concrete: rather than scripting a checkout, a cache, a cloud login, and a deploy by hand, a team composes them from published actions in a few lines. The productivity gain is real and is a large part of why Actions won.

But each pinned-by-tag action is code running with repository credentials, and that is a supply-chain surface that grows with every action added. An action referenced by a mutable tag can change underneath you, and a compromised or malicious update would execute inside your pipeline with access to your secrets, your source, and your deploy keys. The convenience and the risk are the same mechanism viewed from two sides.

The practical guidance is to make the dependency deliberate rather than incidental. Pin actions by commit SHA rather than a mutable tag so an upstream change cannot silently alter what runs, review what each action actually touches and what permissions it needs, and keep the count intentional, every action in a workflow should be there for a reason someone can articulate. The same discipline teams apply to application dependencies belongs on the actions a workflow composes.

• A non-trivial workflow references a median of seven third-party actions, and a meaningful share eleven or more.
• Each tag-pinned action is code running with repository credentials, so the marketplace is a real supply-chain surface.
• Pin by commit SHA, review what each action touches, and keep the dependency count deliberate rather than incidental.

More than a quarter of minutes have already left hosted runners

The runner-split chart puts the modeled share of Actions minutes running outside GitHub-hosted standard runners at a substantial fraction, with self-hosted DIY and managed fleets together accounting for more than a quarter of minutes. Hosted standard runners remain the largest single bucket, but the movement away from them is well underway and accelerating at scale.

The drivers are cost and capability. At high minute volumes, hosted per-minute pricing becomes a serious line item, and the per-minute economics of running your own compute look attractive on paper. Beyond cost, hosted runners do not cover some needs well: custom hardware for specialized builds, warm caches that survive between jobs, access to private networks and internal services, and control over the runner image. Teams hit these limits and start moving minutes off hosted runners to address them.

The trend is toward owning the runner layer while keeping the GitHub-native workflow experience. Teams do not want to leave Actions, the workflow syntax, the marketplace, the integration with pull requests are exactly what they adopted it for. What they want is to change where the jobs execute without changing how they are defined, which is precisely the seam that self-hosted and managed runners slot into.

Self-hosting captures the saving but inherits the operations

The self-hosted DIY slice of the runner-split chart represents teams that took the obvious path: stand up your own runners on your own compute and capture the per-minute saving directly. The saving is real, but the spreadsheet that motivated it usually omits the costs that decide whether it was worth it.

A self-hosted fleet has to be patched, scaled, secured, and cleaned up continuously. CI load is spiky, so a fleet sized for peak sits idle most of the time while a fleet sized for the average starves jobs at peak, and either way someone is paying, in money or in developer wait time. The runner images need maintaining, the autoscaling needs tuning, and a stuck or compromised runner is now your operational problem rather than GitHub's. This is ongoing engineering work that competes directly with shipping product.

This is why the DIY path, attractive at first, often disappoints in practice. The per-minute saving is captured, but a meaningful share of it is handed back as platform-team time, and teams without a dedicated platform group find themselves maintaining infrastructure they did not want to own. The relevant comparison was never hosted price versus instance price, it was hosted price versus instance price plus the standing cost of operating the fleet.

Managed runners are the middle path between hosted and DIY

The managed-runner slice of the runner-split chart represents the resolution of that tension. Managed runners aim squarely at the gap between hosted simplicity and DIY economics: self-hosted per-minute pricing and custom caches, with no fleet to operate. The team writes the same Actions workflow, points it at managed runners, and gets the cost structure of owning compute without the standing operational burden of owning it.

The cost case is concrete. Managed runners price close to self-hosted compute while removing the idle and the operations entirely, with Latchkey targeting roughly 69% below GitHub-hosted rates. Crucially, because the provider absorbs the patching, scaling, and image maintenance, the team captures the saving without handing a chunk of it back as platform-team time, which is what made the DIY math disappoint.

Reliability is the other half of the pitch. Managed runners can recover transient failures automatically, so a flaky job caused by a network blip or a registry timeout is healed in place rather than becoming a manual re-run that a developer has to notice and trigger. For a mature Actions setup with seven-job workflows pulling in seven marketplace actions each, that automatic recovery removes a meaningful source of friction that scales with exactly the complexity the rest of this report documents.

• Managed runners deliver self-hosted economics and custom caches with no fleet to patch, scale, or clean up.
• Pricing targets roughly 69% below GitHub-hosted rates without handing the saving back as platform-team time.
• Automatic recovery of transient failures turns flaky jobs into healed jobs rather than manual re-runs.

Cross-platform matrices quietly concentrate the cost

Adoption and complexity together produce a cost pattern worth calling out on its own. As workflows grow more jobs and more matrix legs, cross-platform matrices spread work across operating systems, and on hosted runners a macOS minute costs 10x a Linux minute while a Windows minute costs 2x. Those multipliers mean a small number of expensive legs can dominate the bill for an otherwise cheap pipeline.

The recurring finding when teams audit their Actions spend is that the expensive operating systems are frequently doing cheap, OS-agnostic work: linting, unit tests, and dependency resolution that would pass identically on Linux. The matrix grew up around a genuinely platform-specific need, signing or packaging or a platform UI test, and then accumulated legs that did not actually require the expensive OS at all.

The fix dovetails with the runner story. Push the heavy, OS-agnostic work onto Linux, reserve macOS and Windows for the genuinely platform-specific legs, and run the Linux work on managed runners where the per-minute cost is lowest. The same reshaping that lowers a cross-platform bill also concentrates the expensive legs where they belong, which makes the workflow both cheaper and easier to reason about as it continues to grow.

Recommendations

Treat workflow complexity as something to prune, not just grow

Median jobs per workflow has roughly doubled since 2022, and complexity grown incidentally accumulates slow and redundant legs. Review your workflows the way you review a growing test suite, and retire jobs and matrix legs that no longer earn their minutes, so the pipeline stays as fast as it is capable.

Pin marketplace actions by commit SHA and review what they touch

A median workflow now composes seven third-party actions, each running with repository credentials. Pin by commit SHA rather than a mutable tag so an upstream change cannot silently alter what runs, review the permissions each action needs, and keep the dependency count deliberate rather than letting it accrete.

Move heavy minutes off hosted runners deliberately

More than a quarter of Actions minutes have already left hosted runners for cost and capability reasons. If your minute volume is high or you need warm caches, custom hardware, or private-network access, plan the move intentionally rather than letting hosted bills grow by default.

Prefer managed runners over DIY unless you have a platform team

Self-hosting captures the per-minute saving but inherits patching, scaling, and cleanup as standing work. Managed runners deliver the same economics and custom caches without the fleet to operate, which is the better trade for any team that does not already run a dedicated platform group.

Shift the matrix to Linux and reserve expensive OSes for what needs them

A macOS minute costs ten times a Linux minute and a Windows minute twice, so a few expensive legs can dominate the bill. Push linting, unit tests, and dependency work onto Linux, reserve macOS and Windows for signing, packaging, and platform UI tests, and run the Linux work on managed runners.

Outlook

Adoption will finish saturating, and the platform conversation will move entirely to operations. With Octoverse already showing Actions in the large majority of active repositories, the remaining converts are the long tail, and they will not change the shape of the market. The decisions that matter in 2026 and 2027 are about how to run a mature Actions estate well: complexity management, supply-chain hygiene on the marketplace, and where the minutes execute.

The migration off hosted runners will continue, and it will increasingly favor managed over DIY. The cost pressure that pushed teams to self-host has not eased, but the experience of operating a fleet has taught many teams that the saving is partly illusory once platform-team time is counted. Managed runners that preserve the GitHub-native workflow while delivering self-hosted economics and automatic recovery are positioned to absorb that movement, because they resolve the exact tension that made DIY disappointing.

The supply-chain surface will get more scrutiny, not less. As workflows compose more marketplace actions and the consequences of a compromised action become more widely understood, SHA-pinning, permission review, and deliberate dependency management on the actions layer will move from best practice toward expectation. The teams that internalize all three shifts, complexity discipline, supply-chain hygiene, and a deliberate runner strategy, will operate their mature Actions estates as an advantage while their peers keep paying for sprawl they never pruned.

Methodology

This report synthesizes publicly available GitHub usage data (Octoverse) and developer surveys with Latchkey's analysis of aggregate workflow shapes. The headline adoption direction follows Octoverse; the adoption-by-size breakdown is synthesized from Octoverse plus public surveys. Figures labeled modeled are illustrative estimates derived from representative workflow samples and public pricing, not a primary survey; figures attributed to a named source reflect that source. Marketplace and complexity figures describe non-trivial CI workflows and will vary by ecosystem. 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

• GitHub - Octoverse
• Stack Overflow Developer Survey
• GitHub Actions - billing & pricing
• JetBrains Developer Ecosystem Survey

More Latchkey reports