GitHub-hosted Linux runners should not be Ubuntu-only

[je4yfc]

🏷️ Discussion Type

Product Feedback

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

GitHub's current position is that its hosted Linux runners are Ubuntu-based, and the actions/runner-images project states that GitHub does not plan to offer other Linux distributions. The recommended alternatives are Docker or self-hosted runners. I strongly disagree with that policy, specifically because the chosen distribution is Ubuntu and therefore because GitHub's Linux runner environment is tied to Canonical's technical direction, licensing choices, and commercial priorities. I have no objection to GitHub standardizing on a Linux distribution for its hosted runners. Debian would be an entirely reasonable default. Fedora would be an entirely reasonable default. AlmaLinux or Rocky Linux would also be defensible choices.

The problem is Ubuntu.

Canonical has repeatedly demonstrated that I do not want its engineering decisions determining my Linux environment

• Canonical has a long history of pursuing major strategic initiatives and subsequently abandoning them. The most obvious example was its convergence strategy: Ubuntu Phone, Unity8, and the associated phone/desktop convergence effort. In 2017, Canonical formally ended its investment in Unity8 and Ubuntu Phone after years of positioning convergence as an important part of Ubuntu's future.
• More recently, Canonical has undertaken another significant platform-level experiment by replacing GNU implementations of fundamental Unix utilities with Rust rewrites. Ubuntu 25.10 made uutils coreutils the default, replacing GNU coreutils for most commands, and Ubuntu 26.04 continued that transition.
• The GNU Project explicitly declines to endorse Ubuntu, citing Canonical's promotion of non-free software and concerns over Snap's Canonical-controlled distribution infrastructure.
• Richard Stallman and the GNU Project publicly condemned Ubuntu's former desktop search integration after local searches were transmitted to Canonical and used to provide Amazon results. The functionality was eventually disabled by default, but the episode remains one of the more infamous conflicts between Canonical's product decisions and the free-software movement.

This is such a huge slap in the face for the entire open source community. That transition illustrates exactly why I do not want Canonical's engineering choices implicitly imposed on every GitHub-hosted Linux runner. It explicitly aims to reproduce GNU coreutils behaviour while replacing the GNU implementation.

GNU coreutils is GPLv3-or-later software maintained as part of the GNU project. uutils is a ground-up reimplementation under the permissive MIT licence. There is a meaningful philosophical difference between supporting the GNU project's copyleft implementation and replacing it with permissively licensed substitutes. Canonical is entitled to make that choice for Ubuntu. I do not believe GitHub should make Canonical's choice effectively synonymous with "Linux" for hosted Actions runners.

There are also concrete engineering reasons not to treat this transition as an unquestionably superior foundation.

• Canonical's own security process for rust-coreutils found 113 issues during its external audit. For Ubuntu 26.04 LTS, Canonical retained GNU implementations of cp, mv, and rm because unresolved issues remained in the replacements. Canonical stated that eight TOCTOU issues were still open as of April 2026.

• Ubuntu has also published vulnerabilities arising from behavioural and security differences in the new implementation, including problems involving cp, mv, mkfifo, dd, env, and other utilities. These include a high-severity TOCTOU vulnerability in mkfifo and cases where behaviour differs materially from GNU coreutils.

• And then there is Canonical's increasingly close commercial relationship with Microsoft - historically one of the most aggressive opponents of the free-software ecosystem, or, less diplomatically, the devil of the open-source world.

• Canonical and Microsoft have collaborated on Ubuntu in Azure since at least 2012, subsequently deepening that relationship around Ubuntu Pro, Azure integration, and Microsoft security products.

Canonical is free to make those commercial decisions. But GitHub is also Microsoft.

When Microsoft's CI platform declares that the only first-class hosted Linux distribution will be Ubuntu, while Canonical and Microsoft maintain a substantial commercial and technical partnership, it is reasonable to question why GitHub will not provide even one mainstream alternative.

I am therefore asking GitHub to reconsider its stated policy and provide at least one first-class GitHub-hosted Linux runner that is not Ubuntu.

At minimum, reasonable alternatives would include:

• Debian Stable
• Fedora
• AlmaLinux or Rocky Linux

This does not require removing Ubuntu. Users who want Ubuntu should continue to have it.

But Ubuntu is one Linux distribution, not Linux itself, and Canonical's technical and commercial direction should not be the only Linux environment available from GitHub-hosted Actions runners.

Please reconsider the Ubuntu-only policy for GitHub-hosted Linux runners.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[hoangperry]

Your objection is to the host distribution specifically, so to keep the practical options honest alongside the policy ask:

1. container: jobs get you a non-Ubuntu userland today — Debian, Fedora, Alpine, Rocky, whatever image you point at. Everything your job executes (toolchains, libc, package manager) is that distro's. What you can't escape is Canonical's kernel and host stack, which sounds like the core of your concern — but it does mean the "tied to Ubuntu's technical direction" surface is limited to the kernel/runtime layer, not your build environment.
2. Self-hosted / ARC is the full answer to distro sovereignty — since you're already filing this under ARC: runner hosts can be any distro you trust, and GitHub's position (as you note from runner-images) makes clear that's the supported path for anyone with distribution requirements.
3. If the concern is reproducibility/neutrality rather than Ubuntu per se, pinning everything into the container image also insulates you from the runner-image churn that hits people on ubuntu-latest twice a year.

On the ask itself: the historical blocker is that each hosted image is a large maintained artifact (toolcache, preinstalled software matrix), so a second distro roughly doubles that surface — which is why the stance has held even through repeated requests. A more winnable framing might be a minimal hosted image (kernel + container runtime only, no preinstalled toolchain), which sidesteps the maintenance-matrix argument while giving distro-neutral users what they actually run: containers.

[je4yfc]

Your objection is to the host distribution specifically, so to keep the practical options honest alongside the policy ask:

1. **`container:` jobs get you a non-Ubuntu userland today** — Debian, Fedora, Alpine, Rocky, whatever image you point at. Everything your job executes (toolchains, libc, package manager) is that distro's. What you can't escape is Canonical's _kernel and host stack_, which sounds like the core of your concern — but it does mean the "tied to Ubuntu's technical direction" surface is limited to the kernel/runtime layer, not your build environment.

2. **Self-hosted / ARC is the full answer to distro sovereignty** — since you're already filing this under ARC: runner hosts can be any distro you trust, and GitHub's position (as you note from `runner-images`) makes clear that's the supported path for anyone with distribution requirements.

3. If the concern is reproducibility/neutrality rather than Ubuntu per se, pinning everything into the container image also insulates you from the runner-image churn that hits people on `ubuntu-latest` twice a year.

On the ask itself: the historical blocker is that each hosted image is a large maintained artifact (toolcache, preinstalled software matrix), so a second distro roughly doubles that surface — which is why the stance has held even through repeated requests. A more winnable framing might be a minimal hosted image (kernel + container runtime only, no preinstalled toolchain), which sidesteps the maintenance-matrix argument while giving distro-neutral users what they actually run: containers.

Hello, thank you for the time you put into your response. I'm sure it may help people looking for a workaround, but I am not one of them. Running a Debian container on top of an Ubuntu host solves absolutely none of my objections. Other provided workarounds, such as a self-hosted runner or reproducibility, also address absolutely zero of my concerns. It would still mean Ubuntu is the default and only runner, shift the burden of hosting onto myself instead of the provider I pay for the service, and Github would still support a company backing an MIT licensed replacement of GPL code.

I understand the historical blocker, and I suppose in the past canonical was the darling of the Linux world. However, it's 2026 and we've lived through unity and the floundering of uuitils - any reasonably popular GPL supporting distro not backed by Canonical would be a welcome replacement. I would be happy enough for a minimal hosted image, but I personally do not really care what shape or form the replacement takes.

Debian would make an ideal replacement due to a large amount of shared functionality between Debian and Ubuntu, but I would happily accept Gentoo if it meant default runners still supported GPL code.

[Kichura]

Because i have been requested to forward my concerns to the discussions page (though i doubt any of us will get any positive news from the maintainers there), I will upvote this as i would like to either have the ability to get Alpine Linux or AlmaLinux to be hosted in the https://github.com/actions/runner-images repository, as having to use Docker/QEMU to implement a container is a hassle and will cost performance really quickly whereas self-hosting costs money and requires SysAdmins to manually accept incoming action requests that come across.

However i disagree with the debian and fedora choices as debian is known for being incredibly insecure and that Fedora gets updated way too frequently. AlmaLinux and Alpine Linux are less of a hassle to work with in general.