The Package Manager for Everywhere — starhaven.ioSkip to main content<br>Rethinking where Homebrew runs
For years, Homebrew described itself as “The Missing Package Manager for macOS<br>(or Linux)”. Buried in the<br>release notes for Homebrew 6.0.0<br>was a small line you may have missed.
Homebrew is increasingly a “package manager for everywhere” : Homebrew is<br>recommended in Microsoft’s Windows Developer Config for WSL comfort, works<br>well on Bazzite and now supports winget in brew bundle as a Windows-only<br>feature.
In July 2026, we<br>updated references<br>to the old tagline across the Homebrew codebase. Homebrew now describes itself<br>as The Package Manager for Everywhere.
The numbers
Homebrew collects<br>aggregate, anonymous analytics. Analytics are<br>opt-out, and Homebrew displays a notice before enabling them so users can opt<br>out before an event is sent.
These reports count events generated by Homebrew activity, not unique users,<br>machines, or installations. A frequently used installation can generate more<br>events than an occasional one, while CI systems can generate many more.
Even with that limitation, the data can show us broad patterns in how and where<br>Homebrew is used. The split between macOS and Linux is similar across the three<br>trailing windows below.
All figures in this article come from Homebrew’s public analytics API and were<br>retrieved on 2026-07-27 UTC. The windows overlap and should not be read as<br>three separate points in time.
Homebrew events by platform
Window<br>macOS<br>Linux
Last 365 days<br>75.6%<br>24.4%
Last 90 days<br>75.2%<br>24.8%
Last 30 days<br>76.1%<br>23.9%
Linux is harder to interpret because CI accounts for a large amount of its<br>activity. Over the last 30 days, 53.4% of Linux events reported running in CI,<br>compared with 20.6% on macOS.
The public analytics API reports operating-system versions and CI status in<br>separate aggregates. It cannot tell us directly which Linux distributions<br>produced those CI events. The table below uses a simplifying assumption: it<br>assigns all Linux CI events to the combined Ubuntu, Debian, Fedora, Amazon Linux,<br>RHEL-family, and Arch group. It should be read as an estimate rather than a<br>directly measured breakdown of non-CI event activity.
Estimated share of non-CI Linux events
Linux group<br>365d<br>90d<br>30d
General-purpose distributions (combined)<br>73.1%<br>66.5%<br>65.6%
Universal Blue<br>18.7%<br>26.0%<br>26.0%
Linux Mint<br>1.9%<br>1.7%<br>1.9%
Pop!_OS<br>1.2%<br>1.0%<br>1.1%
CachyOS<br>0.6%<br>0.8%<br>0.9%
All others<br>4.5%<br>4.0%<br>4.5%
The recent Universal Blue share stands out.<br>Universal Blue provides a community process for<br>building operating-system images based on Fedora Atomic. Those images include<br>Bazzite, Bluefin, and<br>Aurora.
Under this estimate, Universal Blue accounts for roughly 26% of non-CI Linux<br>events in both recent windows, compared with 18.7% across the trailing year.
Universal Blue’s underlying event count is measured directly. The uncertainty<br>lies in treating those events as non-CI because the operating-system report<br>does not include CI status. The resulting 26% estimate would change materially<br>only if a meaningful share of Universal Blue activity came from CI.
Universal Blue share of estimated non-CI Linux events
Image<br>365d<br>90d<br>30d
Bazzite<br>12.4%<br>20.7%<br>20.2%
Bluefin<br>4.1%<br>3.5%<br>3.8%
Aurora<br>2.2%<br>1.8%<br>2.0%
Bazzite alone accounts for about one in five estimated non-CI Linux events in<br>both recent windows.
Shipping brew by default
Bazzite, Bluefin, and Aurora use three complementary ways of delivering<br>software: image-based updates for the operating system, Flatpak for graphical<br>applications, and Homebrew for command-line tools.
Homebrew is not merely available on these systems. They include it by default<br>and present it as a preferred way to install command-line software. The<br>projects document that integration directly for<br>Bazzite,<br>Bluefin, and<br>Aurora.
These integrations appear to have developed independently of Homebrew. I am not<br>aware of a formal relationship or ongoing coordination between Homebrew and any<br>of these projects.
That matters. It suggests that Homebrew’s Linux support and package catalogue<br>have become useful enough for other projects to make them part of their<br>default experience without first needing a coordinated upstream integration.<br>Homebrew is no longer only software that people install after setting up their<br>computer. It now forms part of the experience delivered by community-maintained<br>operating systems.
The Windows question
An evergreen question we receive is: “When are you going to support Windows?”
Homebrew does not run natively on Windows. It does support an increasingly<br>useful Windows development workflow through Windows Subsystem for Linux.<br>Homebrew itself runs as a Linux process inside WSL, while selected features<br>can integrate with the Windows host.
Microsoft’s<br>Windows Developer Config<br>offers Homebrew as an optional part of its WSL Comfort setup. When Homebrew is<br>running under WSL, brew bundle can also<br>manage Windows packages through winget.
To better understand this...