2026 OpenClaw Frontend-Praxis:
Cloudflare Pages Deploy Hook → Remote Mac: Smoke, Security-Headers-Patrouille & Build-Summary
Zielgruppe: Teams auf Cloudflare Pages, die nach jedem Build Edge-Cache, Security-Header und echte Browser gemeinsam prüfen. Abgrenzung zum Netlify-Hook-Runbook: CF Deploy Hook, Purge, Header-Diff (_headers vs. Messung), curl-Batch, dann Playwright; OpenClaw orchestriert Gateway und Digest. Mehr: Pre-Deploy-Smoke, CSP/Safari, HTTP/3-curl, SW-Freigabe, Build-Metriken.
Slug (Dateiname): 2026-openclaw-cloudflare-pages-deploy-hook-remote-mac-howto.html
01 Warum Cloudflare Pages Hook, Cache und Header separat modellieren
Grüner Build ≠ sichtbare Änderung: Edge-Cache, Workers und Service Worker entscheiden. Header kommen aus _headers, Regeln oder Workern — ohne „Purge → curl → Header-Diff → Smoke“ sind Tickets nicht reproduzierbar.
Deploy Hook → OpenClaw-Gateway → Remote Mac: WebKit- und Chromium-Pfade auf Apple-Hardware, dieselbe Shell lokal wie gemietet.
Typische Fallen: unnötiger Voll-Purge; Diff ohne getrennte Preview/Prod-Baseline; lange Hooks blockieren — Ingress 202 Accepted, Arbeit async.
02 Entscheidungsmatrix: Netlify Deploy Hook vs. Cloudflare Pages Hook
HTTP-Hook nach Build — aber Telemetrie und Purge unterscheiden sich. Tabelle verhindert vermischte Idempotenz-Keys.
| Kriterium | Netlify (Referenz) | Cloudflare Pages (dieses HowTo) |
|---|---|---|
| Hook-Quelle | Build Hook / Plugin-Webhook, Fokus NETLIFY_*-Metadaten. |
Pages Deploy Hook oder CI-Webhook; Zuordnung über CF_PAGES_* / Deployment-JSON. |
| Cache & Invalidierung | Edge-Verhalten plattformspezifisch; Warm-up oft ausreichend. | Explizites Purge (URL-Liste oder Konto-weit), danach cf-cache-status beobachten. |
| Header-Baseline | _headers / Redirect-Konfiguration analog, weniger globale Edge-API. |
_headers plus gemessene Köpfe; Diff gegen exportierte Regeln und Worker. |
| Batch-Nachweis | curl-Warm-up, Link-Crawl üblich. | curl-Batch mit Parallelitätslimit, Fokus auf Header- und Status-Stichprobe. |
| Idempotenz-Namespace | ${GIT_SHA}:${NETLIFY_DEPLOY_ID}:summary |
${GIT_SHA}:cf-pages:${CF_PAGES_DEPLOYMENT_ID}:summary — niemals mit Netlify-Keys mischen. |
03 Reproduzierbare Skript-Kette (Notebook und Remote Mac identisch)
scripts/cf-pages/openclaw-post-deploy.sh versionieren; Pages Deploy Hook → gesicherter Ingress; gleicher Einstieg lokal und auf dem Remote Mac.
- Kontext:
GIT_SHA,CF_PAGES_DEPLOYMENT_ID,DEPLOY_URL,OPENCLAW_RUN_ID; Secrets nur im Runner. - Purge: Purge Everything oder URL-Liste; kurz warten.
- curl-Batch:
urls.txtmitxargs -P N,curl -fsSI;cf-cache-statusloggen; bei 429 Parallelität senken, Backoff mit Jitter. - Header-Diff: Köpfe filtern →
headers_observed.jsonvs.headers_baseline.json(_headers+ Rules). - Smoke: Playwright webkit+chromium; optional SW-PR-Summary.
- Summary:
build_summary.json(purge_ms,curl_batch_ms,headers_diff_failed, …); POST mit Bearer und CF-Idempotenz-Key aus Matrix.
Purge → curl → Diff → Smoke → Summary — diese Reihenfolge hält Edge und Security-Regressionen fassbar.
So bleibt jeder Lauf auf dem Remote Mac nachstellbar: dieselben Umgebungsvariablen wie in CI, identische curl-Flags und dieselbe Baseline-Datei — Support diffiert Logs statt Stimmungen.
04 OpenClaw-Gateway: Aufgaben orchestrieren und Fehlerdigest liefern
Gateway: Auth, Anti-Doppel-Purge, Fehlerdigest („Purge ok · curl 429 · CSP-Diff · Smoke timeout“) — Chats nur Digest + Artefakt-Link, keine Secrets.
NDJSON-phase: purge|curl_batch|headers_diff|smoke|callback; Felder cf_ray, cf_cache_status, git_sha. Retries nur idempotent.
Kennzahlen: Batch-Latenz, Header-Abweichungen, Smoke-zeit — optional Build-Metriken.
05 FAQ: Hook, Cache-Invalidierung und Header-Diff
| Symptom / Code | Häufige Ursache | Was prüfen |
|---|---|---|
| Hook feuert, Inhalt wirkt alt | Edge-Cache oder SW hält noch auslieferbare Objekte. | Purge-Umfang; cf-cache-status; Abgleich mit Service-Worker-PR-Summary. |
| Header-Diff „komplett rot“ | Preview-Hostname vs. Produktion oder Worker injiziert Köpfe. | Pro Umgebung eigene Baseline; gleichen Host-Header wie Monitoring nutzen. |
| 429 beim curl-Batch | Zu hohe Parallelität nach globalem Purge. | xargs -P senken; einzelne URLs serialisieren; Backoff. |
| 401 / 403 am Callback | Gateway-Token rotiert oder Uhr driftet. | Vault aktualisieren; NTP; minimal nötige Scopes. |
| 502 / 504 nach Hook | Origin oder Worker kalt; TLS-Middlebox. | Warm-up-Frist; curl -v vom Remote Mac; DNS zum richtigen Deployment. |
Soll der Pages-Hook lange Tests synchron ausführen?
Nein. Der Hook soll das Gateway schnell entlassen (202 Accepted), während der Runner asynchron arbeitet. Lange Suites gehören in eine Warteschlange — sonst riskieren Sie Timeouts und doppelte Hook-Lieferungen ohne klare Idempotenz.
Kann ich dasselbe Playwright-Projekt wie beim Netlify-Artikel nutzen?
Ja — Tests und build_summary-Schema können geteilt werden. Trennen Sie nur Umgebungsvariablen und Idempotenz-Präfixe, damit NETLIFY_* und CF_PAGES_* niemals dieselbe Schlüsselspalte belegen.
Cloudflare Pages Hooks auf einen dauerhaften Mac-Runner legen
Nach jedem Deploy: Purge disziplinieren, curl-Batch und Header-Diff dokumentieren, WebKit- und Chromium-Smoke auf Apple-Hardware — OpenClaw bündelt Digest und Artefakte. Preise, Hilfe und Technik-Einblicke sind ohne Login lesbar; über mieten oder kaufen skalieren Sie Runner-Kapazität.