The State of Open Source CI 2026

Free CI built the open-source world, and in 2026 the bill, the fork security model, and the maintainer's time are all under strain at the same moment.

Executive summary

Open source runs on free CI. The generous free tiers that hosted providers extend to public repositories are one of the quiet subsidies that make the modern ecosystem possible, and most projects never come close to the limit. A weekend library with a handful of contributors and a small test suite lives comfortably inside the free allowance for its entire life, which is exactly the design intent and exactly why the subsidy works. The strain does not show up in the average. It shows up in the tail.

That tail is where the ecosystem actually lives. The popular, dependency-heavy projects that everyone relies on, the ones whose names appear in a million package manifests, are the projects most likely to blow through the free allowance, and they tend to do it at the worst possible moment: during a release crunch when contributions and CI demand spike together. When a critical dependency cannot run CI because it has exhausted its minutes, the cost is not borne by that one project, it is borne by everyone downstream waiting on the release.

Two other pressures compound the cost problem. The fork-and-pull-request security model means a maintainer must decide, on every outside contribution, whether to run untrusted code against project secrets and minutes, a decision with no good default. And the build burden itself falls on a small number of volunteers who triage red pipelines, re-run flaky jobs, and keep a broad cross-platform matrix green on their own unpaid time. Money is one scarce resource in open source, but maintainer attention is the scarcer one, and CI taxes both.

This report quantifies where OSS CI minutes go, how the burden concentrates on popular projects and individual maintainers, how the fork security model shapes day-to-day maintainer behavior, and how managed runners and self-healing recovery reduce both the bill and the manual toil. We look at the distribution of minutes across project tiers, the approaches maintainers actually use for fork PR builds, the split of where minutes are spent inside a typical multi-platform library, and the maintainer hours that transient failures quietly consume.

The encouraging finding is that the two scarce resources, money and maintainer time, respond to the same set of fixes. Caching across the cross-platform matrix recovers minutes; skipping unchanged legs recovers more; and automated recovery of transient failures recovers the maintainer hours that would otherwise go to clicking re-run on jobs that were never really broken. For a project that has outgrown the free tier, a managed runner layer with self-healing is not just cheaper compute, it is fewer hours stolen from the work the project exists to do.

The free tier works until a project gets popular

Free CI minutes comfortably cover the long tail of open-source projects, which is exactly the design intent and the reason the subsidy is sustainable. The overwhelming majority of public repositories run a small suite a few times a week and never approach the allowance. For them the free tier is invisible infrastructure, and that is how it should be.

The problem is concentrated at the head. A small number of popular and critical-dependency projects consume minutes far out of proportion to their count, because they carry large cross-platform matrices, heavy dependency graphs, and a constant stream of contributions that each trigger a full pipeline. Those are precisely the projects the rest of the ecosystem depends on, which means their CI constraints are everyone's constraints.

When a critical dependency hits the limit during a release crunch, the failure radiates outward. Downstream projects waiting on a fix, a security patch, or a new release stall because the upstream pipeline cannot run. The chart below shows just how steep the distribution is: a popular project burns several times the minutes of the median, and a critical dependency burns an order of magnitude more, which is where the free-tier model strains hardest.

Fork PRs force a security trade-off on every contribution

Running CI on an outside contribution means running untrusted code, and that is the structural tension at the heart of open-source CI. A pull request from a fork can contain a workflow change or a build script that, if run with the project's secrets and minutes, could exfiltrate credentials, mine cryptocurrency, or simply burn the allowance out of spite. The maintainer has to make a security decision on every contribution, and there is no default that is both safe and frictionless.

Most maintainers settle on manual approval or withholding secrets from fork builds. Both are safe, and both add a human gate to the very thing open source depends on: easy outside participation. A first-time contributor whose PR sits unbuilt until a maintainer wakes up and clicks approve is a contributor who may not come back, and the friction is heaviest exactly for the newcomers the project most wants to welcome.

The approaches in use form a clear hierarchy of caution, shown in the chart below. Manual approval per PR is the most common and the most conservative; approving first-time contributors only is a middle ground; withholding secrets from fork builds trades some test coverage for safety; and running everything automatically is rare because the risk is real. The right answer for most projects is isolation rather than trust: ephemeral, secret-free environments for fork builds so untrusted code cannot reach anything valuable.

• Manual approval per PR is the most common posture and the safest, but it gates every contribution behind a human.
• Withholding secrets from fork builds trades coverage for safety and is a sensible default for untrusted code.
• Ephemeral, isolated, secret-free environments let fork CI run automatically without exposing anything worth stealing.

Flaky re-runs are a maintainer tax, paid in hours

A large share of red OSS pipelines are not real failures. They are flaky cross-platform jobs that pass on the next run, registry timeouts pulling a dependency, and transient network blips on one leg of a wide matrix. The test code is fine; the environment hiccuped. But someone has to notice the red check, decide it is not real, and click re-run, and on a busy project that someone is an unpaid volunteer.

The time adds up faster than it looks. A popular project without automated recovery can lose double-digit maintainer hours a month just to clicking re-run and re-triaging jobs that were never broken, and that time comes straight out of the volunteer budget that would otherwise go to reviewing contributions, writing docs, or fixing real bugs. It is the most demoralizing kind of work because it produces nothing.

Self-healing runners change this directly. When a job fails on a known-transient signal, the platform retries it on a fresh environment automatically, before the maintainer ever sees a red check. The chart below shows the effect: a popular project that adopts self-healing recovery cuts its monthly CI toil by roughly two-thirds, reclaiming hours that go back into the project rather than into babysitting the pipeline.

• Transient cross-platform flakes, registry timeouts, and network blips dominate red OSS pipelines, not real regressions.
• A popular project without auto-heal can lose double-digit maintainer hours a month to re-running clean failures.
• Self-healing recovery cuts that toil by roughly two-thirds by retrying transient failures before a human is involved.

The cross-platform matrix is where the minutes hide

Open-source libraries pride themselves on broad support, and rightly so: a library that works on Linux, macOS, and Windows across several language versions is more trustworthy than one tested on a single configuration. But the matrix that proves that breadth is the single largest consumer of CI minutes for a typical project, often more than a third of the total, because the full suite reruns on every cell.

Most of that work is redundant. The same dependencies install on every leg, the same fixtures build, and the bulk of the test suite behaves identically across platforms, with only a small genuinely platform-specific surface justifying the fan-out. When the matrix runs cold on every push, the project pays full price for proving the same thing many times over.

Caching dependencies across the matrix and skipping legs whose inputs have not changed recovers a large fraction of those minutes without giving up the coverage that makes the project trustworthy. The chart below shows the cross-platform matrix as the dominant slice of where OSS minutes go, which is exactly why it is the first place a cost-constrained project should look.

Caching is the highest-ROI lever a maintainer underuses

Dependency installation that recomputes unchanged work is the quiet second-largest consumer of OSS CI minutes after the matrix itself. Every leg of the matrix that resolves and downloads the same dependency set cold is paying for work that produced a bit-for-bit identical result on the last run, and across a wide matrix that waste is multiplied by the number of cells.

Caching is conceptually simple and operationally finicky, which is why many maintainers do it badly or skip it under time pressure. A cache keyed too loosely serves stale dependencies and produces baffling failures; a cache keyed too tightly almost never hits. The projects that get it right scope the key to the lockfile and toolchain version and share the cache across matrix legs so one cold resolve warms the rest.

For a volunteer-run project the appeal of caching is not just the reclaimed minutes, it is that the reclaimed minutes are free of maintainer effort once set up. Unlike triaging flakes, a working cache pays back silently on every run forever. A managed runner with a shared cache layer makes that persistence the default rather than something each project wires up and then has to maintain.

The supply chain runs through the maintainer who runs the CI

Open-source CI is not just a cost and toil problem, it is increasingly a security one, because the projects that consume the most minutes are also the most-depended-on links in everyone else's supply chain. A compromise of a popular project's pipeline is a compromise of every downstream consumer, which makes the maintainer's CI configuration a piece of shared critical infrastructure that the maintainer alone is rarely resourced to defend.

The fork-PR problem is one face of this, but the larger exposure is the standing pipeline itself: long-lived secrets stored in the CI configuration, shared runners that carry state between builds, and dependency steps that pull from registries on every run. Each is a place a poisoned dependency or a leaked token can do lasting damage, and a single volunteer maintainer is a thin line of defense against a determined attacker who understands exactly how much leverage a critical-dependency pipeline carries.

The mitigations are the same architecture that solves the cost and toil problems, which is what makes adopting them realistic for a volunteer project. Short-lived credentials instead of stored secrets, ephemeral single-use runner environments that cannot carry a poisoned cache from one build to the next, and isolated fork builds together close the most common classes of CI supply-chain incident, and they do it as a property of the runner layer rather than as ongoing vigilance the maintainer has to sustain by hand.

• A popular project's pipeline is shared supply-chain infrastructure, defended by a single volunteer.
• Stored secrets, shared stateful runners, and per-run registry pulls are the main standing exposures.
• Short-lived credentials plus ephemeral single-use environments close the common incident classes at the runner layer.

Managed and self-healing runners ease the burden on both axes

For projects that outgrow the free tier, the per-minute cost of CI becomes a real budget question, and managed runners cut that cost substantially compared with paying hosted overage rates. A project that has crossed into the popular or critical-dependency tier, where minutes run into the thousands per month, sees the most benefit precisely because it has the most minutes to make cheaper.

The reliability axis matters as much as the cost axis for open source, arguably more, because maintainer time is the scarcer resource. Self-healing recovery absorbs the transient failures that drive the re-run toil, so the hours a maintainer would have spent clicking re-run go back into the project. The two effects are independent: one shrinks the bill, the other shrinks the toil, and a project past the free tier usually needs both.

The architecture that delivers this is the same one that solves the fork-security problem. Ephemeral, isolated, per-job environments give fork builds a place to run untrusted code safely, give the matrix a clean environment that eliminates state-bleed flakes, and give self-healing a fresh environment to retry into. For a maintained open-source project, that single architecture answers the cost question, the security question, and the toil question at once.

Recommendations

Cache dependencies across every matrix leg

Scope the cache key to the lockfile and toolchain version and share it across platform legs so one cold resolve warms the rest. Dependency install is the largest recoverable block after the matrix itself, and a working cache pays back silently on every run with no further maintainer effort.

Run fork PRs in isolated, secret-free environments

Instead of choosing between gating every contribution and exposing secrets, run untrusted fork code in ephemeral environments with no access to credentials or sensitive minutes. This lets fork CI run automatically and safely, removing the human approval gate that drives away first-time contributors.

Slim the matrix on the hot path

Run a single representative configuration on every push for fast feedback and reserve the full cross-platform, multi-version matrix for nightly and pre-release runs. This keeps contributor feedback fast while preserving the broad coverage that makes the project trustworthy, and it caps the flake exposure that a wide matrix multiplies.

Auto-heal transient failures so they never reach a maintainer

Cross-platform flakes, registry timeouts, and network blips pass on a clean retry. Retrying automatically on a fresh environment removes the re-run minutes and reclaims the double-digit maintainer hours a busy project otherwise loses every month to clicking re-run on jobs that were never broken.

Move popular projects to managed runners before the next crunch

A project in the popular or critical-dependency tier has both the most minutes to make cheaper and the most contributions to keep flowing during a release. Adopting a managed runner layer ahead of the crunch, rather than during it, removes the free-tier ceiling as a release-time risk and shrinks the bill at the same time.

Outlook

Expect the strain at the head of the distribution to intensify through 2026. The most-depended-on projects keep accumulating dependencies, contributors, and platform targets, and each addition widens the matrix and deepens the install graph, so their CI demand grows faster than the projects themselves. The free-tier model will keep working beautifully for the long tail and keep straining hardest exactly where the ecosystem can least afford a stalled release.

The security model is converging on isolation rather than trust. As supply-chain attacks through CI become a more common headline, the maintainer practice of running untrusted fork code in ephemeral, secret-free environments will shift from a careful minority position to the expected default. The same per-job isolation that makes fork builds safe also eliminates a category of cross-platform state-bleed flakes, so the security and reliability stories point at one architecture.

For maintainers the practical takeaway is that the scarcest resource, their own time, is recoverable with the same moves that recover minutes. A shared cache, a slim hot-path matrix, isolated fork builds, and automated recovery of transient failures together shrink the bill and the toil at once. The projects that adopt them will spend the next two years shipping releases on time and welcoming contributors without friction, while the projects that do not will keep paying both costs out of the same exhausted volunteer budget.

Methodology

This report combines publicly available ecosystem data, including GitHub Octoverse figures on developer and project counts, with Latchkey's own analysis of open-source CI economics. Modeled figures reflect representative project tiers, from a small personal repository to a critical dependency carrying a wide cross-platform matrix and a heavy dependency graph. Maintainer-practice shares for fork PR handling are synthesized from public maintainer behavior and shown as relative weights rather than a surveyed population. Free-tier allowances and pricing reflect published terms at time of writing and should be verified against current provider terms. 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
• GitHub Actions - billing & pricing
• Stack Overflow Developer Survey
• CNCF Annual Survey

More Latchkey reports