Pouring packages with Homebrew

The Homebrew project is an open-source package-management system that comes with a repository of useful packages for Linux and macOS. Even though Linux distributions have their own package management and repositories, Homebrew is often used to obtain software that is not available in a distribution's repository or to install more current versions of projects than are available from long-term-support (LTS) distributions. Homebrew 5.0.0, released on November 12, 2025, expanded Linux support to include 64-bit Arm packages in addition to x86_64, and turned on concurrent downloads by default to speed up package downloads.

The project began in 2009 as a package-management system for Mac OS X, later macOS, which did not (and still does not) have a package manager as such. It allowed users to easily install and manage software not included with the operating system or available in Apple's App Store; in particular, it is popular for installing open-source applications that are either unavailable with macOS or shipped with the operating system but severely outdated.

Over time, a fork of the project called Linuxbrew became a popular way to install software on Linux as well. It was merged with Homebrew for the 2.0.0 release in 2019. In addition to serving as a supplement to a distribution's package repositories, Homebrew has become a recommended method of managing software on some image-based distributions, such as Bazzite, which do not support traditional Linux package management using APT, DNF, etc. It makes a good complement to Flatpak for such systems; Homebrew's focus is command-line and server software, rather than desktop applications.

Getting started

Homebrew is written in Ruby and available under a BSD 2-clause license. The recommended way to install Homebrew on Linux is, unfortunately, by fetching the install script via curl and feeding it to bash. It prompts for sudo access during the install, so users need to be able to use sudo to install Homebrew—or to persuade the system's administrator to do it for them—but afterward it does not require sudo to install or manage software.

The installer puts Homebrew in /home/linuxbrew/.linuxbrew; users will need to add that to their path afterward. The project's install documentation notes that it is possible to install Homebrew elsewhere, but it is unsupported: "If you decide to use another prefix: don't open any issues, even if you think they are unrelated to your prefix choice. They will be closed without response."

That may seem a bit odd, but there is a reason for the project's choice of directory and insistence that users stick to that directory or take their chances. It is possible to compile Homebrew packages from source, but the default is to install a prebuilt binary package which is (maintaining the overall theme) called a bottle. Some of the precompiled binaries contain hard-coded paths, so the project chose /home/linuxbrew as the default directory. In the early days of the Homebrew project, the default was to compile from source rather than to install precompiled binaries—so there were no doubt many packages that already had ~/.linuxbrew as the default location.

Once installed, the brew command can be used to install, update, remove, and otherwise manage software. The "brew help" command will provide a short list of available operations and a link to the documentation. As one might suspect from the name and logo (a mug of beer), the project leans heavily into beer-related terminology, which is helpfully documented online.

A package definition for Homebrew that builds from upstream open-source projects is called a formula (plural "formulae"); these are written in Ruby. A Git repository of formulae is called a tap, and the project maintains a core repository (the "core tap") with hundreds of formulae.

So, "brew install fzf" would install the bottle for the fzf command-line fuzzy finder project, as well as any dependencies. Adding the source option (-s) would build fzf from source, though it still downloads fzf's dependencies as binaries. It seems something of a terminology miss that dependencies are not called "chasers", but I digress.

Brewing

Anyone can submit a formula to the core repository: the guidelines for acceptable formulae include a requirement that the software is available under a license that meets the Debian Free Software Guidelines. That is not the sole requirement, of course. The project also has a prohibition on software that upgrades itself (rather than being updated using "brew update"), and discourages vendoring other software, though the guidelines indicate flexibility. If something cannot be packaged without vendoring, "so be it; better to have packaged software in Homebrew than not." Homebrew refers to the policies from Debian and Fedora as examples of acceptable vendoring practices. Homebrew also has the sensible requirement that a formula must use a stable version tagged by the upstream project; the project does not want to be shipping unstable software, unreleased versions, etc.

Finally, its documentation notes that exceptions to its guidelines may be made in either direction: some software that meets the written criteria may be rejected, and some software may be accepted that does not meet all the criteria. "Although some rejections may seem arbitrary or strange they are based on years of experience making Homebrew work acceptably for our users."

Software need not be in the core repository to work with Homebrew, however. Users may want to package software for their own use without submitting it to the project, which can be done by creating a custom tap. The "brew tap" command can be used to add a third-party repository; the project maintains a list of interesting third-party taps users may want to try out.

Homebrew also provides packages that are only available in binary format and that are not (necessarily) open source; these are called casks. This is mostly a convenience feature for macOS; it allows users to install and manage popular desktop applications, such as Ghostty, GIMP, or Zoom, from the command line instead of having to use the App Store or download an Apple Disk Image (DMG). Homebrew added preliminary support for Linux casks with the 4.5.0 release in April 2025. I haven't, so far, found any packages I wanted to install via Homebrew that were casks rather than formulae, but I expect that the community will add a larger selection of casks over time.

Linux users who are comfortable with DNF or APT will have no problem acclimating to using Homebrew. The basics are pretty much the same; "brew install" installs packages, "brew search" is used to find available packages, "brew upgrade" upgrades packages, and so forth. Running "brew commands" will display a full list of brew's built-in commands, including those for creating and working with formulae. For example, "brew edit fzf" will open the Ruby script for fzf's package.

One thing I like about Homebrew is the amount of information provided about packages and how easy it is to search the development history of packages. The "brew search --pull-request text" option allows users to search Homebrew's GitHub repositories, including the formulae, cask, and main project repository, for any pull requests that have been submitted to the project with "text" in them. This means that one can search for all pull requests that match a package name or other term of interest.

Analytics

The "brew info package" command provides the version of the package, its repository information, how much space it takes up on disk, license, and the analytics information for the package. That last bit is something Linux users will no doubt want to know more about.

By default, Homebrew enables anonymous analytics after it is installed and has shown the user a notice about analytics. No analytics are sent during the installation. The notice is part of many messages displayed to the user after install, and is easy to miss; but the project does provide a link to the documentation that explains what is collected, how long it is retained (365 days), and how it is used. Users who do not want to provide analytics can opt-out by setting an environment variable ("HOMEBREW_NO_ANALYTICS=1") or by running "brew analytics off".

The project's documentation explains why it collects analytics, and I am sympathetic to the fact that it is a volunteer project that uses the data to try to guide development. Still, it would be better if users were asked about analytics during installation rather than collecting them by default. Even a prompt that defaulted to "yes, take my data please" would be preferable.

All that said, Homebrew's analytics data is publicly available and provides some interesting insights about the use of the project. In particular, the OS versions for events data shows that Linux users make up a larger part of Homebrew's install base than one might expect. Mac users are far and away the majority of Homebrew users. But, in the last year, Ubuntu LTS users accounted for about 12% of the events tracked by Homebrew's analytics. It also shows the relative usage and popularity of various Linux distributions; the 90-day and 30-day views indicate that Bazzite is steadily becoming more popular, having climbed from 0.23% of events in the year view to 1.01% in the last 30 days.

The Homebrew project is fairly mature at this point, so its releases mostly bring modest enhancements and improvements rather than big changes. The significant changes in 5.0.0 that concern Linux users are the promotion of Arm64/Aarch64 packages to Tier 1 support, and turning on concurrent downloads by default. Even though Homebrew is an all-volunteer project, it has well-defined support tiers to help users understand how well things are expected to work on different systems. Each tier describes the combination of operating system, hardware, and Homebrew configuration. For example, the definition of a Tier 1 Linux system only includes Ubuntu releases still within their support window, or a Homebrew Docker image, running on x86_64 or Arm 64-bit systems. Thus, the project would consider Debian, Fedora, or other distributions to be Tier 2.

Tier 1, for instance, receives the highest level of support and test coverage. If a patch or formula fails to build for a Tier 1 system, it is rejected. Tier 2 and Tier 3, of course, have reduced expectations and the maintainers do not commit to fixing bugs or accepting pull requests for these tiers.

The concurrent downloads feature was added in the 4.6.0 release, but was opt-in only. In 5.0.0 it is turned on by default and set to "auto", which sets the number of downloads to twice the number of CPU cores on a system. So, for example, if a system has 16 cores, "brew—install foo" will attempt up to 32 parallel downloads if the operation requires it. This can be faster if a package has many dependencies that also need to be downloaded and installed. The command also displays download progress as each dependency is downloaded; this is not exactly a critical feature, but it's fun to watch.

Homebrewing

If one has a bit of Ruby background or is willing to learn, packaging software for Homebrew is not terribly difficult. The Formula Cookbook explains the package definition format and has plenty of tips for creating formulae. The project also has a good guide for opening pull requests whether one wants to submit a new formula, cask, or make changes to brew itself.

Homebrew is a fairly active project with well-documented governance policies. The project is on Open Collective, and its finances and expenses are visible there. The project is volunteer-run but does provide some stipends to maintainers as well as things like reimbursing for conference travel.

It is by no means a full replacement for distribution package management or repositories, but Homebrew does help fill in the gaps on older systems and image-based systems. It is straightforward to work with as an end user and amateur packager.