What Is Homebrew and Should You Use It on Mac?

The short answer. Homebrew is a package manager: one command that installs, updates and removes software, instead of you visiting a website for each tool and remembering to check for updates. It is the standard way to install command-line software on a Mac, it is free and open source, and it installs entirely inside its own directory rather than into the system.

Whether you need it depends on one question: do you install command-line tools? If yes, use it. If you only ever install applications with a window, you can skip it — a cask is a convenience wrapper around the same download the vendor offers.

What it actually is

Homebrew is a catalogue plus a client. The client is the brew command; the catalogue is a set of Git repositories describing how to build or fetch each piece of software.

Two kinds of package, and the distinction matters more than it looks:

Formulae are command-line software. wget, git, python, ffmpeg, jq. A formula describes where the source is, what it depends on, and how to build it. Homebrew either builds it on your machine or installs a bottle — a pre-built binary from Homebrew’s own servers, which is what happens almost all the time.

Casks are macOS applications. firefox, visual-studio-code, docker. A cask describes where to download the app, how to install it (drag to Applications, run a .pkg, mount a disk image) and how to remove it. It is a scripted version of what you would do by hand.

The distinction matters because a formula is built from source in a controlled way, while a cask runs whatever installer the vendor shipped. That is a different level of trust, and it is why “it is in Homebrew” is not by itself a security statement.

Installing it

The official installer is a shell script fetched and executed:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

That is a command that downloads code from the internet and runs it, which is worth pausing over. The reason it is acceptable here is that the URL is HTTPS, the repository is the project’s own, and the script is short enough to read — which you should do once, if you are the sort of person who is going to use this tool.

The installer does three things: it installs the Xcode Command Line Tools if they are missing, it clones the catalogue into its prefix, and it prints two commands to add brew to your PATH.

On Apple Silicon the prefix is /opt/homebrew, and the two commands are:

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

On Intel the prefix is /usr/local, which is already in the default PATH on most systems, so the second step is often unnecessary.

The prefix is the design decision that makes everything else simple. Because Homebrew lives in one directory that it owns, it does not need sudo, does not touch /System or /usr/bin, and does not require System Integrity Protection to be disabled. Uninstalling it is rm -rf on that directory, and every package goes with it.

The commands worth knowing

Two of these confuse people because they sound the same. brew update refreshes the catalogue — it tells Homebrew what exists and what version it is. brew upgrade installs the newer versions of what you already have. Running brew upgrade without brew update first upgrades to whatever the catalogue last knew about.

brew cleanup is the one to run periodically, and the reason is disk space rather than correctness: Homebrew keeps old versions of everything and every bottle it has downloaded. A few years of use can leave several gigabytes in ~/Library/Caches/Homebrew, all of it re-downloadable.

Formulae, casks and the trust question

The security model deserves a straight answer because it is often glossed over.

Formulae are defined in the homebrew-core repository, which is reviewed by maintainers and where each formula is a Ruby file specifying a URL, a checksum and build instructions. When you install, Homebrew either builds from source or downloads a bottle and verifies its checksum. The chain of trust runs from Homebrew’s CI to your machine, and it is reasonably strong.

Casks are defined in homebrew-cask, which describes where to download the vendor’s own installer. Installing a cask runs that installer, which can do anything an installer can do — including writing outside /Applications, installing a privileged helper, or requiring an administrator password. A cask is a convenience, not a sandbox.

Taps are third-party repositories you add explicitly. brew tap someone/something makes their packages available, and those packages are not reviewed by anyone but the person who wrote them. Adding a tap is a decision about trust, and it is worth knowing when you have done it.

The practical rule: prefer homebrew-core formulae, treat casks as equivalent to downloading the app yourself, and be deliberate about taps.

Reproducing a setup: the Brewfile

The feature that makes Homebrew more than a convenience is brew bundle, which records what you have installed in a text file and restores it.

brew bundle dump --file=~/Brewfile
brew bundle install --file=~/Brewfile

The Brewfile lists every formula, cask and tap, in a format you can read and edit:

tap "homebrew/cask"
brew "git"
brew "ffmpeg"
cask "visual-studio-code"
cask "firefox"

Two uses. Setting up a new Mac becomes one command instead of an afternoon, which is the argument for keeping a Brewfile in your dotfiles repository. And keeping a project’s dependencies in a Brewfile checked in beside the code means a colleague can install exactly the tools the project expects, rather than a version they happened to have.

It is not a lockfile — it records what you have, not exact versions with hashes — so it reproduces the set rather than the state. For exact reproduction, the tool is Nix, which is a different design with a much steeper curve.

Where it puts things

Knowing the layout makes the odd behaviours explicable.

The Cellar is why installing two versions of a tool is possible and why upgrading does not immediately delete the old one — the old version stays until brew cleanup. It is also why the bin directory contains symlinks rather than files: brew link and brew unlink create and remove those symlinks, which is how you switch which version a command resolves to.

When a command “is not found” but brew list says it is installed, the problem is almost always the symlink or the PATH, not the installation. brew link <name> recreates the links; the PATH check is echo $PATH | tr ':' '\n' | grep homebrew.

Common problems

brew doctor complains about everything. It is deliberately pessimistic. Warnings about unbrewed headers in /usr/local/include are common on machines that have installed things by hand, and are usually harmless. Errors are worth acting on.

Permission errors in the prefix. Caused by running brew with sudo at some point, which leaves root-owned files. The fix is sudo chown -R $(whoami) $(brew --prefix), and the lesson is not to use sudo with brew.

“Another active Homebrew process is already using it.” Two brew commands at once, usually because one is waiting for a password prompt in another window. Find it and let it finish; killing it mid-install can leave a package half-linked.

Upgrades are slow. brew update clones the catalogue, which is large. It is fast after the first time unless the repository has diverged, in which case Homebrew resets it — and the reset is what takes minutes.

An app installed by cask will not update through the App Store. Correct: a cask installs the vendor’s build, not the App Store build, and it updates through brew upgrade --cask instead. Mixing the two for the same app produces a duplicate or a broken one.

What it does not manage

Homebrew is one tool among several, and knowing the boundary stops you from expecting it to do things it will not.

macOS itself. System updates are Apple’s, delivered through System Settings. Homebrew does not touch them and cannot.

App Store applications. An app bought or downloaded from the App Store updates through the App Store, with its own account and its own sandbox. Installing the same app as a cask produces a second copy that will conflict with the first.

Language-specific version managers. Node, Ruby, Python and Go all have their own ecosystems — nvm, rbenv, pyenv, goenv — which exist because a project needs a specific version rather than the current one. Homebrew installs one version of node and keeps it current; if you work on several projects with different requirements, the version manager is the right tool and Homebrew’s copy is at best a fallback. Installing both is common and is the source of the “which node am I running” problem: which -a node shows the order.

Python packages. pip install inside a Homebrew Python works, but Homebrew’s Python is externally managed and will refuse system-wide installs on current versions. The answer is a virtual environment, not a Homebrew formula.

Configuration. Homebrew installs software; it does not configure it. A brew install postgresql gives you a binary and a brew services start postgresql gives you a running service, and everything after that is the software’s own documentation.

That boundary is why the standard Mac development setup is several tools rather than one: Homebrew for the binaries, a version manager for each language that needs one, and the language’s own package manager for libraries.

Homebrew compared with the alternatives

Three package managers are in serious use on macOS, and they make different trade-offs.

Homebrew’s advantage is currency and convenience: bottles mean most installs are a download rather than a compile, and the catalogue is updated within hours of a release. Its weakness is that it is not reproducible in the strict sense — two machines installing “the same” Brewfile today may get different versions.

Nix solves that by content-addressing everything, which is genuinely better for reproducible builds and genuinely harder to learn. MacPorts is older, builds more from source, and has a smaller community; there is little reason to choose it today unless you already have.

Keeping it healthy

A Homebrew installation that is used for years accumulates cruft, and three commands keep it in shape.

brew update && brew upgrade
brew cleanup -s
brew doctor

The first pair, run monthly, keeps everything current. brew cleanup -s removes old versions and the download cache, and the -s also scrubs the cache of the most recent versions, which is the difference between reclaiming a few hundred megabytes and reclaiming several gigabytes. brew doctor reports problems — a broken symlink, a stale lock, a prefix with the wrong permissions — and it is worth running when something behaves oddly rather than on a schedule.

Two habits prevent most problems. Never run brew with sudo: the prefix is owned by you and using sudo leaves root-owned files that break the next install. And let a brew command finish — killing one mid-install can leave a package half-linked, which is the situation brew doctor exists to find.

If you want the same set of tools on a new machine, the Brewfile is the mechanism, and keeping it in a dotfiles repository is the habit that makes setting up a Mac an afternoon rather than a weekend.

What installing a cask actually does

A cask looks like one command and is really a small script, and knowing the steps explains most cask oddities.

1. Resolve the artefact. The cask names a download URL, usually the vendor’s own. Homebrew fetches it into its cache and verifies a checksum where the cask specifies one.
2. Mount or unpack. For a .dmg, Homebrew mounts the image read-only. For a .pkg, it runs the installer. For a .zip, it extracts.
3. Copy or install. For the common “drag the app to Applications” case, Homebrew copies the .app into /Applications. For a .pkg, the vendor’s installer script runs, which can do anything.
4. Record it. The Caskroom gets a directory recording what was installed and from where, which is what brew uninstall --cask uses to remove it.
5. Handle quarantine. The downloaded file carries the quarantine attribute, so Gatekeeper checks the app on first launch exactly as it would for a manual download.

The consequences: a cask that installs a .pkg can require an administrator password, can install a privileged helper, and can place files outside /Applications. brew uninstall --cask removes what the cask knows about, which is not necessarily everything the installer wrote. And a cask whose vendor changes their download URL breaks until the cask is updated — which is why a cask occasionally fails with a 404 for a day or two after a release.

Where it fits in a Mac setup

For a machine used for development, the usual arrangement is Homebrew for binaries and applications, a version manager for each language, and the language’s own package manager for libraries. Each layer knows about its own updates, and none of them tries to manage the others.

For a machine used for writing, design or administration, Homebrew is optional and often unnecessary. The apps come from the App Store or the vendor, and the command-line tools you need are few enough to install by hand. Installing it anyway costs nothing and occasionally saves a search.

The mistake to avoid is treating Homebrew as a replacement for the App Store. It is a different channel with a different review process, and the two do not coordinate: an app installed both ways ends up duplicated, and one installed as a cask does not get App Store updates.

Should you use it?

Yes, if you install command-line tools, work in Terminal at all, or set up machines often enough that a Brewfile would save you an afternoon. It is the standard, the catalogue is enormous, and the alternatives — MacPorts, Nix — are either less current or considerably more demanding.

No, if you only install applications with a window and never open Terminal. The App Store and the vendor’s download page cover that case, and installing a package manager to install Firefox is a layer you will never use.

Maybe, if you are somewhere in between: you want ffmpeg once, or you need a tool a tutorial told you to install. In that case install Homebrew, use it for that, and ignore it otherwise. It costs nothing to have and does not run in the background.

If you want a graphical front end rather than the command line, Cork is a native app that wraps brew — it lists what is installed, shows what is outdated and runs the commands for you, which is useful for people who use Homebrew occasionally and do not want to remember the syntax.

The terminals worth using with it are a separate question, and a well-covered one: Ghostty, iTerm2, Warp, kitty and WezTerm all run brew identically, because it is a command rather than an integration. Pick the terminal for its own sake, not for this.

FAQ

Is Homebrew the same as the App Store? No. The App Store is Apple’s curated, sandboxed, paid-or-free distribution channel with its own review and its own update mechanism. Homebrew is a community catalogue of scripts that install software from the vendor or from source. They coexist, and an app can be available in both with different builds.

Does Homebrew need Xcode? It needs the Xcode Command Line Tools, which are a much smaller download than Xcode itself and are installed by the Homebrew installer if missing. Full Xcode is only needed to build software that requires it.

Can Homebrew break macOS? Not in the way people fear. It installs into its own prefix and does not modify system files, which is why it works with System Integrity Protection enabled. The realistic risks are installing a package you did not mean to, and a tap that turns out to be untrustworthy.

How do I uninstall Homebrew completely? There is an official uninstall script in the same repository as the installer, and it removes the prefix and the packages. Doing it by hand means rm -rf /opt/homebrew plus deleting the cache and the PATH line — and remembering that casks installed to /Applications may leave the app behind.

Why does brew install sometimes compile for ten minutes? Because no bottle exists for your macOS version and architecture, so it builds from source. This is more common for niche packages and for very new macOS releases, before Homebrew’s CI has produced bottles for them.

Is there a graphical interface? Yes — Cork wraps the command line in a native app, listing what is installed, showing what is outdated and running the commands for you. It is a genuine convenience for occasional use and no substitute for knowing the four or five commands above, because when something goes wrong the error message is the same either way.