Warum OpenClaw Remote-Runner-Architektur wichtig ist
OpenClaw-ähnliche Arbeit wird wertvoller, wenn Agenten weiterlaufen können, nachdem der Laptop zugeklappt wurde. Die Architektur entscheidet aber darüber, ob das sicher bleibt. Ein Remote Runner ist nicht einfach ein offenes SSH-Terminal, sondern ein ersetzbarer Arbeitsbereich mit Branch, begrenzten Zugangsdaten, Logs, Health Checks und Review-Gate.
Office Claws ist kein nativer OpenClaw-Runtime. Der ehrliche Einsatz ist Office Claws als Desktop-Kontrollschicht für OpenClaw-nahe Abläufe: VPS-Runner bereitstellen und überwachen, langlebige Schlüssel lokal halten und Codex-gestützte Ausführung nutzen, wo das praktisch ist. Vergleiche zuerst OpenClaw vs Codex und den OpenClaw Desktop Manager.
Die Form eines OpenClaw Remote Runners
Eine sichere Architektur besteht aus lokaler Kontrollschicht, Runner-Host, isoliertem Checkout, Credential-Grenze und Review-Gate.
| Ebene | Aufgabe | Risiko ohne sie |
|---|---|---|
| Lokale Kontrollschicht | startet Aufgaben, hält Schlüssel, zeigt Status | Geheimnisse landen in jeder VPS-Shell |
| Runner-Host | CPU, Netzwerk und Laufzeit | Ruhezustand des Laptops beendet Arbeit |
| Isolierter Checkout | eine Aufgabe, ein Branch | Agenten überschreiben einander |
| Credential-Grenze | kurzlebiger Repo-Token | Prompt Injection bekommt zu viel Zugriff |
| Review-Gate | PR, CI, Freigabe | Code landet zu früh in Produktion |
Das Ziel ist kontrollierte Autonomie: Agenten arbeiten selbstständig, dürfen aber keine Vertrauensgrenzen heimlich überschreiten.
Referenzarchitektur
Office Claws Desktop
├─ Provider-Schlüssel bleiben lokal
├─ Aufgabenwarteschlange und Freigaben
└─ Log- und Health-Dashboard
│
▼
VPS-Runner-Pool
├─ runner-001: repo-a / branch-a / begrenzter Token
├─ runner-002: repo-a / branch-b / begrenzter Token
└─ runner-003: repo-b / branch-c / begrenzter Token
│
▼
GitHub PR + CI + menschliches ReviewDasselbe Muster stützt OpenClaw Background Tasks, OpenClaw Monitoring und OpenClaw Remote SSH Workflows.
Grenzen für sichere Remote-Agenten
Lege nicht jeden Token auf jeden Runner. Der sichere Standard ist: langlebige Schlüssel lokal speichern, pro Runner nur Repo und Branch freigeben, kurzlebige GitHub-Tokens nutzen, Deployments durch CI laufen lassen, Logs zurückstreamen und Runner nach Abschluss löschen.
Office Claws for OpenClaw users konzentriert sich deshalb auf Desktop-Management, VPS-Runner, Logs und lokale Schlüsselverwaltung statt auf einen permanent vertrauenswürdigen Serveraccount.
Größen- und Kostenregeln
| Workload | Runner | Hinweis |
|---|---|---|
| Doku, Skripte, kleine Fixes | 2 vCPU / 4 GB RAM | günstige Basis |
| Web-App mit Tests | 4 vCPU / 8 GB RAM | guter Standard |
| Browser/E2E | 4-8 vCPU / 16 GB RAM | Abhängigkeiten isolieren |
| großes Monorepo | dedizierter Runner | Cache und Parallelität begrenzen |
Kostenkontrolle entsteht durch Warteschlangen, Limits und Teardown, nicht nur durch billigere Instanzen.
Betriebscheckliste
- Aufgabe hat Branch, Repository und erwartetes Ergebnis.
- Runner startet aus sauberem Image oder Worktree.
- Zugangsdaten sind begrenzt und kurzlebig.
- Logs, Exit-Status und Diffs sind sichtbar.
- CI ist der einzige Deploy-Pfad.
- Vor dem Merge gibt es menschliches Review.
Für mehr Kontext siehe OpenClaw Security Best Practices und OpenClaw Secrets Management.
Wo Office Claws passt
Office Claws macht daraus einen Operator-Workflow: lokales Desktop-Control, remote VPS-Runner, dauerhafte Aufgabenverfolgung, Logs und Codex-gestützte Ausführung. So entstehen OpenClaw-ähnliche Abläufe ohne versteckte Terminalzustände und mit kleinerem Blast Radius.