Moltworker: Running OpenClaw as a Cloudflare Sandbox Container

What Moltworker Actually Packages

Moltworker is a thin deployment layer. It takes OpenClaw, a personal AI assistant with a gateway architecture, and wraps it so it runs inside a Cloudflare Sandbox container. OpenClaw itself is the renamed project formerly known as Moltbot and Clawdbot. The assistant connects to Telegram, Discord, and Slack, offers a web-based Control UI, pairs devices through an approval flow, and keeps conversation history across sessions. Moltworker does not reimplement any of that. It provides the container image, the wrangler configuration, and the setup steps. The README is explicit that this is experimental and unsupported. That label matters. You are not getting a managed product. You are getting a packaging of someone else's assistant into Cloudflare's container runtime, with all the moving parts left visible.

The Architecture: A Container Behind a Worker

The core idea is that OpenClaw runs in a Cloudflare Sandbox, which is a container environment. The worker front-end receives requests, and the first request can take one to two minutes because the container needs to start. The README describes a standard-1 instance with half a vCPU, 4 GiB of memory, and 8 GB of disk. The container is always on unless you configure SANDBOX_SLEEP_AFTER to make it sleep when idle. The worker exposes two paths: the Control UI at the root, protected by a gateway token, and an admin UI at /_admin/ for device management. That admin UI is protected by Cloudflare Access, not by the gateway token. The worker validates JWTs from Access using CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD secrets. So there are two separate authentication layers. The gateway token gates the chat interface. Access gates the administrative functions. If you skip either, the UI is unusable, per the README's warning.

Getting It Running: Commands and Secrets

The quick start is short but has several mandatory steps. You install dependencies with npm install. Then you set secrets. For direct Anthropic access, you run npx wrangler secret put ANTHROPIC_API_KEY. Alternatively, you can route through Cloudflare AI Gateway by setting CLOUDFLARE_AI_GATEWAY_API_KEY, CF_AI_GATEWAY_ACCOUNT_ID, and CF_AI_GATEWAY_GATEWAY_ID. You also generate a gateway token with openssl rand -hex 32 and set it as MOLTBOT_GATEWAY_TOKEN. That token is required to open the Control UI at https://your-worker.workers.dev/?token=YOUR_GATEWAY_TOKEN. The README is blunt: you will not be able to use the Control UI until you set up Cloudflare Access and pair a device. Access setup involves enabling the built-in Access integration on workers.dev, copying the AUD tag, and setting CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD. Then you redeploy. The truncated command after npm run is cut off in the material, so the exact redeploy command is not visible. That missing piece is a real gap for a reader trying to follow along.

The Cost Reality: More Than the $5 Plan

The README includes a detailed cost estimate, which is rare and useful. The Workers Paid plan is $5 per month. But the container itself is billed separately. For a standard-1 instance running 24/7, the estimate is roughly $26 for memory, $2 for CPU at 10 percent utilization, and $1.50 for disk, for a total near $34.50 per month. Memory and disk are billed on provisioned capacity for the full runtime. CPU is billed on active usage only. That distinction matters. A lightly used assistant might sit idle most of the time, but memory and disk charges keep accumulating. The README suggests configuring SANDBOX_SLEEP_AFTER to something like 10m so the container sleeps. If it only runs four hours a day, compute drops to roughly $5 to $6 on top of the plan fee. Network egress and logs are extra but described as minimal. This is the kind of concrete financial detail that most experimental projects omit, and it changes the adoption calculus.

A Genuine Limitation: The Access Setup Is Not Optional

The most obvious failure mode is skipping the Cloudflare Access configuration. The README states in bold that you must set up Access and pair a device before the Control UI works. If you only set the Anthropic key and the gateway token, you will hit a wall. The admin UI at /_admin/ is protected by Access, and without it you cannot pair devices. The README even notes that the Manage Cloudflare Access link in the dialog may 404, so you have to navigate the Zero Trust dashboard manually. That is a friction point. For a single user, the setup is doable but tedious. For a team, you need to configure identity providers and allow lists. Another limitation is the container start time. The first request can take one to two minutes, which is fine for a personal assistant but poor for any interactive use that expects a quick response. The project is also explicitly unsupported and may break without notice. There is no release history retrieved, and the last push date is unknown, so maintenance cadence is unclear.

The Wrong Tool for Some Cases

Moltworker is the wrong choice if you are on the Workers free plan, because Sandboxes require the Paid plan. It is also wrong if you need a low-latency, always-warm assistant. The one to two minute cold start on first request is a hard constraint. If you want a simple self-hosted assistant without Cloudflare-specific services, you would run OpenClaw directly on your own server or a VM. That avoids the container billing and the Access setup, but you then handle uptime, updates, and security yourself. The README does not compare Moltworker to that path, but the trade-off is clear. Moltworker trades operational control for a managed container environment. If you already live in Cloudflare's ecosystem, the integration with Access, AI Gateway, and R2 is convenient. If you do not, the setup overhead is significant.

A Real Alternative: Direct Self-Hosting of OpenClaw

The direct alternative is to run OpenClaw yourself on a standard server or a container platform like Docker. The difference is in the hosting model. Moltworker uses Cloudflare Sandbox, which bills you for provisioned memory and disk, and requires the Workers Paid plan. Direct hosting on a small VPS typically gives you a fixed monthly cost, often lower than the $34.50 estimate, and you control the runtime environment completely. You also avoid the Cloudflare Access requirement, because you can expose the Control UI over SSH or a VPN. The trade-off is that you must manage the process, handle restarts, and deal with updates manually. OpenClaw's gateway architecture works the same either way; only the deployment target changes. If you want to avoid Cloudflare's pricing model entirely, direct hosting is the simpler cost structure, though it shifts operational burden onto you.

Maintenance, Upgrades, and License

The README does not describe an upgrade path. There are no release notes retrieved, and the last push date is unknown. The project is marked experimental, so you should expect breaking changes without notice. The repository is not archived, which is a positive sign, but that is a weak signal. The license is Apache-2.0, which permits commercial use, modification, and distribution, with the usual conditions about preserving copyright notices. That license applies to Moltworker's own code, not necessarily to OpenClaw, so check OpenClaw's license separately if you plan to redistribute. For maintenance, the practical cost is in the secrets. You have to manage ANTHROPIC_API_KEY, CF_ACCESS_TEAM_DOMAIN, CF_ACCESS_AUD, and MOLTBOT_GATEWAY_TOKEN. Rotating the gateway token means regenerating it and updating the secret, and you must save it because the README tells you to. R2 storage is optional for persistence, but if you enable it, you pay for storage and need to consider backup. The project is a proof of concept, so the maintenance burden is on you to track changes in both Moltworker and OpenClaw.

Editorial conclusion

Adopt Moltworker if you are already on a Workers Paid plan, want a managed always-on host for a personal AI assistant, and accept the experimental label and the roughly $34.50 per month estimate for a 24/7 standard-1 container. Do not adopt it if you need a stable, supported deployment, if you are on the free tier, or if you cannot commit to Cloudflare Access and device pairing before using the Control UI. Before deploying, verify the current Cloudflare Containers pricing, confirm the Sandbox sleep behavior with SANDBOX_SLEEP_AFTER, and check whether your Anthropic usage fits the AI Gateway billing option. The project is a proof of concept and may break without notice, so treat it as a testbed, not a production system.

Official sources

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