# zerobrew: a Homebrew client that reuses bottles and deduplicates them

> zerobrew is an experimental Rust client for the Homebrew ecosystem that adds content-addressable storage and APFS clonefiles on top of Homebrew formulas and bottles. It is fast on repeat installs, unmaintained as of its README, and not a drop-in replacement for brew.

**lucasgelfond/zerobrew** — A 5-20x faster experimental Homebrew alternative

- Repository: https://github.com/lucasgelfond/zerobrew
- Stars: 7,543 · Forks: 181
- Language: Rust
- License: Apache-2.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/lucasgelfond-zerobrew

## What zerobrew solves, and who it is actually for

Homebrew installs a package by fetching a bottle, unpacking it, and linking files into a prefix. When you install a second package that shares dependencies, the shared parts are fetched and unpacked again. On macOS that repeated work shows up as time spent waiting, especially on a fresh machine or in CI.

zerobrew is a client for that same ecosystem, written in Rust. The README describes it as "a performance-optimized client for the Homebrew ecosystem" that relies on Homebrew's formula definitions from homebrew-core, Homebrew's pre-built bottles, and Homebrew's package metadata. It does not maintain its own formula repository. That distinction matters: zerobrew is not a fork of Homebrew's package set, it is a different way of fetching and storing the same artifacts.

The intended audience is someone who already uses brew, installs many packages, and wants the second and third installs to be cheaper. The README is explicit that it is experimental and recommends running it alongside Homebrew rather than replacing it. Anyone looking for a self-contained package manager with its own catalog is looking at the wrong project.

## Content-addressable storage and APFS clonefiles

The README names three areas of work: content-addressable storage for deduplication, APFS clonefiles for zero-overhead copying, and source build fallback using Homebrew's Ruby DSL.

Content-addressable storage means files are keyed by their content hash rather than by package name and version. Two packages that ship an identical file, a shared dylib or a common header, resolve to one entry in the store. Installing the second package does not duplicate the bytes. The README also lists `zb gc`, described as garbage collect unused store entries, which only makes sense if there is a shared store with reference counting behind it.

APFS clonefiles are a macOS-specific mechanism. A clone is a copy-on-write reference to existing file data, so creating it is cheap and does not consume additional disk space until one side is modified. The README calls this "zero-overhead copying". This is why the performance table shows a large gap between cold and warm runs: the warm number benefits from store entries that already exist. On a cold run the bytes still have to arrive.

The workspace layout in Cargo.toml reflects the split: `zb_core`, `zb_io` and `zb_cli` are separate crates. `zb_io` is where fetching and unpacking live, judging by the dependency list, which includes reqwest with rustls, flate2, tar, xz2, zstd and zip, plus rusqlite with the bundled feature. A bundled SQLite suggests local state is kept in a database file rather than in flat metadata. The README does not document the schema.

## Installing zerobrew and running a first bundle

The README gives two install paths. The standalone installer is a shell script served from zerobrew.rs:

```bash
curl -fsSL https://zerobrew.rs/install | bash
```

The README states the installer updates your shell config, and that you should restart your terminal or run the `source` command it prints. The alternative is through Homebrew itself:

```bash
brew install lucasgelfond/zerobrew/zerobrew
```

If you used the standalone installer, updates mean rerunning the same script. If you installed through Homebrew, the README gives `brew update && brew upgrade zerobrew`.

Once `zb` is on your path, the quick start covers the common operations. Installing one package or several:

```bash
zb install jq
zb install wget git
```

Brewfile handling is the part worth testing first, because it is how most people would move an existing setup across:

```bash
zb bundle
zb bundle install -f myfile
zb bundle dump
zb bundle dump -f out --force
```

The README does not say what `zb bundle` does when no Brewfile is present, so run `zb bundle dump` first and inspect the output before trusting a round trip. There is also a way to run a binary without linking it into your prefix:

```bash
zbx jq --version
```

That is the safest first command to try, since it exercises the install path without modifying your linked environment.

## The performance table is narrower than it looks

The README publishes a table comparing Homebrew and zerobrew on the top 100 packages: 452s for Homebrew against 226s cold and 59s warm, which it reports as 2.0x cold and 7.6x warm. It also lists individual packages. libsodium is given as 2353ms for Homebrew, 392ms cold, 130ms warm. tesseract is 18950ms, 5536ms, 643ms.

Two things in that table deserve attention. The first is ffmpeg, listed at 3034ms for Homebrew and 3481ms cold. That is a cold slowdown, 0.9x, and it is the only row in the table where Homebrew wins. The README includes it rather than omitting it, which is a point in the project's favour, but it also means the 5-20x claim in the repository description does not hold uniformly. Cold installs are roughly twice as fast overall, not five to twenty times.

The second is what warm means. Warm numbers depend on store entries already being present, so they measure the cost of linking and cloning rather than the cost of downloading. A first install on a clean machine gets the cold number. The 7.6x figure describes the second install of the same or overlapping packages, which is a real scenario but not the one people usually imagine when they read a speed claim.

## Unmaintained status and the Homebrew dependency

The README carries a warning block stating that zerobrew is "currently unmaintained", and directs CVE reports or other critical security issues to two email addresses. That is the most important fact on the page. The last push to the default branch was on 2026-09-02, and the most recent release, v0.3.2, is dated 2026-06-12. Whatever the commit activity looks like, the maintainer's own statement is that the project is not being maintained.

For a tool that fetches and unpacks archives from the network, that status has a direct consequence. The dependency list in Cargo.toml includes a pinned rustls range, `>=0.23.26, <0.24`, with a comment explaining that newer reqwest pulls a rustls 0.24-dev version lacking the aws-lc-rs feature. Pinning like that is normal, but a pinned TLS stack in an unmaintained project is a thing you have to track yourself. The README points security reports at two addresses rather than at a process.

The second structural constraint is the dependency on Homebrew itself. zerobrew uses Homebrew's formulas, bottles and metadata. If Homebrew changes how bottles are structured or where metadata lives, zerobrew has to follow, and there is no stated commitment that it will. The README's own advice is to run it alongside Homebrew and not to purge Homebrew and replace it, unless you are sure about the implications.

## How it differs from Homebrew and from other clients

The obvious comparison is brew itself. Homebrew is a Ruby program with a large formula repository, its own update mechanism for that repository, and a linking model built around a prefix. It is maintained, it is the reference implementation for the ecosystem, and it handles the long tail of formulas that need custom build logic. zerobrew does not attempt to replace the formula layer at all; it consumes it. The difference is in the storage and linking layer, where zerobrew adds a shared content-addressed store and, on macOS, clonefile-based copies.

The README also mentions uv-style architecture, referring to the Python package installer whose design separates resolution from installation and keeps a global cache. zerobrew applies that shape to Homebrew packages. That is a design lineage, not a compatibility claim: a uv-style cache does not make zerobrew a Python tool, and it does not make it a general replacement for uv.

People searching for a zerobrew alternative often land on nanobrew, but this repository says nothing about nanobrew's design or scope, so any comparison between the two would be guesswork. What can be said from the repository is narrower: zerobrew is a client with a different storage layer, not a different package catalog.

## Licence and the cost of keeping it running

The repository is dual-licensed under Apache 2.0 OR MIT, at your choice. Both licence files are present at the top level, LICENSE-APACHE.md and LICENSE-MIT.md, and the README states the dual licensing explicitly. There is also a file named LICENSE-HOMEBREW in the repository root, which is consistent with the project reusing Homebrew-derived definitions and shipping their licence text alongside. Anyone redistributing zerobrew or bundling it into a larger product should read both licence files and that third one rather than assuming the dual licence covers everything in the tree. This is not legal advice.

The upgrade cost is the part that is easy to underestimate. The toolchain requires Rust 1.96 per the workspace manifest, and the release profile uses fat LTO with a single codegen unit and `panic = "abort"`, so a from-source build is not quick. The README's documented update paths are the installer script and `brew upgrade zerobrew`, both of which fetch a prebuilt binary. Given the unmaintained status, the practical question is not how to upgrade but whether a new release will exist. Pinning a known-good version and watching the repository yourself is the honest posture here.

## Conclusion

Adopt zerobrew only if you want to measure its cold and warm install behaviour next to brew on the same machine, and you are comfortable keeping Homebrew installed as the fallback. Do not adopt it as your only package manager: the README states it is unmaintained, it leans on Homebrew's formulas and bottles, and it warns against purging Homebrew. Before you rely on it, verify that the packages you actually need resolve, that `zb bundle dump` reproduces your Brewfile, and that `zb reset` leaves your brew installation untouched.

## FAQ

### Is it safe to install Homebrew on my Mac?

That question is about Homebrew, not zerobrew. The README of this project does not address Homebrew's own safety; it only recommends running zerobrew alongside Homebrew rather than replacing it.

### What is a good alternative to Homebrew on macOS?

The README positions zerobrew as a performance-optimized client for the Homebrew ecosystem rather than a replacement, and recommends running the two alongside each other. It relies on Homebrew's formulas, bottles and metadata.

### Is it worth installing Homebrew on a Mac?

The README does not discuss whether Homebrew itself is worth installing. It only states that zerobrew depends on Homebrew's formula definitions, pre-built bottles and package metadata.

### Do I have Homebrew installed on my Mac?

The README does not describe how to check whether Homebrew is present. It does note that zerobrew can be installed through Homebrew with `brew install lucasgelfond/zerobrew/zerobrew`, which implies brew is on the path in that case.

### zerobrew vs brew: what is the difference?

zerobrew is a client for the Homebrew ecosystem rather than a replacement for it. It uses Homebrew's formulas, bottles and metadata, and its own work is in content-addressable storage, APFS clonefiles and a source build fallback through Homebrew's Ruby DSL.

## Sources

- [Issues](https://github.com/lucasgelfond/zerobrew/issues)
- [License: Apache-2.0](https://github.com/lucasgelfond/zerobrew/blob/main/LICENSE)
- [lucasgelfond/zerobrew on GitHub](https://github.com/lucasgelfond/zerobrew)
- [README](https://github.com/lucasgelfond/zerobrew/blob/main/README.md)
- [Releases](https://github.com/lucasgelfond/zerobrew/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lucasgelfond-zerobrew
