The Package Manager for Everywhere

Rethinking where Homebrew runs

For years, Homebrew described itself as “The Missing Package Manager for macOS (or Linux)”. Buried in the release notes for Homebrew 6.0.0 was a small line you may have missed.

Homebrew is increasingly a “package manager for everywhere”: Homebrew is recommended in Microsoft’s Windows Developer Config for WSL comfort, works well on Bazzite and now supports winget in brew bundle as a Windows-only feature.

In July 2026, we updated references to the old tagline across the Homebrew codebase. Homebrew now describes itself as The Package Manager for Everywhere.

The numbers

Homebrew collects aggregate, anonymous analytics. Analytics are opt-out, and Homebrew displays a notice before enabling them so users can opt out before an event is sent.

These reports count events generated by Homebrew activity, not unique users, machines, or installations. A frequently used installation can generate more 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 Homebrew is used. The split between macOS and Linux is similar across the three trailing windows below.

All figures in this article come from Homebrew’s public analytics API and were retrieved on 2026-07-27 UTC. The windows overlap and should not be read as three separate points in time.

Homebrew events by platform

Linux is harder to interpret because CI accounts for a large amount of its activity. Over the last 30 days, 53.4% of Linux events reported running in CI, compared with 20.6% on macOS.

The public analytics API reports operating-system versions and CI status in separate aggregates. It cannot tell us directly which Linux distributions produced those CI events. The table below uses a simplifying assumption: it assigns all Linux CI events to the combined Ubuntu, Debian, Fedora, Amazon Linux, RHEL-family, and Arch group. It should be read as an estimate rather than a directly measured breakdown of non-CI event activity.

Estimated share of non-CI Linux events

The recent Universal Blue share stands out. Universal Blue provides a community process for building operating-system images based on Fedora Atomic. Those images include Bazzite, Bluefin, and Aurora.

Under this estimate, Universal Blue accounts for roughly 26% of non-CI Linux events in both recent windows, compared with 18.7% across the trailing year.

Universal Blue’s underlying event count is measured directly. The uncertainty lies in treating those events as non-CI because the operating-system report does not include CI status. The resulting 26% estimate would change materially only if a meaningful share of Universal Blue activity came from CI.

Universal Blue share of estimated non-CI Linux events

Bazzite alone accounts for about one in five estimated non-CI Linux events in both recent windows.

Shipping brew by default

Bazzite, Bluefin, and Aurora use three complementary ways of delivering software: image-based updates for the operating system, Flatpak for graphical applications, and Homebrew for command-line tools.

Homebrew is not merely available on these systems. They include it by default and present it as a preferred way to install command-line software. The projects document that integration directly for Bazzite, Bluefin, and Aurora.

These integrations appear to have developed independently of Homebrew. I am not aware of a formal relationship or ongoing coordination between Homebrew and any of these projects.

That matters. It suggests that Homebrew’s Linux support and package catalogue have become useful enough for other projects to make them part of their default experience without first needing a coordinated upstream integration. Homebrew is no longer only software that people install after setting up their computer. It now forms part of the experience delivered by community-maintained 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 useful Windows development workflow through Windows Subsystem for Linux. Homebrew itself runs as a Linux process inside WSL, while selected features can integrate with the Windows host.

Microsoft’s Windows Developer Config offers Homebrew as an optional part of its WSL Comfort setup. When Homebrew is running under WSL, brew bundle can also manage Windows packages through winget.

To better understand this group, we began labeling WSL analytics in Homebrew 6.0.0, released on 2026-06-11.

WSL currently accounts for around 3.7% of non-CI Linux events over the last 30 days. We only have labeled data from late June onward, so this is an early figure that is certain to change. WSL is also an environment rather than a distribution family. Its events are counted under the underlying Linux distribution, primarily within the combined row above.

I’m looking forward to seeing how this data develops and where WSL sits in Homebrew activity a year from now.

What “everywhere” costs us

Most Homebrew maintainers primarily use macOS. A much smaller group works regularly with Linux distributions and their particular constraints.

One of those maintainers, Ruoyu Zhong, put tremendous effort into bringing ARM64 Linux support to Homebrew and helping make it a Tier 1 supported platform. I highly recommend his FOSDEM 2025 talk about that work.

That effort also illustrates the cost of supporting more platforms. When a downstream operating system includes Homebrew by default, some of its users will inevitably bring platform-specific problems to Homebrew’s issue trackers. Some will be upstream Homebrew bugs. Others will result from the downstream integration or the underlying operating system. Determining which is which still requires maintainer time.

Homebrew also has an important support boundary. Its current Tier 1 criteria for Linux cover supported Ubuntu releases and Homebrew-provided Docker images, along with requirements for architecture, prefix, system libraries, and other configuration details. Fedora-based Universal Blue images do not currently meet that distribution criterion.

That does not mean Homebrew cannot work well on those systems. The activity above suggests that it can. It means that platform-specific failures do not carry the same support promise as failures reproduced on a Tier 1 configuration.

Security and trust introduce another boundary. Homebrew can attest to the code, bottles, and official installation methods that the project ships. A downstream project controls how Homebrew is installed, who owns the installation, how it is updated, whether anything is modified, and how it interacts with the rest of the operating system. Even when the Homebrew code itself is unchanged, those integration decisions can affect its security and reliability.

Homebrew’s BSD-2-Clause license allows redistribution with or without modification and disclaims warranties and liability. That establishes the legal baseline, but it does not determine how users will attribute a failure. If a downstream integration breaks or suffers a security incident, many people will not immediately distinguish between Homebrew itself and its downstream delivery.

That freedom is part of the beauty of open-source software. Homebrew does not need or seek control over projects that redistribute it. But as those integrations become more widely used, clearer communication about support, updates, and security becomes valuable to everyone involved.

Where this goes

Homebrew is a package manager and an open-source project that I love maintaining. We will continue working to make it a free way to install software across the platforms we support.

The adoption described here makes me wonder whether closer relationships with downstream projects would benefit everyone involved. That does not need to mean approval, control, or a formal partnership. Even lightweight coordination could give us known security contacts, document how Homebrew is installed and updated, and help route integration-specific problems to the right project.

If you maintain a project that ships Homebrew by default, or uses it in some other creative way, I would love to learn more about what you are doing and how you handle updates, support, and security. You can find me on Mastodon or email me at patrick@brew.sh.

This is a personal post reflecting my perspective as a Homebrew maintainer, not a statement of Homebrew project policy.

Methodology: The figures in this article come from Homebrew’s public analytics API. These are rolling windows, so requests made later will not reproduce the exact values retrieved on 2026-07-27 UTC.

The platform, CI, and WSL figures, as well as the non-CI Linux denominator, come from the homebrew-os-arch-ci report. The distribution numerators come from os-version. These reports can have slightly different total event counts, so independently calculated results may differ slightly after rounding.

As described above, the calculation assigns all reported Linux CI events to the combined Ubuntu, Debian, Fedora, Amazon Linux, RHEL-family, and Arch group.

Replace 30d with 90d or 365d to retrieve the other windows:

• https://formulae.brew.sh/api/analytics/os-version/30d.json
• https://formulae.brew.sh/api/analytics/homebrew-os-arch-ci/30d.json

AI disclosure: I wrote the original draft of this post. I used AI during the editing process to stress-test claims, reproduce the analytics, and improve its structure and clarity. I reviewed the final text and remain responsible for its content.