Image: GitHub
Why it mattersRebuilding a developer laptop or a CI image spends most of its time inside Homebrew, so a client that installs the same bottles with the same prefix layout and finishes a 100-package set in under two minutes removes a long wait from the loop.
Setting up a new Mac for development, or rebuilding a CI image, mostly means waiting for Homebrew to install one package after another. A new Rust client called zerobrew, built by a developer who goes by @cachebag, downloads the same bottles Homebrew does and installs them with a different method. Across 100 packages the author timed on 2026-10-08, Homebrew took 776 seconds cold and 638 seconds warm. zerobrew took 117 seconds and 9.3 seconds. That is 6.6 times faster cold, 68 times faster warm.
The repository has 7,702 stars and 181 forks on GitHub, and reached the front page of Hacker News this morning with 75 points. The project was created in January 2026 and the latest commit landed last night. It is dual-licensed under Apache 2.0 or MIT, at the user's choice.
What the measurement actually shows
The 100-package table in the README was run on a MacBook Pro with an M3 Pro and 18 GB of RAM, on macOS 26.6.2, on a 318 Mbit/s connection, against Homebrew 7.0.8 and zerobrew 0.3.5. A cold run starts with the package and all its dependencies uninstalled and an empty download cache. A warm run keeps the downloads from the cold run in cache but reinstalls from scratch. The median package was 5.3 times faster cold and 56 times faster warm. Of the 100 packages, 24 installed at least 100 times faster warm. The author also ran the full table on a 69 Mbit/s link and reports 3.3 times faster cold and 69 times faster warm, which lines up with the explanation that cold installs are mostly bound by the download.
A smaller version of the benchmark runs in GitHub Actions on every change. The timing workflow installs a fixed set of formulae with both tools on the same runner and fails the build if zerobrew is less than 1.5 times faster cold or 3 times faster warm on any of them. A parity workflow checks that the resulting prefixes match Homebrew's byte for byte.
Why the install step is faster, in the author's own words
The README states, and the author repeats in a note at the end, that zerobrew does not build or maintain anything. Every package it installs is a bottle Homebrew's build farm produced, tested and published. The speed difference is in what happens after the download. Homebrew, written in Ruby, evaluates each formula, unpacks the bottle, rewrites embedded paths with install_name_tool, and re-signs each binary one at a time. zerobrew runs the relocation in-process and links from a content-addressed store, which it says lets it pay the time for the download and little else. It uses APFS clonefiles for copies, which is why installs that resolve to cached content are measured in milliseconds.
The author is explicit about what this depends on: Homebrew's formula definitions, Homebrew's pre-built bottles, and Homebrew's package metadata. The project is positioned as a performance-focused client for the Homebrew ecosystem. The README recommends running zerobrew alongside Homebrew rather than purging the one and installing the other, and labels the project experimental.
Source
- Repository and benchmark table: zerobrewhq/zerobrew on GitHub
- Hacker News discussion
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.