Einen OpenClaw-ähnlichen Workflow selbst zu hosten klingt einfach: VPS mieten, Agent installieren, Repo öffnen. Schwierig wird alles um diese Schleife herum — Secrets, Branches, Logs, Kostenlimits und der Rettungsweg, wenn eine lange Aufgabe mitten in einer Migration hängen bleibt.
Das ist das Betriebsmodell, das wir OpenClaw-Nutzern empfehlen, die mehr Kontrolle wollen, ohne so zu tun, als wäre Office Claws eine native OpenClaw-Laufzeit. Office Claws verwaltet lokalen Desktop-Zustand und VPS-Runner für Codex-gestützte Agenten. Wenn deine OpenClaw-Arbeit vor allem Repository-Arbeit ist, bekommst du damit die nützliche Self-Hosted-Form: Schlüssel bleiben lokal, jede Aufgabe bekommt einen isolierten Runner, und jede Änderung landet weiterhin als prüfbarer Branch.
Was „OpenClaw Self Hosted“ bedeuten sollte
Die sicherste Definition ist nicht „den gehosteten Dienst auf einen Server kopieren“. Es ist eine geteilte Control Plane.
| Ebene | Ort | Warum es wichtig ist |
|---|---|---|
| Desktop-Steuerung | Lokale Maschine | API-Token, SSH-Schlüssel, Freigaben und Operator-Absicht bleiben nah am Entwickler |
| Agent-Ausführung | VPS-Runner | Lange Jobs überleben Laptop-Ruhezustand und instabiles WLAN |
| Repository-Änderungen | Branch pro Aufgabe | Review, CI und Rollback bleiben normal |
| Netzwerkzugang | Privates Mesh | SSH ist nicht direkt im öffentlichen Internet sichtbar |
| Abrechnung | Subscription + kleiner VPS | Kosten bleiben planbar, statt dass jeder Leerlauf-Retry zur API-Überraschung wird |
Dieses Modell ist nicht dasselbe wie OpenClaw selbst zu betreiben. Wir behaupten nicht, dass Office Claws OpenClaw-Erweiterungen, Memory oder Browser-Automationen importiert. Wir beschreiben einen Self-Hosted-Workflow für OpenClaw-Nutzer, die vor allem autonome Coding-Arbeit auf dauerhaften Maschinen brauchen. Der Vergleich OpenClaw vs Codex ist der bessere Ort, um zu entscheiden, ob dieser Tausch passt.
Die Referenzarchitektur
Ein verlässliches Self-Hosted-Setup hat vier Teile:
- Office Claws auf dem Desktop für Provisionierung, Freigaben, Status und lokale Schlüsselverwaltung.
- Ein VPS pro aktivem Runner bei Contabo, DigitalOcean, Hetzner oder einem Anbieter, dem du bereits vertraust.
- Tailscale oder ein ähnliches privates Mesh, damit Runner SSH nicht ins Internet öffnen.
- Codex CLI im Runner für den repo-förmigen Ausführungspfad, den viele OpenClaw-Nutzer nach Abo- oder Kostenänderungen brauchen.
Die wichtige Gewohnheit lautet: eine Aufgabe, ein Runner, ein Branch. Lass nicht drei Agenten denselben Checkout teilen, nur weil es effizient wirkt. So wird aus einem günstigen Self-Hosted-Experiment ein Rätsel aus Diffs und überschriebenen Testergebnissen. Der OpenClaw Desktop Manager Guide erklärt, warum die UI Runner-Zustand so sichtbar macht: Wenn du nicht erkennst, welcher Agent welches Repo besitzt, hast du noch keine Betriebsschicht.
Setup-Checkliste
Fang klein an. Ein Runner reicht, um die Schleife zu beweisen.
# target shape, not a magic installer
1. create a VPS from a known snapshot
2. join it to your private mesh
3. authenticate Codex CLI on the runner
4. clone one repo into one task workspace
5. create a branch before the agent edits files
6. run tests and push the branch
7. destroy or reset the runner when the task is doneFür Office Claws-Nutzer übernimmt die App Provisionierung und Status; Repo-Rechte, GitHub-Review-Regeln und Modellkonto bleiben bei dir. Der Self-Hosted-Plan kostet $4.99/Monat für die Desktop/VPS-Verwaltung, ein Managed Runner $14.99/Monat, wenn du weniger Serververantwortung willst. Trenne diese Zahlen von Modellabo und VPS-Rechnung.
Bevor du dem Runner echte Arbeit gibst, prüfe die langweiligen Kontrollen:
- Begrenzter GitHub-Token: nur Repo-Zugriff, kein organisationsweiter Admin-Token.
- Kein gemeinsames
.env-Chaos: gib nur die Secrets weiter, die die Aufgabe braucht. - Kostenlimit: setze eins beim VPS-Anbieter und, wenn möglich, eins im Modellkonto-Workflow.
- CI-Gate: kein direkter Deploy aus einem Agent-Branch.
- Reset-Pfad: Snapshot oder Neuaufbau sollte schneller sein als Debugging eines vergifteten Runners.
Das sind dieselben Kontrollen, die wir im Beitrag zu OpenClaw Security Best Practices empfehlen. Self-Hosting entfernt eine Vendor-Oberfläche, fügt aber Verantwortung hinzu; es macht Agentenarbeit nicht magisch sicher.
Fehlerbilder, für die du planen solltest
Die meisten Self-Hosted-Agentenprobleme sind vorhersehbar. Plane sie vor dem ersten Nachtlauf ein.
| Fehlerbild | Symptom | Schutzmaßnahme |
|---|---|---|
| Kollisionen im gemeinsamen Workspace | Zwei Agenten ändern dieselben Dateien | Ein Runner und Branch pro Aufgabe |
| Öffentliches SSH | Zufällige Loginversuche in Logs | Nur privates Mesh; öffentliches SSH schließen |
| Zu breite Secrets | Agent kann fremde Credentials lesen | Env pro Aufgabe und begrenzte Tokens |
| Stilles Hängen | Job stoppt nach Prompt oder Testfehler | Statuschecks, Logs und klare Recovery für hängende Agenten |
| Kostendrift | Extra-Runner laufen das ganze Wochenende | Kostenlimits und Runner-Cleanup |
Die Statusschicht ist wichtiger, als viele erwarten. Ein Terminal-Multiplexer kann eine Sitzung am Leben halten, beantwortet aber nicht die Operator-Fragen: Wem gehört diese Aufgabe, welchen Branch hat sie gepusht, sind Tests grün, und darf die Maschine gelöscht werden? Darum verweisen unsere OpenClaw-Beiträge immer wieder auf Office Claws für OpenClaw-Nutzer, statt so zu tun, als reiche ein nackter VPS.
Empfehlung
Wenn deine OpenClaw-Arbeit überwiegend Code ist, hoste zuerst die Betriebsschicht selbst, nicht alles. Halte Freigaben und Credentials lokal. Lass Agenten auf privaten VPS-Runnern laufen. Nutze Codex-gestützte Ausführung, wo sie passt. Schicke jedes Ergebnis wie den Branch eines Teamkollegen durch GitHub und CI.
Wenn deine OpenClaw-Arbeit native Erweiterungen, browserlastige Automationen oder plattformspezifische Flows braucht, zwänge sie nicht in dieses Muster. Behalte OpenClaw für diese Jobs und nutze Office Claws für repo-förmige Arbeit, die von günstigeren dauerhaften Runnern profitiert.
Das beste Self-Hosted-Setup ist absichtlich langweilig: eine Aufgabe, ein Runner, ein Branch, ein Review-Gate. Genau darum geht es. Autonomes Coding wird viel vertrauenswürdiger, wenn die Infrastruktur sich weigert, clever zu sein.