2026 OpenClaw Linux VPS
Produktion ohne Docker Ubuntu 24.04 · systemd · Cloudflare Tunnel—kein Gateway auf oeffentlichem Port

OpenClaw laeuft, aber das Gateway soll nicht direkt am oeffentlichen Interface lauschen? Auf Ubuntu-24.04-VPS stolpert man dann oft ueber Adresswahl, vorhersehbare systemd-Neustarts und wie Cloudflare Tunnel (oder Aequivalent) nur den Loopback-Port hinter einer kontrollierten Domain sichtbar macht. Dieser Artikel ergaenzt Docker-Produktions- und Multi-Plattform-Installationsleitfaeden um Bare Metal + Systemdienst + Tunnel: Umgebungsbaseline, Gateway-Parameter, Beispiel-Unit, Ingress und symptomorientierte Diagnose, plus eine gaengige Topologie mit stabilem Remote-Mac als Ausfuehrungsschicht.

01

Abgrenzung zu Docker-Produktion und Multi-Plattform-Installation

Die Multi-Plattform-Anleitung liefert den schnellen Einstieg; die Docker-Produktionsvariante passt zu Teams mit Container-Standards und Compose/Orchestrierung. Dieser Text richtet sich an Betrieb auf Bare-Metal-Ubuntu 24.04 mit minimalem Abstraktionsgrad, systemd fuer Absturzrecovery und Boot, sowie Cloudflare Tunnel (oder selbst betriebenem Reverse Proxy), damit TLS und Zugriffskontrolle nicht in der Anwendung haengen. Die drei Wege schliessen sich nicht aus: zuerst Bare Metal stabilisieren, spaeter containerisieren.

Die folgenden sechs Punkte sind typische Denkfehler aus Tickets. Erst wenn diese klar sind, lohnt die Checkliste weiter unten.

  1. 01

    „curl ok“ gleich „produktionssicher“: Bind an 0.0.0.0 ohne Front-Proxy legt Auth und TLS in Default-Einstellungen der App; ein Konfigurationsfehler reicht fuer breites Scanning.

  2. 02

    Node-Runtime und glibc ignorieren: Alte Prebuilds oder falsche NODE_OPTIONS auf 24.04 erzeugen Schein: lokal ja, unter systemd nein.

  3. 03

    Arbeitsverzeichnisse und Rechte ad hoc unter /root: Nach Upgrade oder Logrotate fehlen Leserechte—systemd restartet im Kreis, Logs gehen unter.

  4. 04

    Health nur als Prozess-Check: Ohne HTTP-Readiness und Modell-Erreichbarkeit liefert der Load Balancer weiter, der Tunnel antwortet 502—Fehlersuche an der falschen Schicht.

  5. 05

    Tunnel steht, Ingress falscher Port: cloudflared-Ingress und tatsaechlicher Gateway-Listenpunkt divergieren—DNS stimmt, Loopback nicht.

  6. 06

    Linux-Gateway als Universal-Executor: Xcode, Simulator oder Apple-Silicon-Spezifisches auf dem VPS erzwingen wirkt wie „OpenClaw instabil“—in Wahrheit falsche Schicht.

Wenn „Loopback + Tunnel“ zu Ihrem Modell passt, folgen Sie der Baseline und den Befehlen in den naechsten Abschnitten.

02

Varianten im Vergleich: oeffentliches Binding, Docker, systemd + Tunnel

Nicht nur Installationsdauer zaehlen: Angriffsflaeche, Observability und Rollback gehoeren in eine Zeile. Die Tabelle dient Reviews; Ports und Image-Tags durch Ihre Werte ersetzen.

DimensionGateway oeffentlichDocker / Composesystemd + Loopback + Tunnel
ExpositionMaximal; TLS und Firewall in der App-SchichtAbhaengig von Publish-Ports/Netzmodus; Host-Netz fehleranfaelligProzess nur 127.0.0.1; oeffentlicher Einstieg am Tunnel/Edge
ZertifikateEigenes ACME oder manuelle Rotationhaeufig Traefik / Caddy / Cloud-LBTLS-Terminierung bei Cloudflare (oder Aequivalent)
Neustart / DebugExterne Supervisoren oder manuellRestart-Policy und Logging explizit planensystemd-Restart und journal klar strukturiert
Passend fuerMinimaler PoC, nicht ProduktionTeams mit Container-GovernanceEinzel-VPS, reproduzierbare Skripte, KMU

Entscheidend ist nicht Erreichbarkeit, sondern autorisierte Pfade—Loopback verlagert diese Frage an die Edge, wo Policy und Zertifikate stabil verwaltet werden.

03

Umgebung: Node, Verzeichnisrechte, Firewall-Baseline

Unter Ubuntu 24.04 LTS orientieren Sie sich an der aktuellen Node.js-LTS-Hauptversion (Anfang 2026 typisch 22.x; verbindlich nodejs.org). nvm, fnm oder NodeSource sind moeglich; in Produktion Minor-Version pinnen und Upgrade-Fenster dokumentieren. Distro-Pakete sind meist zu alt als alleinige Quelle.

Firewall: SSH nur mit Schluessel, ufw default deny incoming, keine oeffentlichen Regeln fuer den Gateway-Dienst—extern nur ueber den Tunnel. Direktzugriff fuer Debug nur zeitlich begrenzt oder ueber Jump-Host; Widerruf im Change-Log festhalten. Endet TLS bei Cloudflare oder einem US-Anbieter, pruefen Sie Auftragsverarbeitung, Datenfluesse und Speicherorte im Sinne der DSGVO und dokumentieren Sie die Verarbeitungsverzeichnisse.

  1. 01

    Eigener Benutzer und Pfade: z. B. Nutzer openclaw, Laufzeit unter /var/lib/openclaw, Konfiguration /etc/openclaw (640/750), nicht unter root mischen.

  2. 02

    Fixierte Node-Version und Lockfile: package-lock.json oder pnpm-lock.yaml versionieren; in Produktion npm ci oder Aequivalent—keine Major-Upgrades nebenbei.

  3. 03

    glibc und native Module: Saubere Installation und Smoke-Tests auf Zielhardware, um dlopen-Fehler auszuschliessen.

  4. 04

    Zeitzone: timedatectl auf UTC oder Team-Standard—Korrelation mit Tunnel- und Edge-Logs.

  5. 05

    ufw-Baseline: ufw allow OpenSSH, dann ufw enable; Dienstports zu; mit ss -tlnp verifizieren, dass von aussen nichts Gateway-offen ist.

  6. 06

    Health-Endpoint: Vor Tunnel-Go-Live curl -fsS http://127.0.0.1:PORT/health im Runbook; Abgleich mit ExecStartPost oder externem Probe.

info

Hinweis: OpenClaw-CLI und Dateinamen folgen der Upstream-Dokumentation; Pfade und Ports in Unit und YAML sind Platzhalter—vor Aktivierung anpassen.

04

Gateway, systemd und Cloudflare-Tunnel-Routing

Listen: Produktion: 127.0.0.1:PORT; optional Unix-Socket falls unterstuetzt. Secrets: ueber Environment-File, nicht world-readable. Rotation: neues Token schreiben, Rolling-Restart, altes entfernen. Health: mindestens Prozess plus HTTP-Readiness oder Erreichbarkeit des Modell-Control-Planes—sonst meldet der Tunnel nur „down“, nicht „falsche Schicht“.

Beispiel systemd-Unit (Pfade ersetzen)

/etc/systemd/system/openclaw-gateway.service
[Unit]
Description=OpenClaw Gateway (loopback)
After=network-online.target
Wants=network-online.target

[Service]
User=openclaw
Group=openclaw
WorkingDirectory=/var/lib/openclaw
EnvironmentFile=-/etc/openclaw/gateway.env
# ExecStart durch den echten Startbefehl aus der Doku ersetzen
ExecStart=/usr/bin/node /opt/openclaw/gateway.mjs --config /etc/openclaw/gateway.yaml
Restart=on-failure
RestartSec=5
LimitNOFILE=1048576

# Logging: bevorzugt journal; bei Dateien logrotate und Rechte
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Ablauf: systemctl daemon-reloadsystemctl enable --now openclaw-gatewaysystemctl status bis stabil → lokaler curl-Health → dann cloudflared.

cloudflared: nur Loopback-Upstream (Beispiel)

config.yml Ausschnitt
tunnel: <YOUR_TUNNEL_ID>
credentials-file: /etc/cloudflared/<YOUR_TUNNEL_ID>.json

ingress:
  - hostname: claw.example.com
    service: http://127.0.0.1:8787
  - service: http_status:404
warning

Achtung: Tunnel-Credentials nur fuer root oder dedizierten User lesbar; nicht in Image-Layern oder oeffentliche CI-Logs. Bei Nginx/Caddy statt Cloudflare dieselbe Struktur: TLS am Edge, Upstream nur Loopback.

Log-Reihenfolge bei Stoerungen:journalctl -u openclaw-gateway -b --no-pager (Crash-Loop, Env); ② App-Logverzeichnis; ③ journalctl -u cloudflared; ④ curl -v lokal und extern—Prozess vs. Routing.

05

Symptomhandbuch und Topologie mit Remote-Mac

Ports: Bei EADDRINUSE mit ss -tlnp den Besitzer pruefen; nach Portwechsel Ingress und interne Probes anpassen. Rechte: Bei EACCES Owner/Group von Config und Keys pruefen; systemd-User muss lesen koennen. Tunnel: 502 extern, curl lokal ok—Ingress, Cloudflare-Verbindung, DNS-Zone. Modelle: Timeouts/401—Baseline-API vom Server aus curlen (Secrets nicht in der Shell-History), um gesperrte Egress-IPs und abgelaufene Tokens auszuschliessen.

Gaengiges Schnittbild: Linux-VPS fuer oeffentliches Gateway, Queue, leichte Orchestrierung; stabiler Remote-Mac (Apple Silicon physisch) fuer Xcode, Simulator, macOS-only-Tooling. Schwere Jobs wandern auf den Mac—Sicherheitsziel „kein oeffentliches Gateway-Binding“ bleibt, Linux bleibt schlank. Mac als bestellbarer Executor, Linux als selbst betriebene Control-Plane; Verbindung per SSH, Queue oder privatem Tunnel. Fehlerdomaenen trennen: Gateway-Ausfall loescht keine Mac-Build-Caches; Mac-Wartung soll nicht den gesamten API-Eingang lahmlegen.

  • Listen: In Produktion 127.0.0.1 und ein Port—kein versehentliches Dual-Stack-Bind auf alle Interfaces.
  • systemd: Restart=on-failure und RestartSec=5 fuer lesbare Logs; bei Bedarf StartLimitIntervalSec.
  • Tunnel-Upstream: http://127.0.0.1:PORT statt localhost, um IPv6-::1-Fallen zu vermeiden.

Ein einzelner Linux-VPS plus Tunnel eignet sich fuer Control-Plane und API-Aggregation; iOS-CI/CD, Simulator, Metal und die Xcode-Kette stossen dort schnell an Grenzen—entweder Kompromisse im Headless-Betrieb oder laufender Image-Aufwand. Schwere, stabilisierungskritische Arbeit auf einem dedizierten Remote-Mac mit planbaren Wartungsfenstern zu halten, waehrend Gateway weiter systemd und Tunnel nutzt, reduziert Blast-Radius. Fuer dauerhafte Agent- und Build-Pipelines ist die Mac-Mini-Cloudmiete von NodeMini in der Regel die bessere Wahl—Control-Plane bleibt auf Ihrem VPS, Ausfuehrung auf Apple-ausgerichteter Hardware und Mietmodell.

FAQ

Häufig gestellte Fragen

In Produktion dringend Loopback empfohlen; TLS und Policy ueber Tunnel oder Reverse Proxy. Oeffentliche Ports erfordern Allowlists, Limits und Audit—oft aufwaendiger. Weitere Artikel in der OpenClaw-Kolumne.

Auf dem Server Loopback per curl pruefen; dann Tunnel-Ingress und Credentials; erst danach Modelle oder DNS. Vor Executor-Bestellung Mietpreise fuer Laufzeit und Region lesen.

SSH, VNC und Standardstoerungen im Hilfezentrum; Blog-Uebersicht auf der Blog-Startseite.