OpenClaw auf dem VPS: 24/7-Betrieb ohne offenen Gateway

Ein OpenClaw-Gateway auf einem VPS kann rund um die Uhr laufen, ohne dass seine Oberfläche offen im Internet stehen muss. Für mich steht bei einem solchen Setup die Netzgrenze vor jeder Komfortfrage: Der Gateway bleibt privat und ist nur über einen SSH-Tunnel oder Tailscale Serve erreichbar.

Der VPS übernimmt Zustand und Workspace. Laptop oder Smartphone greifen über die Control UI zu, lokale Fähigkeiten lassen sich gezielt über Nodes anbinden. So entsteht eine dauerhafte Schaltzentrale – und ein System, dessen Absicherung nicht beim Cloud-Login enden darf.

Der Gateway bleibt privat

Zustand und Workspace gehören beim Cloud-Betrieb auf den VPS. Beide Bereiche müssen Neustarts überstehen und regelmäßig gesichert werden. Verschwindet nach einem Reboot die Konfiguration oder der Arbeitsstand, war der Server zwar verfügbar, der Dienst aber nicht belastbar betrieben.

Der vermeidbare Sicherheitsfehler ist ein öffentlich freigegebener Gateway-Port. Bei einer Bindung an Loopback nimmt der Dienst zunächst nur Verbindungen auf dem Server selbst an. Der Zugriff erfolgt anschließend durch einen kontrollierten Tunnel. Tailscale Serve schafft eine vergleichbare Erreichbarkeit innerhalb eines Tailnets, ohne Gateway- oder Browser-Ports ins öffentliche Netz zu stellen. Öffentliche Freigaben gehören nicht in dieses Setup; der Zugriff bleibt auf das private Tailnet begrenzt.

Deployment-Beispiele für AWS und Hetzner folgen demselben Muster: Die Instanz tritt einem privaten Netz bei, Gateway und Browser bleiben von außen unerreichbar. Genannte Monatskosten sind dabei nur Momentaufnahmen. Region, Instanztyp, Speicher und später geänderte Tarife können die Rechnung deutlich verschieben.

Drei Schutzlinien für den Dauerbetrieb

Beim Netzzugang beginnt die Absicherung. Ein privater Gateway verkleinert die öffentlich sichtbare Angriffsfläche, ersetzt jedoch keine Härtung des Servers. Dazu gehören ein abgesicherter SSH-Zugang, eine restriktive Firewall, Schutz gegen wiederholte Anmeldeversuche, ein Nicht-Root-Nutzer und Monitoring. Eine dedizierte Instanz begrenzt zudem den möglichen Schaden, falls der Agent oder eine genutzte Komponente kompromittiert wird.

Die nächste Schutzlinie sind knappe Berechtigungen. Automatisierung sollte niemals pauschal mit einer Owner-Rolle arbeiten. Ein Dienstkonto erhält nur die Rechte, die der konkrete Ablauf benötigt. Das gilt ebenso für angebundene SaaS-Dienste, Repositories und Speicher: Dauerhaft verfügbare Zugangsdaten dürfen keinen pauschalen Vollzugriff eröffnen.

Abgeschlossen wird das Modell durch einen wiederherstellbaren Zustand. Für das Plattform- oder Betriebsteam ergibt sich daraus ein klarer Test: Lassen sich Zustand und Workspace auf einem frischen Server wiederherstellen? Sind benötigte Binärdateien und Konfigurationen danach vorhanden? Ein Backup, dessen Restore nie geprobt wurde, ist lediglich eine Hoffnung mit Zeitstempel.

Cloud-Gateway und lokale Nodes trennen

Der VPS muss nicht jede Fähigkeit selbst bereitstellen. Der Gateway hält Zustand, Workspace und die dauerhafte Sitzung. Lokale Geräte können gezielt Funktionen liefern, die nur dort verfügbar sind.

Diese Grenze verhindert, dass ein privater Rechner nebenbei zum Dauer-Server wird. Sie bestimmt zugleich, welche Nutzer und Daten sich eine Laufzeit teilen dürfen. Ein gemeinsamer Firmenagent ist nur innerhalb einer einheitlichen Vertrauensgrenze vertretbar. Sobald verschiedene Kunden, private Konten oder organisatorisch getrennte Bereiche beteiligt sind, darf ein gemeinsamer Gateway nicht als ausreichende Isolation gelten.

Ein Ausfalltest vor dem produktiven Betrieb

Vor dem Dauerbetrieb sollte das Betriebsteam drei Situationen praktisch durchspielen. Zum Auftakt wird der VPS neu gestartet. Erwartet wird, dass Gateway, Zustand und Workspace vollständig zurückkehren; fehlen Sitzungen, Dateien oder Konfigurationen, muss die Persistenz korrigiert werden.

Danach wird der private Zugangsweg unterbrochen. Der Gateway darf dadurch nicht öffentlich erreichbar werden. Gleichzeitig muss klar sein, wie ein Administrator den Tunnel oder das private Netz wiederherstellt. Abschließend folgt ein Restore auf einer frischen Instanz. Entscheidend sind ein erfolgreicher Start, vollständige Dateien und der Zugriff auf den erwarteten Arbeitsstand.

Bei jedem Test gehören Dienststatus und Systemprotokolle zur Prüfung. Gesucht werden Neustartschleifen, Berechtigungsfehler, fehlende Dateien und blockierte Netzwerkverbindungen. Auf einem Linux-Server mit systemd liefern systemctl status <dienst> und journalctl -u <dienst> einen reproduzierbaren Einstieg; der tatsächliche Dienstname ergibt sich aus der Installationsart. Eine separate Netzwerkprüfung muss außerdem bestätigen, dass der Gateway nur an Loopback oder der erwarteten privaten Schnittstelle lauscht. Danach bleibt der Prüfpfad derselbe: erwarteten Zustand notieren, Fehler reproduzieren, Logs sichern, Ursache beheben und den Test wiederholen.

Reality Check

• Geeignet für: dauerhafte Agentenläufe, private Zugriffe auf die Control UI und getrennte lokale Nodes
• Kritische Bruchstellen: öffentliche Gateway-Ports, überbreite Cloud-Rechte und nicht wiederherstellbarer Zustand
• Vor dem Einsatz zu testen: Restore auf einen frischen VPS und Verhalten bei einem Ausfall des privaten Zugangswegs
• Sicherheitsrisiko: mittel
• Betriebsaufwand: mittel
• Recovery: möglich, wenn Zustand und Workspace gesichert und der Wiederanlauf praktisch getestet sind

Die Mindestregel für den produktiven VPS

Meine Mindestregel wäre eindeutig: Kein Gateway-Port wird öffentlich erreichbar gemacht. Darauf folgen ein dedizierter Server, ein nicht privilegierter Betriebsnutzer, schmale Dienstkonten, persistent gespeicherter Zustand und ein geprobter Restore. Monitoring gehört ebenfalls dazu, denn ein dauerhaft laufender Agent kann auch außerhalb der betreuten Betriebszeiten Fehler produzieren oder unerwartet Ressourcen verbrauchen.

Ein VPS kauft Verfügbarkeit, keine automatische Sicherheit. Erst das Zusammenspiel aus privatem Zugang, begrenzten Rechten und getesteter Wiederherstellung macht den Cloud-Gateway kontrollierbar. Fehlt eine dieser Schutzlinien, landet das bestehende Risiko lediglich auf einem Rechner, der länger online ist.