Viele Teams wollen auf einem Bare-Metal-Remote Mac mini M4 in Singapur, Tokio, Seoul, Hongkong, US East oder US West tagsüber Xcode-Archive und GitHub Actions Self-Hosted-Runner fahren und nachts dieselbe Maschine an OpenClaw oder einen anderen KI-Agenten ausleihen. Scheitern tut man selten am Doppel-Install, sondern an Simulator-Port-Konflikten, Warteschlangen-Inflation und Keychain-Überlagerung zwischen Signatur-Identitäten und Bot-Tokens. Dieser Leitfaden liefert eine Go/No-Go-Kapazitätsmatrix, drei Zeitfenster-Vorlagen, ein Sieben-Schritte-Rollback und eine Konfig-Tabelle für den Maschinen-Split statt Dauer-Kokation. Preise: NOVAKVM Mietpreisseite; Bestellung: Bestellseite; Remote-Richtlinien: Hilfezentrum. Ergänzend: GitHub Actions Remote-Runner und OpenClaw Multi-Workspace.
Nach dem Lesen sollten vier Fragen ohne Diskussion beantwortbar sein: wann Ausleihen verboten ist; wie Werktags-Spitze, Nacht-Batch und Release-Freeze-Woche sich in Labels unterscheiden; wie Rollback über Warteschlangentiefe und Baseline läuft; wann M4 Pro oder parallele Knoten in derselben Region sinnvoller sind als harte Kokation. Runner-Semantik und OpenClaw Gateway bitte nach jedem Upstream-Release in der offiziellen Doku prüfen.
[ SECTION_01 ] // PAIN_POINTS Fünf Stolpersteine, wenn CI und KI-Agent einen Remote-Mac teilen
Unklare Verantwortung: CI und Agent-Ops ändern jeweils Runner-Labels, aber niemand unterschreibt das Ausleihfenster — Agenten halten Simulatoren während PR-Spitzen warm. Falsche Queue-Diagnose: „Mehr Jobs“ statt Ressourcen-Sättigung; ein zusätzliches macos-ci-Label kann die Median-Wartezeit von etwa zwölf auf über fünfunddreißig Minuten treiben. Umgebungs-Bleed: ein macOS-Benutzer, eine Keychain für Archive-Signatur und Kanal-Tokens — nach dem Fenster bleibt Halb-Konfiguration.
Simulator- und Port-Erschöpfung am Morgen nach langer Agent-Session: WebDriver-Mehrfachinstanzen oder hängende XCTest-Geräte erzeugen „device busy“. Miet-Fehlpassung: Monats-M4 Pro nur zum Testen der Kokation, danach dauerhaft für Doppel-Last reserviert bezahlen.
- Label-Drift: eingehende
macos-ci-Tags bleiben in der Agent-Phase aktiv. - Kein Standby: ohne zweiten Runner in der Region ist Ausleihen Single Point of Failure.
- Unbegrenzte Agent-Läufe: mehrtägig ohne Checkpoints füllt das System-Volume.
- Gemeinsame Credential-Pfade: Modell-Keys, Kanal-Tokens und CI-Zertifikate in einem Verzeichnis blockieren Rollback.
- Schreibzugriffe im Freeze: Agenten signieren oder schreiben in die DB während Release-Freeze.
Kokation funktioniert als Zeitfenster plus Labels plus Credential-Trennung — nicht als „CI nachts einfach aus“.
In der Praxis scheitern viele Piloten, weil der Wechsel zwischen CI- und Agent-Modus nicht im Change-Tool landet. Ohne dokumentierte Fenster fehlt die Grundlage für Metriken: niemand weiß, ob ein Queue-Anstieg vom Agent, von mehr PRs oder von einem schlechten DerivedData-Cache stammt. Wer Kokation ernst nimmt, behandelt jedes Ausleihen wie einen produktionsnahen Cutover mit Owner, Rollback-Kriterium und Kommunikation an beide Seiten.
[ SECTION_02 ] // LENDING_MATRIX Go/No-Go-Ausleih-Matrix und drei Zeitfenster-Vorlagen
Vor dem Wechsel von CI- in Agent-Modus die harte Schleuse unten durchgehen. Jede Zeile in der Stopp-Spalte bedeutet: Ausleihe pausieren oder Standby-Kapazität nachziehen.
| Signal | Go (ausleihen) | No-Go (pause) |
|---|---|---|
| Standby-Runner in-Region | ≥1 Host für Smoke und Hotfix | Kein Backup; Ausleihe = Ausfallrisiko |
| Warteschlangentiefe | ≤ historischer Median × 1,2 | >1,5× Median über zwei Stunden |
| Agent-Zeitbudget | ≤90 Minuten mit Checkpoints | Ohne Cap oder mehrtägige Belegung |
| Credential-Isolation | Eigener User oder Keychain-Partition | Gemeinsame Signatur- und API-Dateien |
| Release-Freeze | Nur-Lesen-Agent (kein Schreiben/Signieren) | Freeze-Woche mit Schreib-/Sign-Pfaden |
Drei Zeitfenster-Vorlagen (Stunden auf die Hauptzeitzone des Teams mappen; Beispiel UTC+8 Werktag):
Die Vorlagen sind bewusst konservativ. Werktags-Spitzenabschirmung schützt Merge-Queues und manuelle Archive-Läufe. Die Nacht-Slice begrenzt Agent-Laufzeit und erzwingt Label-Entzug, damit GitHub keine neuen CI-Jobs auf den Host legt. Die Freeze-Woche priorisiert Notarisierung — hier ist „nur kurz Agent anwerfen“ der häufigste Auslöser für Vorfälle.
| Vorlage | Zeitraum | CI-Labels | Agent |
|---|---|---|---|
| Werktags-Spitzenabschirmung | 10:00–19:00 | Volles CI; keine Ausleihe | Aus oder Nur-Lesen-Healthchecks |
| Nacht-Batch-Slice | 23:30–06:00 | Eingehende macos-ci-Tags entfernen |
Ausleihe erlaubt; max. 90 Minuten |
| Release-Freeze-Woche | ±7 Tage um Release | Nur Archive und Notarisierung | Nur-Lesen; kein Kanal-Write-back |
[ SECTION_03 ] // RUNBOOK Runner-Labels verengen, Jobs ablaufen lassen, Sieben-Schritte-Rollback
Ausleihen ist ein auditierbarer Change, kein Einzeiler „Dienste stoppen“. Die Schritte verknüpfen Labels, Queue, Metriken und Rollback, damit CI nach dem Agent nicht in eine schmutzige Umgebung schedult.
Schritt drei und vier sind die häufigsten Abkürzungen: Labels entfernen, während noch Archive laufen, oder Jobs killen, um den Agent früher zu starten. Beides verlängert die Queue am nächsten Tag. Der Baseline-Snapshot in Schritt fünf ist Ihr objektives Rollback-Signal — ohne ihn wird „es fühlt sich langsamer an“ zur endlosen Debatte zwischen CI- und Agent-Teams.
- Change-Ticket: Hostname, Ausleihfenster, CI- und Agent-Verantwortliche; Freeze-Wochen mit Doppel-Freigabe.
- Standby beweisen: Smoke auf zweitem In-Region-Runner; dringende PR-Jobs müssen ankommen.
- Eingehende Labels verengen:
macos-ci(und Peers) auf Org-/Repo-Ebene entfernen. - Laufende Jobs ablaufen: nach SLA warten; Archive-/Notarisierungs-Jobs nicht killen.
- Baseline erfassen: Warteschlangentiefe, laufende Jobs, CPU, freier Platz auf System-Volume.
- Ausleihe ausführen: Agent starten (z. B. OpenClaw Gateway); Disk-Slope und Simulator-Belegung beobachten.
- Rollback: Agent stoppen, Labels zurück, Smoke; Queue > Baseline ×1,3 → nächste Ausleihe aussetzen.
#!/bin/bash
RUNNER_NAME="${1:-novakvm-m4-sg}"
gh api "repos/${GITHUB_REPOSITORY}/actions/runners" --jq \
".runners[] | select(.name==\"$RUNNER_NAME\") | .labels[].name"
test -z "$(gh api ... | grep -c macos-ci)" && echo "CI_LABELS_OFF"
Self-Hosted-Runner-Labels und Queue-Verhalten stehen in der GitHub-Dokumentation. Link nach Upstream-Änderungen erneut öffnen.
OpenClaw Gateway Dauerbetrieb und Neustart laut Projekt-Repository.
https://github.com/openclaw/openclaw
[ SECTION_04 ] // CONFIG_REGION M4-Konfig-Stufen, sechs Regionen, wann Hosts trennen
Brauchen Werktags-CI-Spitze und Nacht-Agent beide SLA, stößt ein Host meist zuerst an RAM und Simulator-Pools. Die Tabelle ist Grenzleitfaden, kein Hersteller-Benchmark.
Planen Sie DerivedData und Simulator-Caches getrennt, sobald Agent und CI denselben Benutzer teilen würden. Selbst auf M4 Pro 64GB kann ein voller Parallel-Test-Tag plus nächtlicher Multi-Workspace-Agent die I/O-Grenze früher treffen als die CPU-Anzeige. Monitoring auf System-Volume-Füllstand und Queue-Tiefe ist Pflicht, nicht Kür.
| Stufe | CI-Spitze | Nacht-Agent | Empfehlung |
|---|---|---|---|
| M4 16GB / 256GB | 1–2 leichte Lanes | Nur-Lesen oder <30 Minuten | Kein Voll-Agent über Nacht dauerhaft |
| M4 24GB / 512GB | 3–4 moderate Lanes | ≤90 Minuten mit Checkpoints | Simulator-Pools und DerivedData trennen |
| M4 Pro 64GB / 2TB | Archive plus parallele Tests | Multi-Workspace / Kanal-Spitzen | Freeze-Woche trotzdem splitten oder parallelisieren |
| Parallel in-Region | CI-Only-Host | Agent-Only-Host | Entfernt Ausleih-/Rollback-Risiko |
Sechs-Regionen-Affinität: Runner nahe Artefakt-Speicher, Modell-API-Roundtrips und Integrationszielen. Singapur für Südostasien; Tokio/Seoul für Ostasien-On-Call; Hongkong für interaktives Debugging in Südchina; US East/US West für atlantische bzw. pazifische Kollaboration. Tages- und Wochenmiete reichen für einen vollen Ausleihe→Rollback-Zyklus; bei stabiler Queue Monatsmiete; Spike-Wochen mit Parallel-Knoten.
Wenn beide Lastprofile dauerhaft hoch sind, ist Parallelisierung in derselben Region oft günstiger als ein einzelner M4 Pro mit 24-Stunden-Umschaltung. Ein Host nur für CI behält stabile Simulator-Pools und DerivedData; der Agent-Host kann eigene Nutzer, Keychain-Partition und Neustart-Zyklen haben. Der operative Aufwand steigt moderat, der Ausfallrisiko durch halbe Rollbacks sinkt stark.
[ SECTION_05 ] // DATA_FAQ Kennzahlen, FAQ und Bare-Metal-Umsetzung
Die Werte sind Review-Bandbreiten für Kapazität und Miete — keine Hersteller-Claims.
Nutzen Sie sie in Architektur-Reviews und Kapazitätsgremien, nicht als SLAs gegenüber dem Business. Wenn Ihre Median-Wartezeit dauerhaft über der 1,2×-Schwelle der Go/No-Go-Matrix liegt, ist das ein Signal für mehr Runner-Kapazität — nicht für längere Agent-Fenster. Umgekehrt: stabilisiert sich die Queue nach einem erfolgreichen Rollback, können Sie Wochenmiete rechtfertigen, statt jeden Monat neu zu verhandeln. Bei personenbezogenen Daten in Logs oder Artefakten gehört die Trennung von CI- und Agent-Benutzern zusätzlich in Zugriffs- und Aufbewahrungsdokumentation — unabhängig von der Mietstufe.
- Queue-Verstärkung: auf gesättigtem Host können Extra-Labels P50-Warte von ca. 12 Minuten auf 35+ Minuten heben.
- Agent-Cap: ohne Checkpoints ≤90 Minuten, damit Logs/Simulatoren den nächsten CI-Tag nicht vergiften.
- Change-Vorlauf: Ausleihe und Freeze 24–48 Stunden ankündigen, Rollback-Slot reservieren.
- Standby: mindestens ein In-Region-Runner für Smoke — sonst null Redundanz.
- Rollback-Trigger: Post-Ausleihe Queue > Baseline × 1,3 → nächste Ausleihe gesperrt bis Root Cause weg.
FAQ
- F: CI tagsüber, OpenClaw nachts? A: Ja, wenn Go/No-Go passt und Label-Verengung plus Sieben-Schritte-Rollback laufen.
- F: Queue schon lang — trotzdem ausleihen? A: Nein. Erst Lanes reduzieren oder Standby.
- F: Release-Woche? A: Agent nur Lesen; Archive/Notarisierung exklusiv; kein Signieren/Schreiben durch Agent.
- F: Reicht Tagesmiete? A: Ja für einen vollen Ausleihe→Rollback-Zyklus; Dauer-Kokation eher Woche dann Monat.
- F: Brauchen wir zwei GitHub-Organisationen? A: Nicht zwingend — Label-Trennung und getrennte macOS-Benutzer reichen oft; zwei Orgs helfen bei strikter Compliance.
Geteilte virtualisierte Mac-Clouds zerstören Ausleihfenster durch Nachbar-Lärm und undurchsichtige Wartung. Ein Dienst-Laptop neben CI bringt Schlaf, lokale Simulator-Reste und nicht auditierbares Rollback. Wer tagsüber iOS/macOS-CI und nachts KI-Agenten auf dediziertem Apple Silicon mit sechs Regionen und Miet-Stufen braucht, landet oft sauberer bei NOVAKVM Mac-mini-Bare-Metal-Miete: exklusive Hosts, labelgeroutete Runner, Parallelität in-Region — vom einen Nacht-Agent-Test bis zur release-wochenfreien Kokation. Vor dem nächsten Change: Go/No-Go-Tabelle und Sieben-Schritte-Rollback ins gleiche Ticket — das schlägt die Debatte „CI nachts einfach aus“.