OpenClaw 2026: Fly.io vs. klassischer Linux-Cloud-VPS — Persistenz, öffentlicher Ingress, Channel-Webhooks und Health Checks (Matrix + FAQ)

OpenClaw braucht einen stabilen Prozess, dauerhaften Zustand für Sessions und Tokens sowie eine HTTPS-URL, die Chat-Anbieter für Webhooks erreichen. 2026 sind zwei typische Fußabdrücke üblich: eine Fly.io-Machine mit Volume und verwaltetem TLS oder ein generischer Linux-VPS mit systemd, Reverse-Proxy und gemountetem Datenverzeichnis. Dieser Artikel vergleicht die Dimensionen, die Produktion wirklich brechen: wo der Zustand liegt, wie sich die öffentliche URL bei Deploys verhält, wie Retries von Slack oder Telegram mit Ihrem Gateway interagieren und wie Health Checks verdrahtet sein sollten, damit Neustarts keine gepaarten Kanäle verwerfen.

Entscheidungsmatrix auf einen Blick

Fly eignet sich, wenn die Plattform Rolling-Deploys, Anycast-Routing und Zertifikatserneuerung mit wenig Ansible übernehmen soll. Ein VPS passt, wenn Sie feste Egress-IPs, beliebige Kernel-Module, Neben-Agents auf demselben Host oder eine Compliance-Grenze brauchen, die Sie Ende-zu-Ende kontrollieren. Für Muster mit minimaler öffentlicher Fläche (Gateway nur Loopback plus SSH oder getrenntes HTTPS) siehe 2026 OpenClaw Linux-Cloud-VPS: Minimale Angriffsfläche — Firewall-Vorlage, Gateway-Loopback-Bindung und SSH-Tunnel für die Verwaltungsebene, Entscheidungsmatrix gegenüber HTTPS-Reverse-Proxy im öffentlichen Netz und gestufte FAQ.

Persistenz: Volumes vs. Bind-Mounts

Auf Fly: Volume in derselben Region wie die Machine deklarieren und an den Pfad mounten, den Ihr Container-Entrypoint für Credentials, Kanal-Metadaten und lokale Caches nutzt. Horizontale Skalierung ohne gemeinsamen Storage spaltet den Zustand; für OpenClaw wollen Sie fast immer genau eine Writer-Instanz, bis das Projekt explizite Multi-Node-Semantik dokumentiert. Auf dem VPS: ein Bind-Mount-Verzeichnis, Eigentümer ein Nicht-root-Service-User, Dateisystem-Backups, die für SQLite-ähnliche Stores crash-konsistent genug sind.

Wenn Sie noch zwischen Installationsarten wählen, hilft 2026 OpenClaw Linux-Cloud-VPS in der Praxis: curl-Installation vs. Docker, Umgebungschecks und FAQ zu typischen Fehlern mit Checks, die gelten, bevor Sie Port 443 überhaupt freigeben.

Ingress, Webhooks und Replay-Druck

Kanal-Anbieter liefern Events mit Retries und knappen Latenzbudgets. Das Gateway muss schnell antworten, Signaturen möglichst am Rand prüfen und schwere Arbeit in eine Queue legen statt inline. Unter Fly: interne HTTP-Timeouts kürzer halten als das Client-Timeout des Anbieters, damit keine doppelten Zustellungen wie Replay-Bugs wirken. Unter Nginx oder Caddy: Upstream-Status und TLS-Handshake-Fehler getrennt loggen, damit ein Zertifikatsproblem nicht als Applikations-500 gelesen wird.

Health Checks, die Rollouts überleben

Ein günstiges GET-Endpoint, das Konfigurations-Parsing und Schreibbarkeit auf dem Volume prüft — keine Live-Calls zu Drittanbietern bei jedem Probe. Ergänzend eine synthetische „kann Arbeit einreihen“-Prüfung in der Observability. Auf Fly: Intervall so wählen, dass kurzzeitiger CPU-Steal keine gesunden Machines ersetzt. Bei systemd: Type=notify nur, wenn der Binary sd_notify unterstützt; sonst Exit-Codes und Backoff-Limits statt Restart-Stürmen.

Log-Versand verdient dieselbe Disziplin wie der Check: wenn Sie nur stdout scrapen, aber Datei-Logs unter dem State-Verzeichnis schreiben, rotieren oder forwarden — sonst füllt sich die Platte, während ein flacher Health-Check noch grün bleibt. Bei Dual-Stack prüfen, ob der Health-Client IPv4 oder IPv6 nutzt, damit nicht Loopback grün ist, während das öffentliche AAAA auf einen toten Listener zeigt.

1. curl -v https://ihr-host/healthz   # TLS + Routing
2. ls -la $OPENCLAW_STATE_DIR        # Volume gemountet?
3. journalctl -u openclaw -b         # oder fly logs --app …
4. Webhook-Secret vs. Anbieter-UI     # stille 401/403-Schleifen

FAQ: reproduzierbare Ausfälle

F: Slack melkt die Events-URL nach jedem Deploy. A: Listener vor Traffic-Umschaltung starten; Request-Pfad zwischen Preview und Produktion identisch halten; Signing-Secret in der UI mit der Laufzeitumgebung abgleichen.

F: Sessions waren über Nacht weg. A: Fast immer ungemountetes Volume oder Container, der in den Image-Layer schrieb. Mount im laufenden Task prüfen, nicht nur im Dockerfile.

F: Health grün, Nutzer sehen Timeouts. A: Der Check trifft vermutlich localhost, Webhooks aber ein gesättigtes TLS-Front. Zweite synthetische Prüfung von außerhalb oder externes Monitoring.

F: Fly zeigt mehrere Machines nach Scale-Bump. A: Ohne Leader-Election nicht horizontal skalieren, bis gemeinsamer Storage oder Single-Writer-Queue existiert; sonst konkurrieren doppelte Webhooks mit denselben Automationen.