How to Run OpenClaw on Cloudflare Workers (Moltworker) — the In‑Depth, Step‑by‑Step Guide (2026)

Jan 31, 2026Updated Jan 31, 2026

If you’ve seen people running OpenClaw on a spare machine at home (or buying dedicated hardware to keep it always‑on), you’re not alone. Cloudflare called out that trend directly—then introduced Moltworker, a project that lets you run OpenClaw online, securely, without dedicated hardware. You can read the announcement here: Cloudflare’s Moltworker launch post.

This guide is the complete, practical setup flow with the security steps that are required to make Moltworker usable in production.

1) What OpenClaw is (and what “Moltworker” is)

If you’re new to the ecosystem, here’s the simple version:

OpenClaw is an open‑source personal AI assistant built around a gateway architecture. Most operations flow through a single long‑running Gateway process that owns chat channel connections and exposes a WebSocket‑based control plane. The official docs live at docs.openclaw.ai.
Moltworker is Cloudflare’s “make this run on Cloudflare” wrapper: a middleware Worker + adapted runtime scripts that run OpenClaw inside Cloudflare Sandboxes, with optional persistent storage and browser automation hooks. It’s described as a proof of concept and may break without notice. The canonical README is here: cloudflare/moltworker.

Also worth noting (because naming online can get confusing fast): Cloudflare’s blog explicitly says Moltbot was renamed to OpenClaw (Jan 30, 2026), and the repo still uses some older env var names like MOLTBOT_GATEWAY_TOKEN.

2) Why run OpenClaw on Cloudflare?

Running OpenClaw locally is totally valid, but Cloudflare gives you a different set of advantages—especially if you want something that’s “always there” without babysitting a machine.

You don’t need dedicated hardware

The whole pitch is: don’t buy or maintain a box just to keep your assistant alive. Moltworker is designed to run OpenClaw efficiently and securely online.

Sandboxed execution (safer by default)

Cloudflare uses Sandboxes so you can run code in isolated environments (good fit for AI agents that may execute tools or run scripts).

Built‑in authentication + access policies

Instead of building auth yourself, you can protect your admin UI and internal routes with Cloudflare Access (Zero Trust). Moltworker is designed around that approach.

Persistent storage when you want it (R2)

Containers are inherently ephemeral, so Moltworker supports R2 to persist conversation history, device pairings, and more across restarts.

Browser automation without running Chromium yourself (optional)

OpenClaw agents often need browser automation. Cloudflare’s Browser Rendering can provide managed headless browsers, and Moltworker includes a “thin CDP proxy” pattern + injected browser skill.

Model routing + observability (AI Gateway)

If you want analytics, cost tracking, rate limiting, caching, or the ability to switch models/providers without redeploying, Cloudflare AI Gateway is a strong add‑on.

3) How it works: OpenClaw + Cloudflare architecture (simple mental model)

Moltworker isn’t “just run Node.js in Workers.” It’s more like:

A Cloudflare Worker sits at the edge as the entrypoint (routing requests + proxying to internal services).
The OpenClaw runtime runs inside a Sandbox container, where it can behave much more like a “real machine process.”
Cloudflare Access protects sensitive routes (admin + APIs).
Optional R2 makes state survive restarts.

Cloudflare’s blog describes Moltworker as an entrypoint Worker plus admin UI, connected to a Sandbox container running the standard OpenClaw gateway runtime, with R2 for persistence.

4) Deploy OpenClaw to Cloudflare with Moltworker

Hard requirements

Cloudflare Workers Paid plan (Sandboxes require it).
A model provider key (most examples use Anthropic/Claude) or Cloudflare AI Gateway with a configured provider/unified billing.
Local dev basics: Git + Node.js + npm, and the Cloudflare Wrangler CLI.

Strongly recommended

Cloudflare Access configured (required for the admin UI in this setup).
R2 storage if you don’t want to lose pairings/history when the container restarts.

Optional (but fun)

Chat channels: Telegram / Discord / Slack tokens.
Browser automation via CDP (plus Browser Rendering).
AI Gateway routing and analytics.

Step-by-step: Deploy OpenClaw on Cloudflare with Moltworker

This is the “do it now” path. It closely follows the Moltworker README quick start and then completes the security steps that are called mandatory.

Step 1 — Get the Moltworker project locally

Clone the repo, then install dependencies:

git clone https://github.com/cloudflare/moltworker.git
cd moltworker

# Install dependencies
npm install

(There’s also a “Deploy to Cloudflare” button in the repo, but the manual flow below makes it easier to understand what’s happening and how to secure it.)

Step 2 — Add your AI model credentials

Option A: Direct Anthropic key

npx wrangler secret put ANTHROPIC_API_KEY

Option B: Use AI Gateway instead (recommended for analytics + control)

npx wrangler secret put AI_GATEWAY_API_KEY
npx wrangler secret put AI_GATEWAY_BASE_URL

Moltworker notes these take precedence if both are set.

Step 3 — Generate and store a Gateway token (don’t skip this)

This token is required for remote access to the Control UI via ?token=. Generate a secure random token and save it.

export MOLTBOT_GATEWAY_TOKEN=$(openssl rand -hex 32)
echo "Your gateway token: $MOLTBOT_GATEWAY_TOKEN"
echo "$MOLTBOT_GATEWAY_TOKEN" | npx wrangler secret put MOLTBOT_GATEWAY_TOKEN

Important: treat this like a password. It’s literally access to your assistant.

Step 4 — Deploy

npm run deploy

Step 5 — Open the Control UI (expect a slow first load)

After deployment, open:

https://your-worker.workers.dev/?token=YOUR_GATEWAY_TOKEN

The first request may take 1–2 minutes while the container starts.

5) Lock it down + persistence (Access, tokens, pairing, R2)

Moltworker is very blunt here: you won’t be able to use the Control UI until you do these two things:

Set up Cloudflare Access to protect the admin UI
Pair your device via /_admin/

That’s good. A remotely accessible AI agent should not be “public by accident.”

Layer 1 — Cloudflare Access protects admin + API routes

6.1 Enable Cloudflare Access on your worker

Quick path:

Go to Workers & Pages dashboard
Select your Worker
Settings → Domains & Routes
On the workers.dev row, click ...
Enable Cloudflare Access
Configure who can access (email allow list or identity providers)
Copy the Application Audience (AUD) tag

6.2 Set the Access secrets (so the Worker can validate JWTs)

npx wrangler secret put CF_ACCESS_TEAM_DOMAIN
npx wrangler secret put CF_ACCESS_AUD

6.3 Redeploy

npm run deploy

Then visit:

https://your-worker.workers.dev/_admin/

You should be prompted to authenticate via Cloudflare Access.

Pro tip: The README explicitly mentions protecting paths like /_admin/*, /api/*, and /debug/*. You can extend that policy if you want even tighter control.

Layer 2 — Gateway token for the Control UI

This is the ?token=... you generated earlier. Moltworker lists it as required for authentication.

Practical security note: Because it’s in a URL, it can leak via browser history, screenshots, or accidental sharing. If you want stricter security, consider also putting Access in front of the Control UI route (not just admin) and treat the token like a second factor.

Layer 3 — Device pairing (default)

Moltworker uses device pairing as the default secure model: when a new device connects, it stays pending until approved in the admin UI.

This aligns with OpenClaw’s broader gateway model: the gateway issues device tokens after pairing, and pairing approvals are required for new device IDs (unless you explicitly enable insecure modes).

Make it persistent: add R2 storage (recommended)

If you don’t configure persistence, container restarts can wipe state—because containers are ephemeral by nature. Moltworker includes an R2 persistence flow that syncs your OpenClaw state (and even mentions periodic sync).

Step 1 — Create R2 credentials

The README says to “create an R2 token” and then set these secrets:

npx wrangler secret put R2_ACCESS_KEY_ID
npx wrangler secret put R2_SECRET_ACCESS_KEY
npx wrangler secret put CF_ACCOUNT_ID

Step 2 — Redeploy

npm run deploy

What you get with R2 in Moltworker

Restores from R2 when the container starts
Syncs periodically (README mentions a cron-based sync every ~5 minutes)
Supports manual backup/restore via the admin UI

6) Optional upgrades, operations, and troubleshooting

8.1 Add chat channels: Telegram / Discord / Slack

OpenClaw supports a bunch of channels overall. Moltworker’s out‑of‑the‑box config highlights these three:

Telegram

npx wrangler secret put TELEGRAM_BOT_TOKEN
npm run deploy

Discord

npx wrangler secret put DISCORD_BOT_TOKEN
npm run deploy

Slack

npx wrangler secret put SLACK_BOT_TOKEN
npx wrangler secret put SLACK_APP_TOKEN
npm run deploy

DM policy note: Moltworker lists DM policies for Telegram/Discord (pairing default or open). Leaving it on pairing is safer.

8.2 Add browser automation (CDP shim + Browser Rendering)

Cloudflare’s blog explains why this matters: agents often need to navigate the web, fill forms, take snapshots, etc. Cloudflare Browser Rendering provides managed headless browser instances, and Moltworker bridges OpenClaw to it with a thin CDP proxy + an injected skill.

Moltworker’s README describes a CDP shim that enables browser automation and exposes endpoints under /cdp/*.

Setup

Set an auth secret:

npx wrangler secret put CDP_SECRET

Set your public worker URL:

npx wrangler secret put WORKER_URL
# Example: https://your-worker.workers.dev

Redeploy:

npm run deploy

All CDP endpoints require the CDP_SECRET header.

Built‑in “cloudflare-browser” skill

The container includes a pre‑installed skill with scripts like:

screenshot.js
video.js
cdp-client.js

Example usage:

node /root/clawd/skills/cloudflare-browser/scripts/screenshot.js https://example.com output.png

8.3 Route OpenClaw through AI Gateway (highly recommended for “serious” usage)

If you want one place to manage:

analytics and logs for model calls
caching / rate limiting
cost tracking
and even swapping providers or configuring fallbacks

AI Gateway is built for that. Moltworker supports it out of the box.

Operations + debugging tips

Container lifecycle + cold starts

By default, the container stays alive indefinitely (SANDBOX_SLEEP_AFTER=never).
Cold starts can take 1–2 minutes, and keeping it alive avoids that on first request.
You can reduce cost for infrequent use by setting a sleep timeout. Moltworker supports durations like 10m or 1h.

Debug endpoints

Moltworker can expose debug routes under /debug/* if enabled (requires DEBUG_ROUTES=true and Cloudflare Access). It includes endpoints for processes, logs, and version info.

Local dev gotcha: WebSockets

The README notes that wrangler dev has known limitations with WebSocket proxying through the sandbox: HTTP might work, but WebSockets may fail. For full functionality, deploy to Cloudflare.

Troubleshooting (common issues + fixes)

These are straight from the Moltworker README’s troubleshooting section (with a bit of practical framing):

npm run dev fails with Unauthorized → You likely need to enable Cloudflare Containers in the Containers dashboard.
Gateway fails to start → Check secrets (npx wrangler secret list) and logs (npx wrangler tail).
Config changes don’t seem to apply → The README suggests editing the # Build cache bust: comment in the Dockerfile and redeploying.
R2 not mounting / persistence not working → Confirm all three R2 secrets are set (R2_ACCESS_KEY_ID, R2_SECRET_ACCESS_KEY, CF_ACCOUNT_ID). Also note: R2 mounting only works in production, not with wrangler dev.
Access denied on admin routes → Verify CF_ACCESS_TEAM_DOMAIN and CF_ACCESS_AUD, plus Access application config.
Devices not appearing in admin UI → README notes device list commands can take ~10–15 seconds due to WebSocket overhead; wait and refresh.
WebSocket issues locally → wrangler dev can struggle with sandbox WebSockets; deploy for full functionality.

FAQ (SEO‑friendly)

Is Moltworker officially supported?

No—both the README and Cloudflare’s messaging describe it as experimental / proof‑of‑concept that may break without notice.

Do I need a paid Cloudflare plan?

Yes. Cloudflare Sandboxes require the Workers Paid plan.

How do I access the OpenClaw web UI?

Moltworker exposes a Control UI that you open with a query token, like:

/?token=YOUR_GATEWAY_TOKEN

Is this secure?

It can be—if you do it right.

Moltworker is designed with multiple layers:

Cloudflare Access on admin/API/debug routes
Gateway token for Control UI
Device pairing (default)

OpenClaw’s own docs also emphasize secure contexts for Control UI device identity (HTTPS/localhost) and warn about insecure auth modes.

Will my chat history persist?

Not unless you configure persistence. Containers are ephemeral; Moltworker supports R2 to persist conversation history and state across restarts.

Can I use providers other than Anthropic?

Yes. Moltworker lists other provider secrets (like OPENAI_API_KEY) and supports routing via AI Gateway (which supports multiple providers).

Copy/paste “minimum working deployment” checklist

If you want the quickest “I just want it running” plan:

1) Deploy

npm install
npx wrangler secret put ANTHROPIC_API_KEY

export MOLTBOT_GATEWAY_TOKEN=$(openssl rand -hex 32)
echo "$MOLTBOT_GATEWAY_TOKEN" | npx wrangler secret put MOLTBOT_GATEWAY_TOKEN

npm run deploy

2) Enable Access + set secrets + redeploy

npx wrangler secret put CF_ACCESS_TEAM_DOMAIN
npx wrangler secret put CF_ACCESS_AUD
npm run deploy

3) Visit /_admin/ → approve device (pairing)

4) (Recommended) Enable R2 persistence

Once you’ve got a clean deploy and secure access, you can iterate calmly: add channels, wire in browser automation, or move model traffic behind AI Gateway. Keep Access + pairing on, and treat gateway tokens like passwords.