Zum Hauptinhalt springen
Führen Sie den OpenClaw Gateway auf einem beliebigen Linux-Server oder Cloud-VPS aus. Diese Seite hilft Ihnen, einen Provider auszuwählen, erklärt, wie Cloud-Bereitstellungen funktionieren, und behandelt generisches Linux- Tuning, das überall gilt.

​
Provider auswählen

Railway

Ein-Klick-Einrichtung im Browser

Northflank

Ein-Klick-Einrichtung im Browser

DigitalOcean

Einfacher kostenpflichtiger VPS

Oracle Cloud

Always Free ARM-Tarif

Fly.io

Fly Machines

Hetzner

Docker auf Hetzner VPS

Hostinger

VPS mit Ein-Klick-Einrichtung

GCP

Compute Engine

Azure

Linux-VM

exe.dev

VM mit HTTPS-Proxy

Raspberry Pi

ARM selbst gehostet
AWS (EC2 / Lightsail / kostenloser Tarif) funktioniert ebenfalls gut. Eine Videoanleitung aus der Community ist verfügbar unter x.com/techfrenAJ/status/2014934471095812547 (Community-Ressource — möglicherweise später nicht mehr verfügbar).

​
So funktionieren Cloud-Einrichtungen

  • Der Gateway läuft auf dem VPS und verwaltet Zustand + Workspace.
  • Sie verbinden sich von Ihrem Laptop oder Telefon über die Control UI oder Tailscale/SSH.
  • Behandeln Sie den VPS als maßgebliche Quelle und sichern Sie Zustand + Workspace regelmäßig.
  • Sichere Standardeinstellung: Belassen Sie den Gateway auf loopback und greifen Sie über einen SSH-Tunnel oder Tailscale Serve darauf zu. Wenn Sie an lan oder tailnet binden, verlangen Sie gateway.auth.token oder gateway.auth.password.
Verwandte Seiten: Remote-Zugriff auf den Gateway, Plattform-Hub.

​
Admin-Zugriff zuerst härten

Bevor Sie OpenClaw auf einem öffentlichen VPS installieren, entscheiden Sie, wie Sie die Box selbst administrieren möchten.
  • Wenn Sie Admin-Zugriff nur über Tailnet möchten, installieren Sie zuerst Tailscale, fügen Sie den VPS Ihrem Tailnet hinzu, prüfen Sie eine zweite SSH-Sitzung über die Tailscale-IP oder den MagicDNS-Namen und beschränken Sie anschließend öffentliches SSH.
  • Wenn Sie Tailscale nicht verwenden, wenden Sie eine gleichwertige Härtung für Ihren SSH- Pfad an, bevor Sie weitere Dienste verfügbar machen.
  • Dies ist vom Gateway-Zugriff getrennt. Sie können OpenClaw weiterhin an loopback binden und einen SSH-Tunnel oder Tailscale Serve für das Dashboard verwenden.
Tailscale-spezifische Gateway-Optionen finden Sie unter Tailscale.

​
Gemeinsamer Unternehmens-Agent auf einem VPS

Einen einzelnen Agent für ein Team auszuführen ist eine gültige Einrichtung, wenn alle Benutzer in derselben Vertrauensgrenze sind und der Agent ausschließlich geschäftlich genutzt wird.
  • Belassen Sie ihn auf einer dedizierten Runtime (VPS/VM/Container + dedizierter OS-Benutzer/Konten).
  • Melden Sie diese Runtime nicht bei persönlichen Apple-/Google-Konten oder persönlichen Browser-/Passwortmanager-Profilen an.
  • Wenn Benutzer einander gegenüber adversarial sind, trennen Sie nach Gateway/Host/OS-Benutzer.
Details zum Sicherheitsmodell: Sicherheit.

​
Knoten mit einem VPS verwenden

Sie können den Gateway in der Cloud belassen und Knoten auf Ihren lokalen Geräten (Mac/iOS/Android/headless) koppeln. Knoten stellen lokale Bildschirm-/Kamera-/Canvas- und system.run- Fähigkeiten bereit, während der Gateway in der Cloud bleibt. Dokumentation: Knoten, Knoten-CLI.

​
Start-Tuning für kleine VMs und ARM-Hosts

Wenn CLI-Befehle auf leistungsschwachen VMs (oder ARM-Hosts) langsam wirken, aktivieren Sie den Modul-Compile-Cache von Node: 
grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc
  • NODE_COMPILE_CACHE verbessert die Startzeiten wiederholter Befehle.
  • OPENCLAW_NO_RESPAWN=1 hält routinemäßige Gateway-Neustarts im Prozess, wodurch zusätzliche Prozessübergaben vermieden werden und die PID-Nachverfolgung auf kleinen Hosts einfach bleibt.
  • Der erste Befehlslauf wärmt den Cache auf; nachfolgende Läufe sind schneller.
  • Raspberry Pi-spezifische Details finden Sie unter Raspberry Pi.

​
systemd-Tuning-Checkliste (optional)

Für VM-Hosts mit systemd sollten Sie Folgendes erwägen:
  • Dienstumgebung für einen stabilen Startpfad hinzufügen:
    • OPENCLAW_NO_RESPAWN=1
    • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
  • Neustartverhalten explizit halten:
    • Restart=always
    • RestartSec=2
    • TimeoutStartSec=90
  • Bevorzugen Sie SSD-gestützte Datenträger für Zustands-/Cache-Pfade, um Cold-Start-Einbußen durch zufällige I/O zu verringern.
Für den Standardpfad openclaw onboard --install-daemon bearbeiten Sie die Benutzereinheit: 
systemctl --user edit openclaw-gateway.service

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90
Wenn Sie stattdessen bewusst eine Systemeinheit installiert haben, bearbeiten Sie openclaw-gateway.service über sudo systemctl edit openclaw-gateway.service. So helfen Restart=-Richtlinien bei der automatisierten Wiederherstellung: systemd kann die Dienstwiederherstellung automatisieren. Informationen zum Linux-OOM-Verhalten, zur Auswahl von Kindprozessen als Opfer und zu exit 137- Diagnosen finden Sie unter Linux-Speicherdruck und OOM-Kills.

​
Verwandt