moltworker: OpenClaw als always-on-Assistent in der Cloudflare-Sandbox betreiben

Ein Proof of Concept, kein Support-Produkt

moltworker ist ein TypeScript-Repository von Cloudflare, das den persoenlichen KI-Assistenten OpenClaw, frueher unter den Namen Moltbot und Clawdbot bekannt, in einen Cloudflare-Sandbox-Container verpackt. Die README stellt das Projekt von der ersten Zeile an als experimentelles Proof of Concept vor: Es demonstriere, dass OpenClaw in der Sandbox laufen kann, sei nicht offiziell unterstuetzt und koenne ohne Vorankuendigung brechen. Wer es nutzt, tut das auf eigenes Risiko. Diese Einordnung ist wichtig, weil das Repo mit rund 10.000 Sternen auf GitHub den Eindruck eines stabilen Produkts erweckt, tatsaechlich aber eine Show-Case-Referenzimplementierung ist.

Die Homepage des Repositories fuehrt zu einem Cloudflare-Blogbeitrag ueber das Selbsthosten von KI-Agenten, in dem die Architektur erklaert wird. Fuer den technischen Einstieg reicht die README allein: Sie beschreibt Anforderungen, Deployment, Kosten, Absicherung und optionale Integrationen. Das Projekt steht unter der Apache-2.0-Lizenz, darf also kommerziell genutzt, veraendert und weiterverteilt werden, solange die Lizenzhinweise erhalten bleiben.

Was OpenClaw im Container tatsaechlich leistet

OpenClaw ist ein Assistent mit Gateway-Architektur, der sich an mehrere Chat-Plattformen anschliesst. Der Kern ist eine webbasierte Control-UI am Gateway, dazu kommen Anbindungen an Telegram, Discord und Slack. Neue Geraete muessen ueber eine explizite Freigabe gekoppelt werden, Konversationen bleiben ueber Sitzungen hinweg erhalten, und ein erweiterbarer Agent-Workspace mit Skills bildet die eigentliche Intelligenzschicht.

moltworker fuehrt genau diesen Stack in einem Cloudflare-Container aus, sodass der Assistent dauerhaft erreichbar ist, ohne dass ein eigener Server betrieben werden muss. Optional sichert R2-Storage die Daten ueber Container-Neustarts hinweg. Die README betont, dass damit eine vollstaendig verwaltete, always-on-Deployments moeglich wird, sofern man den Workers-Paid-Plan von 5 USD pro Monat aktiviert hat, denn Cloudflare-Sandbox-Container sind nur dort verfuegbar.

Kostenrechnung fuer den standard-1-Container

Die README enthaelt eine ausfuehrliche Kostenschaetzung fuer eine standard-1-Instanz mit halber vCPU, 4 GiB Arbeitsspeicher und 8 GB Festplatte bei 24/7-Betrieb: rund 34,50 USD pro Monat, davon 5 USD fuer den Workers-Paid-Plan, etwa 26 USD fuer Speicher nach bereitgestellter Kapazitaet, 2 USD fuer CPU bei ca. 10 Prozent Auslastung und 1,50 USD fuer Festplatte. CPU wird nur nach aktivem Verbrauch abgerechnet, waehrend Memory und Disk nach der bereitgestellten Kapazitaet fuer die gesamte Laufzeit kosten. Netzwerk-Egress, Workers- und Durable-Objects-Anfragen sowie Logs kommen hinzu, fallen im persoenlichen Betrieb aber meist kaum ins Gewicht.

Wer Kosten druecken will, setzt die Umgebungsvariable SANDBOX_SLEEP_AFTER auf einen Wert wie 10m, damit der Container im Leerlauf einschlaeft. Ein Assistent, der nur vier Stunden taeglich laeuft, verursacht laut README nur noch 5 bis 6 USD an Compute-Kosten zusaetzlich zur Plan-Gebuehr. Fuer kleinere oder schwerere Workloads nennt die Tabelle der Cloudflare-Containers-Preisseite Alternativen: eine lite-Instanz mit 256 MiB fuer 0,50 USD monatlich oder eine standard-4-Instanz mit 12 GiB fuer anspruchsvollere Agenten.

Deployment in fuenf Befehlen

Der Quick-Start ist bewusst kurz gehalten. Nach dem Klonen installiert man Abhaengigkeiten mit npm install, setzt den Anthropic-API-Key per npx wrangler secret put ANTHROPIC_API_KEY und erzeugt ein Gateway-Token mit openssl rand -hex 32, das als MOLTBOT_GATEWAY_TOKEN exportiert wird. Statt des direkten Anthropic-Zugriffs kann auch das Cloudflare AI Gateway mit Unified Billing genutzt werden, wofuer die Secrets CLOUDFLARE_AI_GATEWAY_API_KEY, CF_AI_GATEWAY_ACCOUNT_ID und CF_AI_GATEWAY_GATEWAY_ID gesetzt werden. Nach dem Deploy erreicht man die Control-UI unter https://your-worker.workers.dev/?token=YOUR_GATEWAY_TOKEN.

Die README warnt davor, dass die erste Anfrage ein bis zwei Minuten dauert, waehrend der Container startet. Wichtiger noch: Die Control-UI funktioniert erst, wenn man zusaetzlich Cloudflare Access fuer die Admin-UI eingerichtet und ein Geraet ueber /_admin/ gekoppelt hat. Wer beides ueberspringt, steht vor einer leeren Anwendung. Fuer die lokale Entwicklung gibt es die Datei .dev.vars, in der DEV_MODE=true Access und Geraetekopplung ueberspringt und DEBUG_ROUTES=true Debug-Endpunkte aktiviert.

Drei Ebenen der Absicherung: Access, Token, Kopplung

Das Deployment hat drei unabhaengige Authentifizierungsschichten. Cloudflare Access schuetzt die Admin-Routen /_admin/, /api/* und /debug/*; dafuer aktiviert man die eingebaute Access-Integration fuer workers.dev im Dashboard, traegt seine E-Mail in die Allowlist ein und setzt danach die Secrets CF_ACCESS_TEAM_DOMAIN und CF_ACCESS_AUD, damit der Worker JWTs validieren kann. Den Application-Audience-Tag kopiert man aus den Access-Einstellungen, den Team-Domain-Namen findet man im Zero-Trust-Dashboard unter Settings und Custom Pages.

Die zweite Ebene ist das Gateway-Token MOLTBOT_GATEWAY_TOKEN, das beim Zugriff auf die remote gehostete Control-UI als ?token=-Parameter uebergeben wird. Die dritte Ebene ist die Geraetekopplung: Jedes neue Geraet muss in der Admin-UI unter /_admin/ explizit genehmigt werden, was die README als sicherste Option bezeichnet, weil sie eine bewusste Freigabe pro Geraet erzwingt. Nur DEV_MODE=true in der lokalen Entwicklung umgeht alle drei Schichten auf einmal.

Persistenz ueber R2 und Schlafverhalten des Containers

Ohne weitere Konfiguration gehen Daten beim Neustart des Containers verloren, weil der Speicher ephemeral ist. Die README beschreibt ein optionales R2-Setup nach dem Backup-Restore-Muster: Beim Start werden vorhandene R2-Backup-Daten in das moltbot-Konfigurationsverzeichnis wiederhergestellt, ein Cron-Job synchronisiert alle fuenf Minuten die Konfiguration nach R2, und die Admin-UI bietet eine Schaltflaeche fuer manuelle Backups. Fehlen die R2-Credentials, laeuft der Worker weiter, aber mit ephemeral Storage.

Standardmaessig lebt der Container unbegrenzt, was der Wert SANDBOX_SLEEP_AFTER=never abbildet und wegen der Kaltstartzeit von ein bis zwei Minuten empfohlen wird. Setzt man stattdessen eine Dauer wie 10m oder 1h, schlaeft der Container nach Inaktivitaet ein, und die naechste Anfrage loest einen Kaltstart aus. Mit aktivierter R2-Persistenz ueberleben gekoppelte Geraete und der Chatverlauf Neustarts und Schlafphasen, was fuer den dauerhaften Betrieb die sinnvolle Kombination ist.

Kanaele, Browser-Automatisierung und der CDP-Shim

Ueber die Control-UI hinaus dokumentiert die README optionale Integrationen. Chat-Plattformen wie Telegram, Discord und Slack werden jeweils ueber Bot-Tokens per wrangler secret konfiguriert. Fuer Browser-Automatisierung gibt es einen CDP-Shim, der Endpunkte wie /cdp/json/version und /cdp/json/list sowie eine WebSocket-Verbindung bereitstellt, alles abgesichert durch einen CDP_SECRET-Query-Parameter. Der Container bringt vorgefertigte Skills unter /root/clawd/skills/ mit, darunter eine cloudflare-browser-Faehigkeit mit Skripten fuer Screenshots und Videos.

Beim KI-Zugriff kann der Worker Cloudflare AI Gateway als Provider nutzen, gesteuert durch Secrets fuer Gateway-Key, Account-ID und Gateway-ID, mit optionalem Model-Override im Format provider/model-id. Die aeltere Konfiguration AI_GATEWAY_API_KEY gilt als veraltet, wird aber laut README weiter unterstuetzt.

Bekannte Stolpersteine und was die Apache-2.0-Lizenz bedeutet

Der Troubleshooting-Abschnitt nennt konkrete Fehlerbilder. npm run dev schlaegt mit Unauthorized fehl, wenn Cloudflare Containers im Account nicht aktiviert sind. WebSocket-Proxying hat in der lokalen Entwicklung bekannte Einschraenkungen, volle Funktionalitaet gibt es nur beim echten Deploy. Unter Windows kann Git Shell-Skripte mit CRLF-Zeilenenden auschecken, wodurch das Gateway im Linux-Container mit Exit-Code 126 abstuerzt; die Loesung ist, Git auf LF-Zeilenenden zu konfigurieren. Wer diese Punkte kennt, spart sich stundenlanges Fehlersuchen.

Die Apache-2.0-Lizenz erlaubt kommerzielle Nutzung, Modifikation, Sublizenzierung und Vertrieb ohne Einschraenkung, enthaelt ausserdem eine Patentlizenz und keine Garantie. Das passt zur experimentellen Ausrichtung: Der Code ist frei kopierbar, aber die README warnt ausdruecklich davor, ohne eigene Tests auf den Assistenten in Produktion zu setzen.

Redaktionelles Fazit

moltworker lohnt sich fuer Entwickler mit einem Cloudflare-Konto, die OpenClaw ohne eigenen Server dauerhaft laufen lassen wollen und bereit sind, die experimentellen Kanten wie CRLF-Fehler unter Windows und die Kaltstartzeit von ein bis zwei Minuten zu tragen. Wer den Container rund um die Uhr betreibt, sollte vor dem Deploy die Kostentabelle fuer standard-1 durchrechnen und SANDBOX_SLEEP_AFTER sowie R2-Persistenz bewusst konfigurieren.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository