VPS-Hosting

Dieser Hub verlinkt die unterstützten VPS-/Hosting-Anleitungen und erklärt auf hoher Ebene, wie Cloud-Deployments funktionieren.

Provider wählen

• Railway (One-Click + Browser-Setup): Railway
• Northflank (One-Click + Browser-Setup): Northflank
• Oracle Cloud (Always Free): Oracle — 0 $/Monat (Always Free, ARM; Kapazität/Registrierung kann hakelig sein)
• Fly.io: Fly.io
• Hetzner (Docker): Hetzner
• GCP (Compute Engine): GCP
• exe.dev (VM + HTTPS-Proxy): exe.dev
• AWS (EC2/Lightsail/Free Tier): funktioniert ebenfalls gut. Video-Anleitung: https://x.com/techfrenAJ/status/2014934471095812547

Wie Cloud-Setups funktionieren

• Das Gateway läuft auf dem VPS und verwaltet State + Workspace.
• Du verbindest dich von deinem Laptop/Handy via Control UI oder Tailscale/SSH.
• Behandle den VPS als die zentrale Quelle der Wahrheit und sichere State + Workspace.
• Sicherer Standard: Halte das Gateway auf Loopback und greife via SSH-Tunnel oder Tailscale Serve darauf zu. Wenn du auf lan/tailnet bindest, verlange gateway.auth.token oder gateway.auth.password.

Remote-Zugriff: Gateway remote Plattform-Hub: Plattformen

Gemeinsamer Firmen-Agent auf einem VPS

Dies ist ein valides Setup, wenn sich die Benutzer innerhalb einer Vertrauensgrenze befinden (z. B. ein Firmenteam) und der Agent ausschließlich geschäftlich genutzt wird.

• Betreibe ihn auf einer dedizierten Runtime (VPS/VM/Container + dedizierter OS-Benutzer/Konten).
• Melde diese Runtime nicht bei persönlichen Apple-/Google-Konten oder persönlichen Browser-/Passwortmanager-Profilen an.
• Wenn Benutzer untereinander nicht vertrauenswürdig sind, trenne nach Gateway/Host/OS-Benutzer.

Details zum Sicherheitsmodell: Sicherheit

Nodes mit einem VPS verwenden

Du kannst das Gateway in der Cloud belassen und Nodes auf deinen lokalen Geräten (Mac/iOS/Android/Headless) koppeln. Nodes bieten lokalen Bildschirm-/Kamera-/Canvas- und system.run-Zugriff, während das Gateway in der Cloud bleibt.

Doku: Nodes, Nodes-CLI

Startzeit-Optimierung für kleine VMs und ARM-Hosts

Wenn sich CLI-Befehle auf leistungsschwachen VMs (oder ARM-Hosts) langsam anfühlen, aktiviere 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 Startzeit bei wiederholten Befehlen.
• OPENCLAW_NO_RESPAWN=1 vermeidet zusätzlichen Startup-Overhead durch einen Self-Respawn-Pfad.
• Der erste Befehlslauf wärmt den Cache auf; nachfolgende Läufe sind schneller.
• Für Raspberry-Pi-Spezifisches siehe Raspberry Pi.

systemd-Tuning-Checkliste (optional)

Für VM-Hosts mit systemd:

• Service-Umgebungsvariablen für stabilen Startpfad hinzufügen:
  • OPENCLAW_NO_RESPAWN=1
  • NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
• Neustart-Verhalten explizit festlegen:
  • Restart=always
  • RestartSec=2
  • TimeoutStartSec=90
• SSD-basierte Datenträger für State-/Cache-Pfade bevorzugen, um Random-I/O-Kaltstart-Penalties zu reduzieren.

Beispiel:

sudo systemctl edit openclaw

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90

Wie Restart=-Policies bei der automatischen Recovery helfen: systemd kann Service-Recovery automatisieren.