vs OpenClaw (upstream)
OpenClawMU vs upstream OpenClaw
OpenClaw is the brilliant single-user AI gateway. OpenClawMU is the same code with the multi-tenant surface added — token isolation, sandboxes, quotas, web terminal, S3 backup.
OpenClaw upstream is a single-user AI assistant that bridges WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Teams, Matrix, LINE, Lark, Google Chat, and WebChat. Same channels, same agent runtime, same skill ecosystem — but the assumption is one user, one device, one set of credentials, one set of channels paired.
OpenClawMU is that same codebase with a multi-tenant surface added. The diff is significant but contained: a per-tenant directory layout, a token-auth dispatcher in front of every JSON-RPC method, sandbox spawning per tenant (with isolation between them), per-tenant quotas and cost accounting, a control-plane HTTP API for admin resource management, S3 backup, and a few hundred lines of glue.
What’s the same
- Every channel adapter (WhatsApp via Baileys, Telegram via grammY, etc.)
- The Pi agent runtime
- The skill registry and ClawHub integration
- The CLI surface for non-tenant-related commands
- The web canvas / UI
- The voice-wake-word + Whisper transcription pipeline
If you’ve used upstream OpenClaw, OpenClawMU will feel identical except for the few extra commands.
What’s different
- Tenant token auth in front of every JSON-RPC and HTTP API.
- Isolated per-tenant directories for sessions, memory, plugins, sandbox roots, cron, channels, config.
- Tenant-scoped HTTP APIs — OpenAI
/v1/chat/completionsand OpenResponses/v1/responsesendpoints route by tenant token. - Web terminal with xterm.js + node-pty, sandboxed per tenant.
- Per-tenant quotas — tokens/day, USD/day, requests/minute.
- S3 backup of full tenant state with path-traversal hardening.
- Control-plane HTTP API for admin resource management.
- Admin / tenant key separation — config overlay can’t override admin keys.
When the upgrade is worth it
If you’re using upstream for personal use and you’re happy, stay. If you’re starting to think about “what if my friend wants their own session” or “what if I want to give this to a customer”, switch.
Migration path
openclaw service stop. Install OpenClawMU. Use openclaw tenants import-from-upstream (one-shot script in the docs) to convert your single-user state into a default tenant. Start the new gateway. Everything else stays the same.
When to pick OpenClawMU
- You need more than one user on the same gateway.
- You're building a SaaS / multi-customer product on top of the OpenClaw agent runtime.
- You want per-tenant cost accounting, quotas, or billing reports.
- Your security team requires hardened path-traversal protection and admin/tenant key separation.
- You need S3-portable tenant snapshots.
When to pick OpenClaw (upstream) instead
- It's you on your laptop — single user, no isolation worries.
- You're contributing to upstream and want a smaller diff to reason about.
- You want the absolute leading edge of features; the MU fork rebases on a cadence.
Frequently asked
- How often does OpenClawMU rebase against upstream?
- Every 2–4 weeks, depending on upstream activity. The fork-marker convention (OPENCLAWMU ADDITION comments) keeps the merge surface small.
- Can I run upstream and MU side by side on the same machine?
- Yes — different ports. Many operators do this during evaluation. Tenant data is in different directories so there's no overlap.
- Will the MU patches ever land upstream?
- Some might (path-traversal hardening is a likely candidate). The full multi-tenant surface is unlikely to land because it's a structural choice that doesn't fit upstream's product vision. The fork is the upstream — for multi-tenant use.