What is Homebrew? An IT Manager's Guide
The package manager on nearly every developer Mac, explained for the people who have to manage those Macs: how it works, why developers rely on it, and what it means for IT.
If you manage Macs, Homebrew is already on them. It is the de facto package manager for macOS — the tool developers use to install compilers, databases, CLIs, and thousands of other open source programs with a single command. This guide explains what it is and how it works, written for IT and security managers rather than for the developers who already know.
The one-paragraph version
Homebrew is a free, open source package manager for macOS and Linux. A developer types brew install postgresql and Homebrew downloads the software, resolves its dependencies, installs everything into a dedicated directory, and keeps it upgradable with brew upgrade. It is to a Mac what apt is to Ubuntu — except it is installed by the developer, not the platform, and by default it answers to nobody.
The vocabulary you will encounter
| Term | What it means |
|---|---|
| Formula | A recipe describing how to install a piece of open source software (e.g. git, node, openssl). |
| Cask | A recipe for installing a regular macOS application (e.g. a browser or editor) rather than a command-line tool. |
| Bottle | A pre-compiled binary of a formula, so the machine downloads and unpacks instead of building from source. Most installs use bottles. |
| Tap | An additional repository of formulae. homebrew-core is the official one; anyone can host their own tap, with their own (or no) review process. |
| Prefix | The directory Homebrew installs everything into — /opt/homebrew on Apple Silicon Macs. |
| brewfile | A checked-in list of packages, used to reproduce a machine's Homebrew setup. |
Why developers rely on it
Nothing about Homebrew is niche. It is how modern development environments get built on a Mac:
- It is the fastest path to a working toolchain. New laptop to productive developer is a handful of
brew installcommands — often scripted in a company's own onboarding docs. - The catalog is enormous. Thousands of formulae, actively maintained, covering essentially every open source tool a developer needs.
- It stays current. Upstream releases reach Homebrew quickly, which matters both for features and for security fixes.
- CI uses it too. Build pipelines on macOS runners routinely install their dependencies with Homebrew, so it is embedded in delivery infrastructure, not just laptops.
Take it away and none of that need disappears — developers fall back to manual downloads and curl-piped install scripts, which are strictly worse for security. That trade-off is the subject of Why Blocking Homebrew Makes Your Security Posture Worse.
What Homebrew means for IT
Here is the part that matters for this audience: Homebrew is the largest software channel on your developer Macs that your management stack cannot see.
Your MDM governs the apps you package and push. The App Store governs consumer apps. Homebrew sits outside both. In its default state:
- There is no inventory — no record of what is installed on which machine.
- There is no policy — any developer can install any formula from any tap.
- There is no audit trail — nothing attributes an install to a person, a time, or a device.
- There is no vulnerability process — packages install clean and quietly age into their CVEs.
None of this is a flaw in Homebrew; it was built as a personal tool and it is excellent at being one. But personal tools that reach fleet scale become IT's problem, and every compliance conversation — SOC 2, ISO 27001, customer security reviews — eventually reaches the question "what open source is running on your endpoints, and who approved it?" With vanilla Homebrew, the honest answer is a shrug. We looked at whether that state of affairs is dangerous in Is Homebrew Safe? A Security Review for IT Teams.
How enterprises bring it under management
The emerging pattern is not to replace Homebrew but to route it: developers keep the exact brew install workflow, while every request passes through a control plane that IT operates. That layer provides what the default tool omits — an allow/block policy checked at install time, a per-device package inventory synced with the MDM you already run, vulnerability checks against the best available data, and an audit log that maps every install to a real user and machine.
That is the model EnterpriseBrew implements. Developers notice nothing; IT finally has the same answers for Homebrew that it has for every other software channel: what, where, who, and whether it is allowed.
The takeaway
Homebrew is not a shadow-IT curiosity — it is core infrastructure for macOS development, and it is almost certainly in production use across your fleet today. The question for an IT manager is not whether to allow it. It is whether the largest package pipeline on your endpoints runs with governance or without it.