Speeding Up Mac mini Cloud Cold Starts with Homebrew Mirrors and Dependency Caching

It's 2am. You just paid $19.9 for a Mac mini M4 in a Hong Kong data center, and the SSH key landed in your inbox within five minutes. Eager to get started, you SSH in and type brew install node — then watch the progress bar freeze mid-download on a bottle. You refresh the terminal, curl times out, reconnects, and twenty minutes later you're still waiting on a tarball that should have taken three seconds. This isn't a network outage. It's the everyday latency of reaching Homebrew's official CDN from an overseas data center — and that latency resets every single time you spin up a fresh instance.

The scenario: a brand-new box, and dependency installs eat half your rental window

The upside of billing a cloud Mac mini by the day is you can spin one up whenever you need it. The downside is every new instance starts as a blank slate. After installing the Xcode Command Line Tools and running your team's setup.sh, the usual routine — a pile of brew install packages, a pile of npm install dependencies, another pod install pulling the CocoaPods spec index — hits official sources that all point overseas. Just the download time alone can burn through a chunk of what you paid for that day's rental. If you only rented for a single one-off task, that cost really stings.

Why the official sources are especially slow on cloud nodes

Homebrew's bottles (precompiled packages) live on GitHub Packages by default, and npm's official registry and the CocoaPods spec repo are likewise hosted on overseas infrastructure. Cloud providers' international egress bandwidth is usually fine, but routing quality to specific CDN edges varies a lot, and the TLS handshake plus DNS resolution on that first connection alone adds tens to hundreds of milliseconds. Multiply that across a few hundred dependencies and you're looking at minutes — sometimes hours — of waiting. It's not your machine that's slow. It's the path.

Three steps to a reusable acceleration setup

Step 1: Point Homebrew's repo and bottle domain at a mirror

First confirm whether your current Homebrew is already pointed at a reachable mirror, then update the environment variables in one pass. Restart your terminal session for them to take effect:

git -C "$(brew --repo)" remote set-url origin \
  https://mirrors.example-mirror.net/homebrew-core.git
export HOMEBREW_API_DOMAIN="https://mirrors.example-mirror.net/homebrew-bottles/api"
export HOMEBREW_BOTTLE_DOMAIN="https://mirrors.example-mirror.net/homebrew-bottles"
brew update

Add these three lines to ~/.zprofile so you don't have to repeat this setup on the next boot.

Step 2: Lock down your dependency list with a Brewfile

Don't type brew install one package at a time. Put your team's standard packages into a Brewfile, install them all in a single bundle run, and keep versions consistent across every node:

tap "homebrew/cask"
brew "node@20"
brew "cocoapods"
brew "watchman"
brew "git-lfs"
cask "visual-studio-code"

brew bundle --file=~/Brewfile

The Brewfile itself is only a few dozen lines — check it into your code repo. On a new box, just git clone the project repo and run bundle once. That's far faster than hunting down install commands one by one, and it won't leave you missing some hidden dependency.

Step 3: Point your language package managers at the same mirrors

Speeding up Homebrew only solves part of the problem — npm, pip, and CocoaPods each have their own default sources, and each needs configuring separately:

npm config set registry https://registry.example-npm-mirror.com
pip config set global.index-url https://pypi.example-mirror.com/simple
pod repo-art add master https://cdn.example-cocoapods-mirror.com/master.git

With all four paths swapped, the time it takes a brand-new Mac mini to go from unpacking dependencies to a first successful build looks dramatically different:

Switching mirrors isn't a free lunch: mirror sites sync from the official repos with a delay window of anywhere from a few minutes to a few hours. After a major version bump, run brew doctor first as a sanity check, then verify critical bottles with shasum -a 256 to confirm the hash matches the official release before promoting anything to production.

Snapshot your warmed-up environment and reuse it on the next boot

If you plan to re-rent the same node weekly or monthly, you can push this acceleration setup one step further. Once your dependencies are installed and a build has run successfully, archive ~/Library/Caches/Homebrew, the shared node_modules cache directories, and ~/.cocoapods into a single package and upload it to your own object storage — or just trigger a snapshot of the current instance directly from the OnceMini dashboard. Next time you renew or reinstall the OS, restore the disk state from that snapshot and you skip even the mirror-configuration step. In practice this user-directory cache bundle lands somewhere between 8GB and 15GB, which fits comfortably within OnceMini's SSD tiers starting at 256GB without eating into the storage quota you need for actual project files.

Checklist

Run through this before you go live — don't wait for a failed build to discover a missing step:

• Are all three Homebrew environment variables saved in ~/.zprofile (not just export-ed in the current session)?
• Is the Brewfile committed to the project repo, rather than sitting only in someone's local shell history?
• Have all three of npm, pip, and CocoaPods been switched to mirrors — not just Homebrew?
• Have the critical bottles been verified with a shasum check?
• If you're planning to re-rent the same node, has an environment snapshot already been taken?

Frequently asked questions