2026 OpenClaw auf gemietetem Mac Mini: GitHub API orchestriert Nacht-Batch-Ketten mit workflow_dispatch, Checkpoints und Backoff-Alarmen

Token mit Minimalrechten

Der im Job erzeugte GITHUB_TOKEN hilft nicht, wenn der Auslöser außerhalb des Repositories auf dem Mac Mini sitzt. Nutzen Sie ein Fine-grained Personal Access Token, strikt auf ein Repository begrenzt. Für reine Dispatch-Läufe reichen typischerweise Actions: Read and write (damit Workflows gestartet werden dürfen) und Contents: Read (damit Referenzen und Metadaten konsistent bleiben)—breitere Admin- oder Org-Scopes bleiben tabu, weil Lecks hier teuer sind.

Bewahren Sie das Secret außerhalb von Git ab, setzen Sie chmod 600 und injizieren Sie es per launchd-Umgebungsvariable oder Keychain-Wrapper. Rotieren Sie kurz—bei Verdacht auf Exposure sofort. Bei höherem Reifegrad trennen Sie Lesen und Schreiben später in ein GitHub App-Installationstoken; für ein Runbook in einer Nacht reicht ein sauber begrenztes PAT. Ergänzend lohnt der Abgleich mit der Batch-Warteschlangen- und Backoff-Matrix, damit Ihre Nachtfenster nicht mit CPU- oder RAM-Spitzen kollidieren.

Dokumentieren Sie im Handbuch explizit, welche API-Pfade das Token jemals aufrufen darf (nur dispatches plus optional runs lesen). Jede zusätzliche Berechtigung erhöht den Blast-Radius bei einem Leak und erschwert SOC-Reviews. Wenn mehrere Personen Zugriff brauchen, lieber zwei kurzlebige Tokens mit getrennten Namenskonventionen als ein „Super-PAT“.

Cron und launchd als Nachtauslöser

Auf einem 7×24-Host ist launchd meist robuster als klassisches cron, weil Jobs nach Wake-from-sleep und kurzen Netz-Aussetzern zuverlässiger neu anlaufen—wichtig, wenn der Mini nachts wartungsarm, aber nicht „klinisch tot“ sein soll. Definieren Sie genau einen primären Trigger; parallele Definitionen in cron und launchd erzeugen doppelte Dispatches und schwer auditierbare Alarme.

Der HTTP-Aufruf geht an /repos/{owner}/{repo}/actions/workflows/{dateiname}.yml/dispatches mit JSON-Körper ref (meist main) und inputs. Setzen Sie Accept: application/vnd.github+json und einen sprechenden User-Agent. GitHub antwortet mit 204, wenn die Anfrage syntaktisch akzeptiert wurde—verifizieren Sie dennoch über die Runs-API, ob ein Lauf wirklich eingeplant wurde.

curl -sS -X POST \
  -H "Authorization: Bearer ${GITHUB_DISPATCH_TOKEN}" \
  -H "Accept: application/vnd.github+json" \
  -H "User-Agent: runmini-openclaw-nightly" \
  https://api.github.com/repos/ORG/REPO/actions/workflows/night-chain.yml/dispatches \
  -d '{"ref":"main","inputs":{"chain_id":"'"$(date +%Y%m%d)"'","resume_from":"0"}}'

Legen Sie die lokale Zeitzone explizit fest und dokumentieren Sie das Nachtfenster (typisch 01:00–05:00 Uhr Ortszeit), damit Wartungsarbeiten am Gateway nicht mit Spitzenlast kollidieren. Fernzugriff und Konsolenpfade finden Sie im Hilfe-Center.

Optional können Sie vor dem eigentlichen Dispatch einen leichten Preflight einbauen: kurzer GET auf den Standardbranch oder die Metadaten des Workflows mit einem read-only-zweiten Token—so erkennen Sie Drift in Dateinamen früh, bevor die Nachtkette startet. Halten Sie den Preflight schlank (Timeout unter fünf Sekunden), damit der 7×24-Knoten nicht selbst zum Engpass wird.

Idempotente Prüfpunkte

Selbst saubere Cron-Ausdrücke verpassen keinen zweiten Tick, wenn ein vorheriger Lauf hängt—deshalb brauchen Sie eine idempotente Checkpoint-Datei auf dem NVMe des Miet-Mac. Schreiben Sie nach jedem erfolgreichen Dispatch ein kleines JSON mit chain_id, run_id und Zeitstempel. Wiederholen Sie keine identische chain_id innerhalb desselben Nachtfensters, wenn der Checkpoint bereits „completed“ meldet.

Auf GitHub-Seite ergänzen Sie concurrency: mit einer stabilen Gruppe und cancel-in-progress: false, damit parallele Doppelstarts nicht gegeneinander arbeiten, sondern in eine wartende Schlange fallen. Kombinieren Sie das mit der Daemon-Health-Webhook-Anleitung, damit lokale Prozesse und entfernte Actions denselben Gesundheitsbegriff teilen. Für Plattenbudgets und Log-Wachstum siehe Log-Rotation und Speicher-Schwellen.

Fehler-Webhooks und Backoff-Alarme

Wenn ein Workflow scheitert, reicht ein grüner 204 beim Dispatch nicht. Konfigurieren Sie in GitHub einen workflow_run-Webhook, der nur bei failure ein minimales JSON an Ihr OpenClaw-HTTPS-Gateway sendet (Repository, Workflow-Name, Run-URL, commit_sha, conclusion). Halten Sie den Payload klein, signieren Sie optional mit HMAC und begrenzen Sie IPs—dies spiegelt das Muster aus den Observability-Artikeln, bleibt aber bewusst schlanker als ein vollständiges SIEM-Onboarding.

Implementieren Sie clientseitig Backoff: bei 429 strikt Retry-After respektieren; bei 5xx exponentielles Warten mit Obergrenze (z. B. Start 2 s, Maximum 60 s, fünf Versuche, 20 % Jitter). Serien von 401 deuten auf abgelaufenes PAT hin—dann Alarm ohne blindes Retry. So bleibt Ihre 7×24-Betriebskette auditierbar und rauscharm.

Minimal reproduzierbare Schritte

1. Workflow-Datei night-chain.yml mit ausschließlich on.workflow_dispatch und Inputs chain_id, resume_from anlegen—kein schedule.
2. Fine-grained PAT erzeugen, auf dieses Repo begrenzen, Actions+Contents wie oben setzen, als GITHUB_DISPATCH_TOKEN auf dem Mac ablegen.
3. Einmalig manuell per curl dispatchen und in der GitHub-UI prüfen, ob Inputs im Log auftauchen.
4. launchd-plist mit Umgebungsvariable und ProgramArguments (Shell-Skript mit obigem curl) aktivieren; Zeitzone im Skript ausgeben.
5. Checkpoint-JSON unter z. B. ~/Library/Application Support/OpenClaw/nightly-chain.json schreiben; Skript überspringt doppelte chain_id.
6. Repository-Webhook workflow_run (nur failure) auf OpenClaw-Endpunkt richten; Testfail provozieren und Alarmtext validieren.

Damit ist die Kette lokal getaktet, API-gesteuert und klar von GitLab-Schedules getrennt—ideal für Teams, die GitHub als Ausführungsort, den RunMini-Knoten aber als autonome Betriebsuhr behandeln wollen.

Nach dem ersten produktiven Lauf sollten Sie einen Game-Day einplanen: Token absichtlich widerrufen, Netzwerk kurz drosseln und einen künstlichen Workflow-Fehler auslösen. So validieren Sie gemeinsam mit On-Call, dass Webhook, Backoff und Checkpoint-Meldungen im Ticket-System lesbar ankommen—ohne dass die Tags mit Rauschen überfüllt werden.

FAQ

Warum nicht einfach on.schedule in Actions nutzen?

Weil Sie damit die Uhr an GitHub binden und das Muster optisch dem GitLab-Cron nähert. Hier soll der Miet-Mac die Fensterlogik besitzen und dispatch als bewusstes API-Ereignis führen.

204, aber nichts passiert

Dateiname des Workflows (inkl. Groß/Klein), ref gegen den Standardbranch, geschützte Branch-Regeln und exakte Input-Namen prüfen; Runs-API auf queued oder skipped filtern.

Doppelstarts um Mitternacht

Prüfen, ob sowohl cron als auch launchd dasselbe Skript starten; nur einen Weg behalten und Checkpoint plus concurrency nutzen.

Nächster Schritt: Dedizierten Apple-Silicon-Knoten für OpenClaw und nächtliche GitHub-Dispatches wählen—Preise öffnen und auf kaufen.html ohne Anmeldung bestellen. Hilfe-Center für Fernzugriff, weiterführende Ops-Artikel im Blog.