2026 Multi-Region Mac mini M4
Pulumi Remote-State, S3-Lease, parallele Preview & Buildsperren-Merge — Abnahme-Matrix

Dieser Leitfaden ergänzt die Orchestrierungssicht aus Nomad-Affinität, Buildsperre & 1TB/2TB-Matrix und die Artefakt-Fan-out-Logik aus rsync-Matrix & Buildsperren; für parallele Xcode- und Simulator-Lasten siehe Xcode Parallel Testing & Disk-Abnahme. Die Tabellen sind Abnahme-Hilfen — keine Ersatzpolitik für Backups, Bucket-Versionierung oder IAM-Reviews.

Kurz-Matrix: Remote-State, Lease, CI und Buildsperre

Nutzen Sie die Tabelle als Merge-Checkliste vor dem Live-Gang: jede Zeile sollte auf Ihren Buckets, Lock-Backends und Runner-Laufzeiten belegt sein — nicht nur auf dem Papier der Pipeline-YAML.

Hebel	Empfohlene Richtung (M4-Mehrregionen)	Typische Fehlkonfiguration
State-Backend	S3-kompatibel + dediziertes Locking (z. B. DynamoDB oder vom Anbieter unterstütztes natives Locking)	State ohne Locking — parallele up korruptieren dieselbe State-Datei
Parallele preview	Shard-IDs im CI, getrennte Arbeitsverzeichnisse; pulumi preview nur lesend oder mit klarer Queue vor up	Zwei Shards, gleicher Checkout, kein flock — Provider-Caches und Plugins kollidieren
apply / up	Seriell pro Stack-Name; Lease-TTL > pessimistische Pipeline-Dauer + WAN-Puffer	TTL zu kurz → Lock-Thrash; zu lang → hängende Runner blockieren andere Teams
Buildsperre + State	flock umschließt Schritte mit Schreibzugriff auf gemeinsame Trees; State-Lock schützt die Wahrheit im Bucket	Nur eines von beidem — doppelte Schreiber bleiben unsichtbar bis zum nächsten Deploy

Ergänzend zur Tabelle gehört ein klarer Runbook-Abschnitt für Ausfälle: Was passiert, wenn der Lock-Anbieter throttelt oder ein Regionen-Link zum Objektspeicher für Minuten weg ist? Dokumentieren Sie, welcher Operator pulumi cancel ausführen darf, wie lange ein manuell freigegebener Lock maximal brachliegen darf, und wie Sie einen „stuck stack“ ohne Datenverlust aus der Warteschlange holen. Auf dedizierten M4-Buildern lohnt sich außerdem ein fester Provider-Cache außerhalb des State-Baums: weniger wiederholte Downloads verkürzen die effektive Lock-Inanspruchnahme und senken die Varianz Ihrer TTL-Messreihen. Verschlüsselung serverseitig (SSE-KMS oder vergleichbar) und getrennte IAM-Rollen pro Umgebung sollten in derselben Abnahme-Session wie die Matrix besprochen werden — nicht erst beim ersten Audit.

Zustandsdatei-Pfad und Bucket-Disziplin

Vergeben Sie pro Umgebung (dev, staging, prod) und pro Stack ein festes Präfix im Bucket, z. B. s3://pulumi-org/env/stack/pulumi.json — nicht pro CI-Build-Nummer. So bleiben IAM-Policies lesbar, Lifecycle-Regeln greifen vorhersehbar und Runbooks auf allen Mac mini M4-Knoten identisch.

Trennen Sie außerdem Artefakt- und State-Präfixe: Binär-Caches und Plugin-Verzeichnisse gehören nicht unter denselben Key-Baum wie der serialisierte Zustand. Teams, die rsync-Fan-out nutzen, sollten explizit dokumentieren, welcher Runner allein pulumi up schreiben darf — analog zum „Golden Node“ in der Nomad-Matrix.

Benennen Sie Stacks und Pfade so, dass pulumi stack rename oder Backend-Wechsel selten nötig sind: jede Umbenennung erzeugt sonst doppelte Objektpräfixe, die in IAM- und Lifecycle-Tests übersehen werden. Für Mehrmandanten-Setups empfiehlt sich ein Präfix pro Mandant und pro Region, damit versehentliche Cross-Region-Writes im Runbook sofort auffallen — unabhängig davon, ob der eigentliche Workload in us-east-1 oder auf einem europäischen Edge liegt.

• Abnahme: pulumi stack ls und Backend-URL auf jedem Region-Runner identisch; keine verwaisten Präfixe nach Umbenennung.
• Abnahme: Bucket-Versionierung oder Point-in-Time-Recovery-Strategie dokumentiert — nicht nur „wir haben S3“.
• Abnahme: Kurzer pulumi refresh-Zyklus für Lese-Jobs definiert; Schreib-refresh nur mit explizitem Change-Fenster.

Lease-TTL und Lock-Erwerb

Die Leasingperre muss länger leben als Ihr längster realistischer preview+up-Pfad inklusive Provider-Downloads auf frischen M4-Workern — sonst verlieren Sie den Lock mitten in der Operation oder erzeugen Warteschlangen mit irreführenden Timeouts.

Orientierung: messen Sie zehn Läufe auf einem kalten Cache; nehmen Sie das 95.-Perzentil, addieren Sie 25–40 % für WAN- und API-Jitter zwischen Region und Objektspeicher, und setzen Sie die TTL knapp darüber. Kürzer wirkt „sauber“, verschärft aber Flapping; länger verschleppt echte Hänger — ergänzen Sie daher harte Pipeline-Timeouts und manuelle cancel-Playbooks.

Prüfen Sie, ob Ihr Lock-Backend Heartbeats oder einmalige Leases nutzt: Heartbeat-Modelle verlangen gesunde Prozesse auf dem Mac mini M4-Runner; wenn der Agent eingefroren ist, kann ein Lease verlängert werden, obwohl kein Fortschritt existiert — dann helfen nur äußere Watchdogs und maximale Job-Dauer. Einmalige Leases ohne Renewal sind einfacher zu argumentieren, bestrafen aber lange Netzunterbrechungen härter. Dokumentieren Sie die Semantik neben der TTL-Zahl, damit On-Call und Entwickler dieselbe Mentalität teilen.

Profil	TTL-Richtwert (Indikativ)	Wann anpassen
Lean preview-only	Deckt nur Lesephase — State-Lock selten nötig; trotzdem Queue vor parallelen Plugin-Schreibern	Wenn Provider-Plug-ins dennoch denselben Cache-Baum beschreiben
Standard up	TTL ≈ längster gemessener Lauf × 1,3–1,4	Bei neuen Provider-Major-Versionen erneut messen
Langläufer / Datenmigration	Eigenes Fenster + Read-only-Flag für andere Shards bis Abschluss	Wenn mehrere Regionen sequentiell mutieren müssen

CI-Fragmentierung (Sharding) für parallele Preview

Sharding bedeutet hier: jede parallele Pipeline erhält eine eigene Arbeitskopie oder ein isoliertes Arbeitsverzeichnis, eindeutige PULUMI_HOME-Pfadkomponente und klar definierte Eingabevariablen — nicht dieselbe pulumi-Instanz auf einem geteilten Tree ohne Koordination.

Für reine preview-Wellen können Sie die Parallelität höher drehen, solange kein Shard heimlich Provider in einen gemeinsamen Cache schreibt. Sobald ein Shard Artefakte materialisiert oder lokale Zwischenstände für up vorbereitet, greift dieselbe Buildsperre-Logik wie bei nativen Builds: ein flock pro Repo-Pfad serialisiert konfliktträchtige Schritte, während der Remote-State-Lock weiterhin die Infra-Wahrheit serialisiert.

Verzahnen Sie das mit Job-Platzierung aus der Nomad-Matrix (siehe Einleitung), falls Nomad (oder ein vergleichbarer Scheduler) Ihre M4-Runner bindet: Shards auf unterschiedliche Hosts zu verteilen reduziert thermische und APFS-Konkurrenz — der State-Lock allein löst keinen lokalen I/O-Sturm.

In CI-Systemen mit Matrix-Builds sollten Umgebungsvariablen wie PULUMI_CONFIG_PASSPHRASE oder cloud-spezifische Tokens pro Shard injiziert werden, ohne dass Geheimnisse in Artefakt-Logs landen. Markieren Sie jedes Shard mit einem sichtbaren Label (shard=2/5) in der Konsolenausgabe — das erleichtert die Zuordnung, wenn zwei Previews zeitgleich scheitern und nur einer den State berührt hat. Wenn ein Shard ausschließlich Plan-Artefakte erzeugt, definieren Sie explizit, welcher Schritt die JSON/HTML-Reports wegschreibt und wo sie nach der Retention wieder verschwinden, damit die 1TB/2TB-Schwellen nicht durch vergessene Report-Ordner gerissen werden.

Entscheidungsmatrix: 1TB- vs. 2TB-Disk-Wasserstände (Pulumi-Caches)

Provider-Plugins, temporäre Plan-Artefakte und parallele Worktrees füllen SSDs auf 1TB- und 2TB-Mac mini M4 unterschiedlich schnell. Die Schwellen sind konservativ; kalibrieren Sie an Ihrer Plugin-Retention und an parallelen Xcode-/Testlasten aus dem Parallel-Testing-Leitfaden (siehe Einleitung).

SSD-Profil	Warn-Wasserstand (frei)	Hard-Stop / Maßnahme	Skalierungs-Hinweis
1TB + Pulumi/CI	< ca. 220 GB frei (24h gleitend)	Keine zusätzlichen parallelen Shards; Plugin-Cache säubern; ggf. zweiten M4-Knoten ordern	Strikte Quoten für PULUMI_HOME und Derived-Data-Pfade
2TB + Pulumi/CI	< ca. 380 GB frei (24h gleitend)	Fan-out drosseln; langlebige Artefakte auf Objektspeicher verlagern	Mehr Retention möglich — trotzdem pro Team Budget setzen

Merge-Abnahme: Preview, Buildsperre und apply zusammenführen

1. State lesen: Ein Runner führt pulumi preview mit produktionsgleichem Backend aus; Ausgabe artefaktieren.
2. Buildsperre: Schritte mit Schreibzugriff auf gemeinsame Repos per flock serialisieren — siehe Muster in der Nomad-/CI-Dokumentation.
3. apply/up: Seriell pro Stack; nach erfolgreichem Lauf Lock sauber frei (keine Zombie-Prozesse auf M4-Runnern).
4. Disk: df -h und optional Inode-Check — unterhalb der Matrix-Warnlinie kein weiteres Shard starten.
5. Post-Merge: Artefakt-Sync laut rsync-Matrix (siehe Einleitung) nur vom freigegebenen Knoten aus.

Kurzfassung & Kaufentscheidung

Wer Pulumi über mehrere Regionen auf Mac mini M4 fährt, sollte S3-kompatibles Remote-State mit belastbarem Locking, feste State-Pfade, CI-Sharding ohne geteilte Schreibbäume und eine dokumentierte Lease-TTL messen statt raten. Ergänzen Sie flock für lokale Wahrheit und die 1TB/2TB-Matrix für nachhaltigen Headroom. Wenn Warnschwellen wiederholt greifen, skalieren Sie horizontal mit einem weiteren dedizierten M4-Knoten — das entlastet APFS und WAN effektiver als nur längere Locks.