Nach den Installationsleitfäden für drei Plattformen und den Docker-Produktionsartikeln kann es sinnvoll sein, das OpenClaw-Gateway auf Bare-Metal-Node plus systemd unter Ubuntu 24.04 zu betreiben und mit Cloudflare Tunnel so zu kapseln, dass das Gateway nicht auf der öffentlichen Schnittstelle lauscht. Dieser Artikel liefert Abgrenzung zu Docker, Zerlegung typischer Schmerzpunkte, zwei Tabellen, systemd- und Tunnel-Snippets, ein sechsstufiges Runbook und drei Bereitschaftsmetriken und verweist auf Post-Install-Triage, Docker-Produktion, Installationsleitfaden und Gateway-Sicherheit (Fortgeschritten) für ein reproduzierbares Go-Live.
Auf Bare Metal liegen Node-Versionen, Berechtigungen, Bind-Adressen und Prozessüberwachung wieder voll beim Host. Wenn Sie die Gewohnheit beibehalten, das Gateway nur im Vordergrund auf einem Laptop zu starten, brechen Dienste nach Neustarts ab, Journals bleiben unstrukturiert, und Abweichungen zwischen ufw und Cloud-Security-Groups machen Vorfälle zur Anekdote. Zerlegen Sie die sechs Klassen, bevor Sie Konfigurationen kopieren.
sudo npm i -g-Upgrades entkoppeln Produktion von der Dokumentation; pinnen Sie ExecStart an eine feste Node-Binärdatei oder einen Shim des Versionsmanagers.0.0.0.0 plus eine vergessene Firewall-Regel legt die Steuerungsebene offen; mit Tunneln ist 127.0.0.1 vorzuziehen—der Tunnel übernimmt eingehend.openclaw läuft, führt zu „manuell ok, als Dienst fehlgeschlagen“.cloudflared zeigt auf den falschen lokalen Port—extern 502 ohne Zusammenhang mit Modell-Timeouts.ExecStart und Konfigurations-Hash verhindert schnelles Zurückdrehen.Zwei Tabellen fassen Docker vs. Bare Metal sowie Tunnel vs. direkten Reverse-Proxy für Architekturreviews zusammen.
Der fortgeschrittene Artikel zur Gateway-Sicherheit behandelt Tokens, Exposition und Secret-Rotation; dieser Artikel behandelt Loopback-Bindung auf Linux-Hosts und Übergabe des Ingress an einen Tunnel. Zusammen ergeben sie „Edge-Ingress, Geheimnisse in der Repo-Ebene, Prozesse unter systemd“. Vervollständigen Sie Onboarding und Modellschlüssel über den Installationsleitfaden, bevor Sie hier produktiv härten.
Der Beitrag Docker-Produktion behandelt Image-Pins, Volumes und Compose-Rollback; dieser Beitrag behandelt Host-Units plus Tunnel. Tabelle 1 dient der Architekturreview—keine Glaubensfrage.
| Dimension | Docker / Compose | Bare Node + systemd (dieser Artikel) |
|---|---|---|
| Reproduzierbarkeit | Images und Digests fixieren die Laufzeit | Host-Stack variiert; Ausgleich durch Konfigurationsmanagement und Versions-Pins |
| Triage-Tiefe | Zuerst Container-Logs und Volume-Rechte | Host-Tools verfügbar, sofern Richtlinien es erlauben |
| Bestehendes Ops-Tooling | Container-Monitoring und Registry-Flow nötig | journald, node_exporter, Backup-Skripte wiederverwenden |
| Upgrade-Pfad | Image-Tags tauschen; Volumes explizit | Node und globale Pakete bewegen sich gemeinsam—Rollback skripten |
| Typische Passform | Teams, die bereits auf Container standardisiert sind | Pflicht zur Ausführung auf Metal oder enge Kopplung an legacy-systemd-Dienste |
Tunnel lagern TLS und öffentlichen Ingress an die Edge aus; Nginx/Caddy terminieren TLS oft lokal und proxen zum Loopback. Sie können kombinieren, doch lauschende Endpunkte müssen minimal bleiben. Nutzen Sie Tabelle 2 gegen Ihre Security-Group-Regeln.
| Muster | Gateway-Bindung | Öffentliche Fläche | Ops-Hinweise |
|---|---|---|---|
| Tunnel zum Loopback | 127.0.0.1:PORT (laut OpenClaw-Doku) | Kein direkter Gateway-Port; nur Ausgang des Tunnel-Prozesses | Ingress an den tatsächlich laufenden lokalen Dienst-Port anbinden |
| Lokales Nginx/Caddy | Upstream meist weiterhin Loopback | 443 am Proxy; Zertifikate und Rate Limits verwalten | ufw und Cloud-SGs dreifach prüfen, um Doppel-Exposition zu vermeiden |
| Nicht empfohlen: Gateway auf 0.0.0.0 | Alle Schnittstellen | Steuerungsebene im Internet | Strikte Tokens, Allowlists und WAF—nicht Standard |
# /etc/systemd/system/openclaw-gateway.service (Gerüst; ExecStart laut offizieller CLI) [Unit] Description=OpenClaw Gateway (bare metal) After=network-online.target Wants=network-online.target [Service] User=openclaw Group=openclaw WorkingDirectory=/var/lib/openclaw Environment=NODE_ENV=production ExecStart=/usr/bin/node /path/to/openclaw/cli.js gateway start --bind 127.0.0.1 Restart=on-failure RestartSec=5 LimitNOFILE=65535 [Install] WantedBy=multi-user.target
# cloudflared-Ausschnitt: Hostname zum lokalen Gateway
tunnel: YOUR_TUNNEL_ID
credentials-file: /etc/cloudflared/YOUR_TUNNEL.json
ingress:
- hostname: claw.example.com
service: http://127.0.0.1:18789
- service: http_status:404
Hinweis: Ports und Binärpfade sind Platzhalter. Gleichen Sie mit der aktuellen OpenClaw-Dokumentation und openclaw --help ab; notieren Sie Hashes und Rollback-Befehle im Change-Ticket.
127.0.0.1 binden, per curl oder Health-Check laut Doku prüfen, dann den Tunnel ergänzen.daemon-reload && enable --now; journalctl -u openclaw-gateway -f auf Reihenfolgefehler prüfen.ExecStart und Konfigurationen archivieren; nur innerhalb Ihrer RTO vorwärts fehlschlagen.Trennen Sie lokale Gesundheit (Prozess + Loopback-Port) von externer Gesundheit (DNS, Zertifikatskette, Edge-Routing). Wer bei Releases nur eine Seite aktualisiert, erzeugt „grün intern, rot extern“-Falschmeldungen. Ticket-Vorlagen sollten OpenClaw-Version, Node-Minor und cloudflared-Version sowie einen Journal-Auszug für Audit-Pfade vorschreiben.
curl -v 127.0.0.1:PORT, dann Tunnel-Logs; lokal fehlgeschlagen = Applikationsschicht, lokal ok / remote fehlgeschlagen = Tunnel oder DNS.Nachtrag: Auf kleinen VPS mit nur Gateway und Tunnel—wenn die Latenz schwankt, die CPU aber leer wirkt—prüfen Sie Dateideskriptoren pro Prozess, langlebige WebSocket-Anzahlen und TLS-RTT zu den Anbietern, bevor Sie vCPU hochstufen.
Ein generischer Linux-VPS eignet sich für Demos, doch IO-Schwankungen und Headless-Grenzen prägen lang laufende Automatisierung. Produktives OpenClaw braucht wiederholbare Überwachung, auditierbare Lauschflächen und Abgleich mit CI- und Secret-Workflows.
Für iOS-Builds, den Simulator oder GUI-Triage ersetzt Linux kein Apple Silicon; viele Teams legen das Gateway auf eine Linux-Edge und verlagern schwere Xcode-Arbeit auf Remote-Macs. Ersatz-Laptops und fragmentierte Desktops kämpfen mit 24/7-Agenten: Ruhezustand und Dialoge verwandeln Automatisierung in Zufallsfehler. MACCOME bietet mehrregionale Mac Mini M4 / M4 Pro auf Bare Metal—sinnvoll als Build- und Langsession-Backend, während Linux den Ingress bündelt. Öffnen Sie das Hilfe-Center (FAQ), und stimmen Sie Mietpreise mit Ihrer Regionsseite ab.
Pilotieren Sie mit kurzen Mieten die End-to-End-Latenz für „Tunnel + Remote-Mac-Workload“, bevor Sie Ingress und Compilerollen auf einem Host zusammenlegen.
FAQ
Reicht Docker nicht aus?
Oft ja—siehe Docker-Produktion. Bare-systemd passt bei enger Integration in bestehenden Host-Betrieb oder wenn Host-Triage nötig ist.
127.0.0.1 oder 0.0.0.0 für das Gateway?
Loopback hinter Tunnel oder lokalem Proxy bevorzugen; nur mit Firewall, Tokens und Monitoring erweitern. Validierung in Post-Install-Triage.
Wo stehen Installationsbefehle und Plattformunterschiede?
Installation und Plattformwahl; Preise unter Mietpreise.
Welche DSGVO-Punkte betreffen Tunnel und Edge?
Dokumentieren Sie Zwecke und Datenkategorien (z. B. Metadaten, Inhalte von Anfragen), prüfen Sie Auftragsverarbeitung und ggf. Drittlandübermittlung beim Anbieter, und halten Sie Verzeichnis von Verarbeitungstätigkeiten sowie Transparenzpflichten aktuell. Technische Minimierung und Zugriffskontrolle auf dem VPS bleiben unabhängig vom Tunnel maßgeblich; bei Unsicherheit holen Sie datenschutzrechtlichen Rat ein.