Homebrew 7.0.0 shipped on September 13, and it ends Intel Mac support in everything but name. Intel x86_64 drops to Tier 3, macOS 10.15 is gone, Sonoma 14 is gone as a bottle target, and the new .pkg installer only runs on Apple Silicon. The same release adds a vulnerability scanner, swaps Bubblewrap for Landlock on Linux, and starts phasing out arbitrary Ruby in install hooks. It is the biggest change to the tool since the 4.0 move to JSON API metadata.
I run brew on dev machines and on CI runners, and I have opinions about which of these changes you'll feel first.
Intel is done, and it happened two weeks early
The release announcement says Intel bottles stopped because of "unreliable infrastructure." That is polite. A discussion thread on the Homebrew org gives the plain version: the macOS Intel CI runners were disabled on August 28 because they were "having serious issues," so no new Intel bottles have been built since. Tier 3 became real before 7.0.0 was tagged.
What Tier 3 means in practice:
- Existing Intel bottles stay on the CDN. If a formula hasn't changed since late August, you still get a binary.
- Any formula updated after that point builds from source on Intel. For gcc, llvm, or anything with a Rust toolchain, that takes an hour on a laptop.
- Homebrew keeps running on Intel until September 2027, then stops. Big Sur on Apple Silicon ends the same month.
- The project points Intel users at MacPorts, which still builds for hardware back to the Leopard era.
Mike McQuaid's reasoning on Hacker News was blunt: Apple dropped x86_64 from macOS 27, GitHub retires its Intel macOS runners in autumn 2027, and supporting macOS Intel has been "harder, slower and more expensive" for the project over the last few years than adding ARM Linux support. Homebrew has no employees. Volunteers were spending their time babysitting a platform its own vendor abandoned.
I don't love it, but I can't argue with it. A 2019 iMac is a fine machine. It is also a machine whose OS vendor, CI vendor, and package manager have all now set the same 2027 date. If you have Intel Macs in a build fleet, the fix is a migration plan, and the plan is not "wait and see." Downstream projects are already hitting this. Wazuh opened an issue because its Intel package build broke when Homebrew stopped publishing gcc bottles. Yours will break the same way, on whichever formula you depend on that updates next.
GitHub's macos-15-intel runner image stays free on public repos until August 2027, so a project can build its own Intel bottles for another year. Someone already set that up in a public intel-bottles repo. Whether you want your supply chain routed through a stranger's GitHub Actions is a separate question.
brew vulns is the feature that should have existed years ago
The new brew vulns command checks installed formulae against a Homebrew advisory database keyed on formula version and revision, fed by OSV.dev. Flags cover the obvious cases: --severity=high, --deps to include dependencies, --brewfile to scan a Brewfile instead of the live prefix, and --fix-available or --no-fix-available to split findings by whether an upgrade closes them. The advisory data is CC0 and published both in the formula API and as a downloadable index, so you can consume it from your own tooling without running brew.
This is an audit story more than a defense story. Most people I know who run brew on servers (yes, people do this, mostly for Linux one-offs and CI images) have no idea what version of curl or openssl is in /home/linuxbrew. Now a cron job can tell you, and the output keys on the same OSV identifiers your container scanner already uses.
The database only knows what someone has recorded against a formula. Coverage will lag NVD on day one. Treat a clean scan as "nothing known to Homebrew," not "nothing wrong."
The release also lists eight security advisories fixed across the 6.x line. The one to read is GHSA-rg9r-ppxp-87hm, rated High, fixed in 6.0.12: cask removal metadata was unsigned. The rest are moderate or low, and mostly about redirects, a cask escaping the sandbox through LaunchServices, and a patch target escaping the staged source tree. If you're still on a 6.0.x older than 6.0.12, that alone is the upgrade reason.
Landlock replaces Bubblewrap, and install hooks lose Ruby
Linux sandboxing now uses Landlock instead of Bubblewrap. Bubblewrap needed a setuid helper or user namespaces, which meant Docker containers needed extra capabilities to get a sandboxed brew. Landlock is a kernel LSM with no userspace dependency and no escalated permissions. Homebrew targets Landlock ABI 2, which landed in Linux 6.1, and warns when the kernel can't enforce network restrictions. Kernels without Landlock run unsandboxed and brew doctor tells you so.
If you build images from ghcr.io/homebrew/ubuntu22.04, that image is gone. Move to ghcr.io/homebrew/brew. The Homebrew/actions/*@master refs are gone too. Pin a CalVer release or a full SHA. Both of these will break a pipeline somewhere this week, and both are in the changelog, so nobody gets to be surprised.
The sandbox itself got tighter on both platforms. Downloads moved into the fetch phase, and the install phase has no network. Home directory reads are blocked by default inside the sandbox. Build tools talk over private temp directories. Casks can no longer launch apps, register Mach services, or connect to Unix sockets during install. That last set is a direct response to the LaunchServices escape.
The change with the longest tail is the install step migration. Formula post_install blocks and cask preflight, postflight, uninstall_preflight, and uninstall_postflight blocks are deprecated. They're replaced by post_install_steps and the matching *_steps forms: serialized, validated operations from a fixed list, instead of a Ruby block that can do anything. Official taps reject the old hooks now. Third-party taps get warnings until December 11, 2027, then the hooks stop running. brew style --fix converts the common patterns.
This is the right direction and it will hurt. A lot of private taps exist because someone needed a post_install that ran a shell command. Those taps have 15 months to express that command as a declared step or find another way. Some won't fit the fixed list. Those maintainers will complain, and the complaint will be fair, and the answer will still be that a package manager running unaudited Ruby with your user's permissions was never a good idea.
Speed, a GUI, and what to do this week
The performance work is real. Package preparation now overlaps with downloads, brew bundle shares setup work across a batch, and brew config and tap-info gather data concurrently. The first comment on Hacker News was about speed, and McQuaid replied that "a lot of time and energy has gone into performance work." On my reading of the changelog, the win comes from fewer subprocesses at startup and from reading bottle download info straight out of API metadata instead of evaluating formula files. Both are the kind of boring fix that compounds.
BrewUI is the official macOS app. It needs Tahoe 26 or later and installs with brew install homebrew-app. It browses packages, shows installed versions and dependencies, and prints the brew command it's about to run. I don't need it. The people who ask me why their Mac has a thing called Homebrew on it might. Showing the underlying command is the correct design choice, because it teaches the terminal instead of hiding it.
Bottles are also inching toward relocatability. Right now the relocation budget is 13 bytes on Apple Silicon macOS, 26 on Linux, and 10 on the remaining Intel bottles. The stated target is 64 bytes via padded builds, which would let bottles install to arbitrary prefixes without a rebuild. That matters for anyone who has fought /opt/homebrew versus /usr/local versus a prefix under a home directory in CI.
What I would do in the next few days, in order:
- Run brew update and confirm you land on 7.0.1, not 7.0.0. The point release, cut the same day, fixed an Xcode 27 requirement that wrongly applied to older macOS and a metadata bug during upgrades.
- Grep your CI for ubuntu22.04 images and @master action refs. Replace both.
- Run brew vulns --deps on every machine that has a prefix. Save the output. Run it again in a week and diff.
- List your Intel Macs, including the ones nobody admits are still building things, and put a date on them.
- If you maintain a tap, run brew style --fix and see how much of your post_install survives the conversion.
One more thing from the thread. Asked how much of the release was written with an LLM, McQuaid said "a lot of my work," reviewed locally first, with a flow that "feels a lot like reviewing human PRs locally." Homebrew/brew has had zero open issues since 6.0.0. I've been skeptical of infrastructure code written by a model, and I still am when nobody reads it. This is what it looks like when someone does.
My prediction: the Intel cutoff generates the most noise and the least breakage, because most Intel Macs still running brew are on stale formulae that already have bottles. The install step migration generates the least noise now and the most breakage in late 2027, when a few thousand private taps discover their hooks stopped firing.
