Installing ffmpeg and its eleven dependencies takes Homebrew roughly 24.5 seconds on a warm cache. Nanobrew does it in 0.287 seconds.
That number—zero-point-two-eight-seven seconds—feels like a typo. It's the kind of claim that makes developers reflexively reach for the benchmarking tools, certain something's been measured wrong. But the assertion is real, documented in automated CI runs, and it sits at the heart of an audacious new open-source package manager that launched in late March positioning itself as a drop-in replacement for the macOS development staple.
The tool weighs just 1.2 MB. It's written in Zig. And it emerged from Bay Area developer Rach Pradhan's effort to rethink package management from scratch while maintaining full compatibility with Homebrew's ecosystem of over 6,500 packages—same formulas, same bottles, same cask definitions. Just none of the Ruby runtime, and none of the waiting.
The architecture is built for milliseconds.
Nanobrew's performance doesn't come from a single clever trick. It's a stack of deliberate technical choices, each shaving microseconds. The project leverages APFS clonefile for nearly instantaneous copy-on-write materialization, sidestepping the filesystem churn that bogs down traditional installs. Parallelism runs throughout: downloads, extraction, dependency resolution—all concurrent. The manager uses Zig's native HTTP client rather than shelling out to curl. It parses Mach-O binaries directly to batch codesign operations.
Under the hood sits a content-addressed store keyed by SHA256, streaming the hash calculation during download rather than running it as a separate pass. The single static binary doesn't need a Ruby interpreter (Homebrew's runtime alone clocks in around 57 MB), and Nanobrew parses formula files line-by-line from GitHub, interpreting the Ruby DSL on the fly.
According to Pradhan's mid-February blog post detailing the architecture, this combination allows the tool to handle simple packages in under ten milliseconds on warm installs. The landing page claims it's "faster than echo." Which is either hyperbole or the kind of performance claim that makes you want to see the receipts.
The receipts, it turns out, are compelling
The project's automated CI benchmarks, last updated in late March on GitHub Actions running macOS 14 with Apple Silicon, show dramatic gaps. Installing tree with zero dependencies: Homebrew takes 4.070 seconds, Nanobrew 0.009 seconds. For wget with six dependencies, the warm install drops from 3.935 seconds to 0.027 seconds.
The ffmpeg example—the headline 85x claim—compares Homebrew's roughly 24.5 seconds against Nanobrew's 0.287 seconds for a warm install with eleven dependencies. Cold installs show smaller but still substantial gains: ffmpeg goes from 14.252 seconds to 0.287 seconds in the same CI environment.
These numbers come with caveats, naturally. Early benchmark documentation noted that cold multi-dependency installs were sometimes slower than Homebrew because parallel downloads weren't fully wired up, though the code has evolved rapidly since. The README acknowledges measurements are single runs meant to be representative rather than rigorous statistical samples—a caveat any graduate-level statistician would insist on.
Linux performance tells a more mixed story. While Pradhan's mid-March LinkedIn post claimed nanobrew with native .deb support was 2–2.8x faster than apt-get for bundles like curl with 32 dependencies, the project's late-March CI snapshot shows apt-get slightly outpacing nanobrew on some of those same workloads—7.168 seconds versus 10.033 seconds for curl, for instance. Environment differences likely account for the variance, though it's a reminder that benchmarks are finicky beasts.
Compatibility comes with asterisks
Nanobrew installs to /opt/nanobrew/ to avoid colliding with Homebrew at /opt/homebrew/. A migration command—nb migrate—imports existing Homebrew packages, and the two can coexist on the same machine. The tool supports third-party taps by pulling formula files directly from GitHub repositories, and cask support covers .dmg, .pkg, .zip, and .tar.gz formats.
But full parity remains a work in progress. Nanobrew doesn't run Ruby post_install hooks, which some formulae rely on for final configuration. Complex custom build options aren't supported. Mac App Store integration via mas isn't available. The README is refreshingly candid about these gaps, listing them under "What doesn't work (yet)."
One deliberate difference stands out: cask installs skip macOS's quarantine attribute, meaning downloaded apps open without Gatekeeper prompts. The README frames this as a feature—"No quarantine"—though it represents a philosophical break from Homebrew. The official Homebrew project removed its --no-quarantine flag in version 5.0.0 last November, aligning with Apple's security expectations and responding to concerns from enterprise users managing fleet security.
For developers tired of clicking through warnings on every new tool, nanobrew's approach is undeniably convenient. For IT administrators managing fleet security, it may be concerning. Your mileage, as they say, will vary.
Security hardening in real time
The project's launch wasn't entirely smooth. Between late March, Pradhan shipped seven rapid-fire releases (v0.1.069 through v0.1.075) addressing security issues flagged during community scrutiny. Release notes detail tar path traversal protections, SHA256 checksum enforcement for packages that previously installed without verification, HTTP redirect limits, and cask symlink validation.
Version 0.1.075 is the current stable release. The flurry of fixes suggests the tool benefited from adversarial review—perhaps more than the developer initially anticipated—but also that it shipped before every edge case was locked down. That's not necessarily damning for a 0.1.x release, though package managers occupy a category where trust and security matter acutely.
Nanobrew isn't alone in trying to speed up Homebrew.
Zerobrew emerged in January with similar promises: content-addressed storage, APFS clonefile, and 5–20x performance claims. The late-March nanobrew benchmarks include Zerobrew as a comparison point, showing nanobrew ahead in the tested scenarios—though the document also notes a Zerobrew failure case on wget related to Mach-O path handling.
Both projects reflect broader frustration with Homebrew's performance, particularly as developers juggle larger dependency trees and CI pipelines where every second compounds. Homebrew itself has been iterating—version 5.0.0 added download concurrency, and 5.1.0 brought further parallelism improvements in March—but the fundamental architecture of a Ruby-based tool with shell-out operations has limits. You can only optimize so much before you're rebuilding the engine.
Nanobrew represents a more radical bet: that rewriting the entire stack in a systems language optimized for speed can unlock order-of-magnitude gains without fragmenting the package ecosystem. The fact that it consumes Homebrew's existing formula and bottle infrastructure means developers can test it with minimal friction.
Installing nanobrew via Homebrew itself—brew tap justrach/nanobrew && brew install nanobrew—is a particular bit of self-referential irony that Pradhan seems to enjoy.
What it means for developers (and what it doesn't)
For individual developers, nanobrew offers a compelling value proposition if speed is the bottleneck. The warm-install benchmarks suggest it could shave meaningful seconds off repetitive tasks—installing a quick diagnostic tool, refreshing a dependency before a build, setting up a fresh environment. Those seconds add up.
The Linux .deb support is intriguing for Docker workflows. Replacing apt-get install with nb install --deb in a Dockerfile could trim build times, though the mixed benchmark results suggest the gains won't be universal. The project provides a nb-linux binary for x86_64 and aarch64.
For teams and IT administrators, the calculus gets more complex. The lack of Gatekeeper quarantine on casks, the absence of post-install hook support, and the rapid security patching during launch week all point to a tool that's moving fast but still maturing. The Apache 2.0 license and active GitHub repository (github.com/justrach/nanobrew) provide transparency, but version 0.1.075 is hardly battle-tested at scale.
The broader question is whether the macOS package management ecosystem benefits from competition or suffers from fragmentation. Homebrew's dominance has made it a de facto standard, which comes with both stability and inertia. Tools like nanobrew push the envelope, but they also introduce new variables—different edge case behaviors, different security postures, different maintenance trajectories. Whether that's healthy churn or unnecessary fragmentation depends, perhaps, on who you ask.
For now, nanobrew sits in that intriguing category of developer tools that are too fast to ignore but too young to bet the infrastructure on. Its 0.287-second ffmpeg install is real in a specific CI environment; whether it holds up across the messy reality of every macOS configuration remains to be seen.
But for a single developer annoyed by twenty-second installs, downloading a 1.2 MB binary and typing nb install tree just to see what happens? That's a low-stakes experiment worth running. Sometimes the fastest way to evaluate a tool that claims to be impossibly fast is simply to watch it work.
