Für wen: Plattform- und Build-Teams, die Nix Flakes auf Remote-Mac-CI im Jahr 2026 betreiben und klären müssen, wie sich flake.lock-Pins bewegen, welche Substituter vor cache.nixos.org stehen und wie max-jobs mit APFS-I/O kollidiert.

Sie erhalten: eine dreizeilige Cache-Gegenüberstellung (lokal / öffentlich fern / firmennah), ein kopierfertiges nix.conf-Fragment mit substituters, trusted-public-keys, max-jobs und cores, Befehle zum Aktualisieren und Zurückrollen des Lockfiles sowie eine Retry-Leiter und Platten-Watermarks, die Stampede-Effekte gegenüber weit entfernten Binary-Caches vermeiden.

Vertiefung ohne Login: Technisches Blog (Übersicht), ergänzend die GHCR-/Registry-Pull-Matrix, wenn OCI-Layer und Nix-Artefakte dieselbe SSD teilen, sowie die MacPull-Startseite für Kapazitätskontext.

Strukturierte Daten: Diese Seite liefert JSON-LD für BlogPosting, Article, BreadcrumbList, HowTo und FAQPage — passend zur Checkliste unten.

Warum Flake-Inputs und Substituter auf Mac-Pools scheitern

Auf Apple Silicon wirken Runner oft „CPU-müßig“, während der Daemon auf narinfo-Roundtrips wartet, sich Flake-Eingaben ohne reviewed PR verschieben oder trusted-public-keys den neuen Firmen-Cache nicht kennen. Klassifizieren Sie Vorfälle als Lockfile-Drift, Substituter-Politik oder Platte plus Parallelität — sonst drehen Sie alle drei Regler gleichzeitig und erschweren die Postmortem-Analyse.

Mit Blick auf 2026: Mehr Teams mischen Rosetta-legacy-Pfade, deterministische Checks und große nixpkgs-Snapshots; ohne dokumentierte Cache-Reihenfolge und ohne Disk-Gates verschärft sich die Konkurrenz um denselben APFS-Band auf geteilten Remote-Macs.

1
Stille Lockfile-Drift: Entwickler führen lokal nix flake update aus, pushen breite Eingabe-Sprünge — und CI kompiliert plötzlich LLVM, weil der entfernte Cache diesen Graphen nie vorwarmte.
2
Grenzüberschreitende Substituter-Latenz: cache.nixos.org zuletzt zu listen klingt schlau, der Daemon prüft aber jeden Host; Reihenfolge und geografische Nähe wiegen genauso schwer wie Rohbandbreite.
3
Store-Konkurrenz: max-jobs zu erhöhen ohne freien Speicher erzeugt lange nix-store-Sperren und blockiert Nachbar-Pipeline-Beine derselben Matrix.

Vergleich: lokale Binary-Cache-Treffer vs. Remote-Substituter vs. eigener Cache

Die Tabelle ist Ihr Routing-Vertrag: Primärpfad, dokumentierter Fallback und klarer Owner für Invalidierung — besonders wichtig, wenn grenzüberschreitende Pulls mit Compliance-Vorgaben kollidieren.

Quelle Stärken Risiken Sinnvoll wenn
Lokale Binary-Cache-Treffer (warmer /nix/store) Kein Netz-RTT; beste Wiederholbarkeit bei identischen flake.lock-Zeilen. Kalte Worker zahlen volle Fetch-Kosten; Mandantenfähigkeit erfordert saubere Store-Berechtigungen. Nacht-Warmer oder Hydra-ähnliche Feeds befüllen den Store bereits.
Remote-Substituter (Vendor- oder Community-CDN) Kein eigener Cache-Betrieb; breite Abdeckung gängiger nixpkgs-Hashes. WAN-Latenz, TLS-Inspection, sporadische 5xx dominieren die Wandzeit. Eingaben bleiben nah am Upstream und Richtlinien erlauben öffentliche CDNs.
Eigener Binary-Cache (gleiche Metro wie Runner) Planbare Latenz, signierte NARs unter Ihrer Kontrolle, Raum für Audit-Logs. Sie betreiben Schlüsselrotation, GC und Kapazität selbst. Rechtliche oder Latenzvorgaben verbieten, jedes Artefakt aus der Ferne zu beziehen.

Kopierbare nix.conf inkl. Platten- und Retry-Parameter

Fragment nach /etc/nix/nix.conf mergen oder per Konfigurationsmanagement ausrollen, dann den Nix-Daemon auf macOS neu starten. Substituters strikt in Priorität: vertrauenswürdigster, nächstgelegener Cache zuerst; cache.nixos.org als Fangnetz — sofern Policy nichts anderes vorschreibt.

# Remote-Mac-CI Baseline 2026 — Hostnamen/Keys anpassen
substituters = https://YOUR-NEARBY-SUBSTITUTER.example https://cache.nixos.org
trusted-public-keys = YOUR-NEARBY-SUBSTITUTER.example:YOURSIGNINGKEY== cache.nixos.org-1:6NCHdD59Z431t0A2VuUAgwCm9zPXAgEVJj5sRdfGC9LBukJCvQywFrpF4cD0H+3hz509uE+2wlJYwiGS9VSFMUXM78mKrQJpB8A/jDmpCDi838ZY4aWKg==
max-jobs = 2
cores = 0

Platten-Watermarks für das Nix-Store-Volume

Messen Sie die APFS-Partition, die /nix bzw. NIX_STORE_DIR trägt. Überschreitet die belegte Kapazität etwa 82 %, Warnungen auslösen; ab ca. 87 % neue Builds drosseln; ab ca. 92 % hart stoppen und nix-collect-garbage nur nach freigegebener Retention-Policy.

Fetch-Retry-Leiter (Sekunden, Jitter addieren): 1 → 3 → 9 → 27, Wandzeit-Obergrenze etwa 90 s für transiente TLS-/HTTP-Fehler; bei 401 oder fehlendem narinfo sofort abbrechen — kein Hammern gegen einen nicht autorisierten Cache.

Flake-Lockfile: Update- und Rollback-Befehle

Lock-Updates aus vertrauenswürdiger Workstation oder Bot-Account ausführen, damit CI keine anonymen Eingabe-Sprünge überrascht. Commit-Nachricht soll jede geänderte Eingabe nennen.

# Alle Flake-Inputs aktualisieren und Lockfile committen
nix flake update --commit-lock-file

# Nur eine Eingabe (z. B. nixpkgs) vorziehen
nix flake lock --update-input nixpkgs

Bei Regression gezielt zurückrollen statt halbe Graphen zu mischen:

# Vorherige flake.lock-Revision aus Git wiederherstellen
git checkout HEAD^ -- flake.lock

# Einzelne Eingabe auf bekannte gute Revision pinnen
nix flake lock --override-input nixpkgs github:NixOS/nixpkgs/<REV>

Fünf CI-Gates vor nix build auf Remote-Macs

  1. Disk-Probe: df -g /nix (oder Store-Mount) parsen — bei frei < ca. 20 GiB oder Belegung über Drossel-Schwelle mit Fehler beenden.
  2. Lock-Diff-Review: Job fehlschlagen lassen, wenn flake.lock ohne Ticket-ID in der Commit-Nachricht geändert wurde.
  3. Substituter-Smoke: kurzes nix path-info gegen Ihr Check-Attribut mit Timeout, damit narinfo-Pfade auflösbar sind.
  4. Begrenzter Build: nix build --option max-jobs 2 und ausführliche Logs, damit hängende Downloads sichtbar werden.
  5. Post-Build-GC: nix-collect-garbage --delete-older-than 30d nur nach erfolgreichem Lauf und wenn die Platte wieder unter die Warnschwelle fiel.

Für Pools, die parallel Container ziehen, siehe Build-Pool: parallele Pulls & Platten-FAQ — damit Docker und Nix nicht blind um dieselbe APFS-Scheibe ringen.

Runbook-Parameter (zitierfähig)

Referenz A: Start mit max-jobs = 2 und cores = 0; nur anheben, wenn nar-Fetch-p95 eine Woche lang flach bleibt.

Referenz B: Mindestens 20 GiB frei auf dem Store-Volume für Multi-Arch-Checks vorsehen.

Referenz C: Substituter-Reihenfolge als Code dokumentieren: firmennah zuerst, öffentlicher CDN zuletzt (sofern nicht umgekehrt vorgeschrieben) — niemals einen Host ohne passenden trusted-public-keys-Eintrag listen.

FAQ: Vertrauensfehler, langsame narinfo, Rollback

„cannot add substituter“ / nicht vertrauenswürdig. trusted-users für CI-Konten prüfen und jeden Cache-Schlüssel in trusted-public-keys ergänzen — nach macOS- oder Nix-Upgrades fehlt die zweite Zeile oft.

Plötzlich alles aus Quelle. nix flake metadata mit letztem grünem Lock vergleichen; fehlender Substituter-Key oder blockierter CDN-Pfad ist häufiger als ein echtes nixpkgs-Totalausfall.

Zeitreise ohne Überraschung. git revert auf flake.lock bereithalten, chirurgische Pins mit nix flake lock --override-input bevorzugen, lange nix-store --query --requisites-Archive nur mit Legal-Freigabe.

Fazit: Eingaben pinnen, Caches ordnen, zuerst die Platte

Im Remote-Mac-CI 2026 wird Nix vorhersagbar, wenn flake.lock diszipliniert bleibt, Substituter-Vertrauen explizit ist, max-jobs konservativ startet und Automatisierung platten-first denkt. Behandeln Sie grenzüberschreitenden NAR-Verkehr wie jedes teure Dependency: messen, Retries deckeln, Rollback des Locks dokumentieren.

Brauchen Sie dedizierte Apple-Silicon-Hosts mit Kontrolle über nix.conf, Store-Pfad und ausgehende Allowlists? Öffentlich ohne Login: Preise, Kaufen, Hilfe-Center, der Technische Blog und die Startseite.

Remote-Mac-CI für Nix Flakes ausgelegt

Mac-Mini-Klasse per SSH/VNC, dimensionierte SSDs für den Nix-Store und Raum für private Substituter nahe Ihrer Build-Flotte.

Preise ansehen Plan kaufen Hilfe Blog