Mac mini Cloud schneller starten: Homebrew-Spiegel und Dependency-Cache

Es ist zwei Uhr nachts, du hast gerade für 9 US-Dollar einen Mac mini M4 in einem Hongkong-Rechenzentrum gemietet, und der SSH-Schlüssel liegt schon nach fünf Minuten im Postfach. Voller Tatendrang loggst du dich ein und tippst als Erstes brew install node – und siehst dem Fortschrittsbalken zu, wie er beim Download des Bottles einfriert. Terminal neu laden, curl meldet Timeout und verbindet neu, zwanzig Minuten sind vergangen, und du wartest immer noch auf ein Tarball, das eigentlich in drei Sekunden fertig sein sollte. Das ist kein Netzwerkfehler, sondern die ganz normale Latenz, mit der Rechenzentren im Ausland auf das offizielle Homebrew-CDN zugreifen – und diese Latenz wartet bei jeder neu gestarteten Instanz erneut auf dich.

Szenario: Neue Maschine, aber die Abhängigkeiten fressen die halbe Mietzeit auf

Der Vorteil eines nach Tagen abgerechneten Cloud-Mac-mini ist, dass du ihn jederzeit hochfahren und wieder abschalten kannst – der Nachteil: Jede neue Instanz ist ein unbeschriebenes Blatt. Nach der Installation der Xcode Command Line Tools und einem Durchlauf des teaminternen setup.sh folgt der übliche Ablauf: ein Haufen Pakete über brew install, ein Haufen Abhängigkeiten über npm install, dann noch ein pod install, das den CocoaPods-Spec-Index neu zieht. Da alle offiziellen Quellen auf Server im Ausland zeigen, frisst allein die Downloadzeit locker so viel Arbeitszeit, wie die Tagesmiete der ganzen Maschine kostet. Wenn du die Instanz nur für einen Tag für eine einmalige Aufgabe gemietet hast, tut dieser Kostenpunkt besonders weh.

Warum die offiziellen Quellen auf Cloud-Knoten besonders langsam sind

Homebrew legt seine Bottles (vorkompilierte Pakete) standardmäßig auf GitHub Packages ab, auch die offizielle npm-Registry und das CocoaPods-Spec-Repository liegen auf Infrastruktur im Ausland. Die internationale Ausgangsbandbreite der Cloud-Anbieter reicht in der Regel aus, aber die Routing-Qualität zu den konkreten CDN-Knoten schwankt stark – gerade der TLS-Handshake beim ersten Verbindungsaufbau plus die DNS-Auflösung addieren sich schnell zu einer Latenz von einigen Zehn- bis mehreren Hundert Millisekunden. Multipliziert mit ein paar hundert Abhängigkeitspaketen wird daraus eine Wartezeit im Minuten- bis Stundenbereich. Nicht deine Maschine ist langsam, sondern die Leitung.

Drei Schritte zu einer wiederverwendbaren Beschleunigungs-Pipeline

Schritt 1: Homebrew-Repository und Bottle-Domain umstellen

Prüfe zuerst, ob dein Homebrew bereits auf einen erreichbaren Spiegel zeigt, und setze dann einheitlich die Umgebungsvariablen. Ein neuer Terminal-Session-Start macht die Änderung wirksam:

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

Trage diese drei Zeilen in ~/.zprofile ein, dann musst du sie beim nächsten Systemstart nicht erneut setzen.

Schritt 2: Abhängigkeitsliste mit einem Brewfile fixieren

Tippe nicht jedes Paket einzeln über brew install ein, sondern trage die im Team üblichen Pakete in ein Brewfile ein und installiere sie mit einem einzigen bundle-Lauf – so bleibt die Version über mehrere Knoten hinweg konsistent:

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

brew bundle --file=~/Brewfile

Das Brewfile selbst umfasst nur ein paar Dutzend Zeilen, gehört ins Code-Repository, und bei einer neuen Maschine reicht ein git clone des Projekts plus ein weiterer Bundle-Lauf. Das ist deutlich schneller, als jedes Mal einzeln nach Installationsbefehlen zu suchen, und es geht keine versteckte Abhängigkeit verloren.

Schritt 3: Sprachpaket-Manager auf dieselben Spiegel umstellen

Die Homebrew-Beschleunigung löst nur einen Teil des Problems – npm, pip und CocoaPods haben jeweils eigene Standardquellen, die einzeln konfiguriert werden müssen:

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

Sobald alle vier Verbindungen umgestellt sind, zeigt sich der Zeitunterschied bei einer brandneuen Mac mini vom Entpacken der Abhängigkeiten bis zum ersten erfolgreichen Build sehr deutlich:

Der Wechsel zu Spiegeln ist kein Free Lunch: Spiegelserver synchronisieren die offiziellen Repositories mit einer Verzögerung von wenigen Minuten bis zu mehreren Stunden. Nach wichtigen Versions-Upgrades solltest du erst brew doctor als Selbsttest durchlaufen lassen und zentrale Bottles zusätzlich per shasum -a 256 prüfen, ob der Hash mit der offiziellen Veröffentlichung übereinstimmt, bevor du in den Produktionsworkflow gehst.

Vorbereitete Umgebung als Snapshot sichern und beim nächsten Boot direkt wiederverwenden

Wenn du planst, denselben Knoten wöchentlich oder monatlich weiterzumieten, kannst du die Beschleunigungs-Pipeline noch einen Schritt weiterdenken: Sobald Abhängigkeiten installiert sind und ein Build erfolgreich durchgelaufen ist, packe ~/Library/Caches/Homebrew, die gemeinsamen Cache-Verzeichnisse von node_modules und ~/.cocoapods in ein Archiv und lade es in deinen eigenen Objektspeicher hoch – oder löse in der OnceMini-Konsole einen Snapshot der laufenden Instanz aus. Beim nächsten Verlängern oder Neuinstallieren stellst du einfach den Festplattenzustand aus dem Snapshot wieder her – selbst die Spiegel-Konfiguration entfällt damit. In der Praxis liegt dieses gepackte Nutzerverzeichnis-Cache-Archiv zwischen 8 und 15 GB; bei den ab 256 GB großen SSD-Stufen von OnceMini ist dafür locker Platz, ohne dass die Speicherquote für die eigentlichen Projektdateien darunter leidet.

Checkliste

Geh diese Punkte vor dem Go-Live einzeln durch – warte nicht erst auf einen fehlgeschlagenen Build, um einen fehlenden Schritt zu entdecken:

• Stehen alle drei Homebrew-Umgebungsvariablen in ~/.zprofile (nicht nur per export in der aktuellen Session gesetzt)?
• Ist das Brewfile ins Projekt-Repository eingecheckt, statt nur in der lokalen Terminal-Historie einer einzelnen Person zu liegen?
• Sind npm, pip und CocoaPods alle drei auf Spiegel umgestellt, nicht nur Homebrew?
• Wurde bei zentralen Bottles einmal eine shasum-Prüfung durchgeführt?
• Falls derselbe Knoten weitervermietet werden soll: Wurde bereits ein Umgebungs-Snapshot erstellt?

Häufig gestellte Fragen