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.

Updated June 1, 2026

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/completions and OpenResponses /v1/responses endpoints 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.

EXFOLIATE!

Run your own gateway today.

Apache-2.0, self-hosted, no SaaS layer between you and your users. Install the CLI, create your first tenant, mint a token — you're routing traffic in 60 seconds.