GitHub announces the end of free self-hosted runners for public repositories. Explore the infrastructure shift and alternative CI/CD strategies for 2026.
What free self-hosted runners actually bought you
Self-hosted runners on public repositories let maintainers run CI on their own machines while still using GitHub Actions for workflow definition, secrets, and status checks. That combination mattered for projects with heavy builds, proprietary toolchains, GPU or hardware access, long-running integration suites, or a need to avoid metered hosted minutes. The runner was free; the real costs were ops: patching the host, rotating credentials, keeping the runner process alive, and ensuring untrusted pull requests could not abuse the machine.
Ending free self-hosted runners for public repos forces a clean split. Workflows stay in the same YAML model, but the compute either moves back to GitHub-hosted runners or onto infrastructure you pay for and operate under a different billing or access model. Treat this as an infrastructure decision, not a branding one: you are choosing who owns the worker fleets, who bills for idle and peak capacity, and how untrusted code reaches that capacity.
Map jobs before you pick a replacement
Inventory every workflow by job type before you migrate. Separate fast unit tests from matrix builds, container image builds, release packaging, and jobs that need special hardware or network access. Note which jobs run on every pull request, which run only on protected branches, and which require secrets or write permissions. That map tells you what can stay on hosted runners, what needs a paid self-hosted path, and what should leave Actions entirely.
Also classify trust boundaries. Public forks and drive-by pull requests are a different risk profile than pushes from maintainers. If a job touches production credentials, signing keys, or a shared build cache on a durable host, it should not run on the same class of runner as untrusted PR checks. Re-home high-trust jobs first; leave low-risk lint and unit tests on the cheapest, most isolated option you can sustain.
Practical CI/CD paths for 2026
- Hosted runners for the common path: Keep default PR checks on GitHub-hosted runners where minutes and concurrency fit. Cache dependencies aggressively, split large matrices, and fail fast so you spend less on redundant work.
- Paid or private self-hosted only where justified: Reserve dedicated workers for hardware, licensed tools, or builds that are clearly cheaper on machines you already run. Document ownership, update cadence, and how PRs are gated before they touch those hosts.
- External CI for specialized fleets: Point status checks at another CI system when you already operate build agents elsewhere. Keep the GitHub side thin: checkout, dispatch, and report status rather than duplicating every job in two places.
- Fewer, sharper pipelines: Collapse duplicate workflows, drop jobs that do not block merges, and move non-blocking work to scheduled or manual runs so day-to-day PR cost stays predictable.
Whatever path you choose, make cost and failure modes visible. Track minutes or agent hours per workflow, set concurrency caps, and define what happens when a runner pool is full or offline. A pipeline that works only when a volunteer’s laptop is online is not a strategy.
Migration checklist without the drama
Start with a single high-traffic repository. Replace free self-hosted labels with hosted or alternative runners job by job, keep branch protection rules pointing at the same required checks, and verify forks still get safe, limited CI. Capture secrets and environment names that were only available on the old hosts. After green builds on main and a few real pull requests, roll the pattern to sibling repos rather than rewriting every workflow at once.
The lasting shift is operational: public projects can no longer assume free on-prem style workers inside GitHub’s runner model. Design for hosted defaults, paid capacity only where it pays back, clear isolation for untrusted code, and pipelines you can measure and explain. That is enough structure to absorb this change without freezing releases or reinventing your entire delivery process.