You own the developer toolchain for a team whose Macs and macOS CI runners install everything with Homebrew. How would you make that toolchain reproducible across machines, and what does Homebrew fundamentally make hard?

## Name the constraint first Homebrew is a **rolling release**. Its formula definitions describe the current version of a package, and `brew update` moves you to the newest definitions. There is no lockfile, no way to ask for an arbitrary past version, no resolver that reconstructs a previous state. Two engineers who onboard three weeks apart get different versions of everything, and neither can easily reproduce the other. Any answer that does not start here is describing a tool Homebrew is not. That is a deliberate design choice, not an oversight: Homebrew optimises for a single up-to-date version of everything on a personal machine, which is exactly what most Mac users want. ## Layer one: make the package set declarative `brew bundle` reads a `Brewfile` — a small Ruby DSL listing taps, formulae, casks and Mac App Store applications: ```ruby brew "jq" brew "node@20" cask "visual-studio-code" ``` `brew bundle dump` writes one from the current machine, `brew bundle install` applies it, `brew bundle check` verifies a machine matches, and `brew bundle cleanup` deals with what is not listed. `HOMEBREW_BUNDLE_FILE` points at a canonical file. This is a genuine win — the toolchain becomes a reviewed file in a repository instead of tribal knowledge — and it is important to be clear about what it does *not* do: the Brewfile names packages, not versions. It removes set drift, not version drift. ## Layer two: pin what can be pinned - **Versioned formulae.** Where upstream maintains parallel major versions, Homebrew exposes them as separate formulae: `[email protected]`, `node@20`, `postgresql@16`, `openjdk@21`. Naming those in the Brewfile pins the major version, which is usually the axis that matters. Minor versions still float. - **`brew pin`.** Pinning stops `brew upgrade` from moving a formula on a machine that already has it. It is a drift *brake*, not a reproducibility mechanism — a fresh machine still installs whatever is current, and pinned formulae eventually block dependents from upgrading. - **Environment discipline in CI.** `HOMEBREW_NO_AUTO_UPDATE=1` stops an incidental `brew install` from also fast-forwarding every formula definition mid-job; `HOMEBREW_NO_INSTALL_CLEANUP=1` stops it from deleting older kegs you may still be using. Both make CI jobs less surprising. ## Layer three: take the important things out of Homebrew The strongest move is scope reduction. Language runtimes and their packages are where version drift causes real incidents, and those have better answers than a system package manager: a per-project version manager pinning the runtime in a file inside the repo, plus the language's own lockfile for dependencies. Homebrew then installs the *version manager*, and the repo owns the versions. This also removes the worst Homebrew failure mode — an unrelated `brew upgrade` moving a language runtime out from under every project on the machine at once. Apply the same logic to build inputs. If a build's output depends on a tool's exact version, that build wants a container image pinned by digest, running on Linux CI, not a Mac with a Brewfile. The Mac is then an editor and a test host, not a build input. ## Layer four: control the supply For teams that need more, Homebrew supports: - **An internal tap.** A private repository of formula definitions your team controls, so a package's definition changes only when you change it. - **A bottle mirror.** `HOMEBREW_ARTIFACT_DOMAIN` redirects bottle downloads to a mirror you host, which gives availability and a measure of supply control. Both cost real maintenance. Reach for them when a genuine compliance or availability requirement exists, not by default. ## The fleet realities that bite - **Mixed architectures.** Intel Macs use `/usr/local`, Apple Silicon uses `/opt/homebrew`. No provisioning script, Makefile or CI job may hardcode a prefix; use `brew --prefix` and `HOMEBREW_PREFIX`. - **Casks self-update.** Applications installed as casks often update themselves, so the Brewfile records what was installed and the vendor decides what is running. For anything build-critical, that is disqualifying. - **Ownership and privilege.** Homebrew wants a prefix owned by the installing user and is unsupported under root. On managed machines with non-admin users or several accounts, that is an awkward fit, and you should know it before promising a fleet-wide install. - **CI runner images.** Hosted macOS runners come with Homebrew and a pile of preinstalled software that changes when the image is updated. Installing more at job time is slow and unpinned; baking your own image, or caching, is what makes those jobs repeatable. ## How to close the answer The principal-level answer is a scoping decision, not a tool list. Homebrew is excellent at what it is for — getting a working developer machine quickly, with community coverage no alternative matches — and structurally unable to guarantee reproducibility. So: a Brewfile for the declarative package set, versioned formulae and version managers for the versions that matter, containers and Linux CI for anything whose output must be reproducible, and a fully declarative alternative such as Nix only when the team's appetite genuinely justifies the operational cost. State the tradeoff out loud; interviewers at this level are listening for whether you know which problem you are refusing to solve.