Why Homebrew Remains in the Shadow (And What to Do About It)

Homebrew shows up in enterprise macOS with Bose headphones under a pulled-up hoodie. It’s the missing package manager for MacOS, the open source darling built on radical self-reliance and decentralized governance. Nobody can stop it from walking in. Everyone knows it's here to get work done. Yet, it operates in the shadows just outside the purview of your MDM. 

If you're reading this, you've had the conversation. Engineering needs it to ship code without being slowed down. Security wants to review it, scan it or ban it. Compliance needs a complete inventory with documented approvals. In the end, IT is caught in the middle, building custom scripts to get some visibility to herd the cats and keep the guard dogs at bay.

If you're evaluating how to establish policy around Homebrew without breaking it, then you're solving the right problem. You're acknowledging that Homebrew is valuable and worth preserving while also recognizing that your organization needs to level up the game. 

So let’s explore the best way forward for all concerned.

Homebrew Was Built by Developers for Developers#

Homebrew prioritizes speed, local control, and autonomy. It assumes one person, one machine, and the freedom to decide what's "safe enough" in context. That's a beautiful model when it works, and in the open-source community, it works remarkably well. Trust through the ability to verify, build, and understand the code yourself.

The tension appears when Homebrew enters a regulated enterprise. Because Homebrew's assumptions are fundamentally different from yours.  You're thinking multi-team, compliance, auditability, and continuity. Homebrew is thinking: Can the developer get what they need now? Both are valid. They're just at odds unless you find a workable compromise.

Why macOS Makes Visibility So Hard (It's Not Just Homebrew)#

Homebrew typically runs in user space, not through a centralized system repository. It doesn't register with the OS the way App Store apps or signed system packages do. Most MDM tools report what they install, or what the OS exposes through standard APIs. They're excellent at tracking applications, profiles, and extensions.

But a Homebrew package? From the operating system's perspective, it's just files in directories. So you end up in a situation many of you know well:

• Homebrew knows what's installed. (Because Homebrew installed it.)

• The developer's machine knows what's installed. (They can run brew list anytime.)

• IT may or may not know what's installed. (Because it never registered anywhere your tools look.)

This is a consequence of how macOS and developer tooling evolved over time. And if you want to understand why Homebrew became this way, check out Workbrew's article "Understanding Homebrew's History." It walks through the evolution from package managers built for Linux distributions (designed for teams and systems) to Homebrew (designed for individual developers on macOS).  

What Homebrew Actually Is (And Isn't)#

Have you ever noticed how Homebrew feels designed for the developer, and not for an IT team? 

Think about Homebrew as a single-player game where the developer decides what's safe, what they need, and how fast to move. It's a beautiful model when you're working alone or in small groups where everyone trusts everyone else. But when you’re a space program or a bank or health technology, the regulators are calling the shots. You're in a multi-player game with a single-player tool. Suddenly the governance questions appear:

• What software packages are being used across the fleet?

• Who approved this tool and this version?

• Is it still acceptable under our current risk profile?

• Are all packages updated for the latest CVEs?

• Why are two engineers on the same team running different versions?

These are multi-player systems questions that matter in environments where software decisions are inherited, audited, and sometimes regulated. But Homebrew was never designed for the enterprise.

Why can't Homebrew just add policy features for the enterprise?#

Homebrew is a volunteer-driven open-source project. The maintainers (mostly unpaid contributors working on code they find useful) make decisions through community contribution and consensus. They're focused on a clear mission: making package installation simple, reliable and (reasonably) safe for individual users.

A built-in policy layer would have to answer questions that change from company to company:

• Which taps are allowed?

• Which versions meet your internal standards?

• Do different teams operate under different rules?

• What happens when someone deviates?

Those decisions belong to your organization based on your regulatory needs and risk appetite, not to an open-source project trying to serve developers worldwide.

If Homebrew added enterprise policy features, it wouldn't be Homebrew anymore. It would be something else (something more complex, slower, more opinionated). The thing that makes Homebrew valuable to your developers is precisely what makes it incompatible with enterprise governance.

The maintainers understand this. They're protecting Homebrew’s integrity by staying in their lane.

What Governance Actually Requires#

So what can you do?

Governance, in a Homebrew environment, is about defining expectations clearly and checking whether reality matches them. Sometimes security teams approach this with strict allow-lists and command blockers. That works, technically. But it also breaks the thing that made Homebrew valuable in the first place.

A better approach starts with different questions:

• Which taps do we consider acceptable?

• What does "approved" mean for our organization today?

• Do different teams operate under different rules?

• When reality diverges from those expectations, how do we detect it? How do we respond?

Homebrew installs what developers request. Most device management tools report what's already installed. Both are useful. But neither defines what you expect or continuously compares behavior to it.

What's missing is a layer that can express organizational policy alongside Homebrew (modeling allowed sources, tracking versions across your fleet, detecting drift from your declared expectations, and producing audit records) while preserving the developer experience that made Homebrew valuable in the first place.

This is our mission.

Where Workbrew Fits#

Workbrew was built around the need for Homebrew to work in regulated environments.

It doesn't replace Homebrew or repackage it. Instead, we added an organizational layer around it. You define which taps are acceptable, model team-level rules, detect when reality drifts from your expectations, and generate the audit records compliance requires. 

All while developers continue using the familiar brew workflow they love.

For your developers, it's still just Homebrew. The workflow feels the same.

For IT and security, it's the visibility and control you've been missing. Integration with your MDM tools. Zero-touch deployment with real-time audit trails of every brew command, every install, every CVE and every fix. We complete your MDM by offering fleet-wide insights into what's installed, where, and why. 

The goal is to maintain development velocity and even go faster, because you can meet your security and compliance requirements without turning it into a manual exercise.

The Actual Problem You're Solving#

If you're evaluating how to establish policy around Homebrew without breaking it, then you're solving the right problem. You're acknowledging that Homebrew is doing something valuable (something worth preserving) while also recognizing that your organization needs something it was never designed to provide.

Homebrew and Workbrew are complementary layers solving two different problems. Homebrew gives developers the speed and autonomy they need to use open source tools. Workbrew gives you the governance and visibility you need.

Both working together is how you stop having that conversation. The one where you're wondering why your fleet is invisible, and developers are wondering why you keep asking them to use something worse.

Workbrew lets Homebrew do what it does best, with the management controls that let you do your best.