--- title: "OpenClaw vs OpenClawMU: when to fork from single-user to multi-tenant" description: "OpenClaw is a brilliant single-user AI gateway. OpenClawMU is the multi-tenant fork. Here's exactly what differs, when the fork is worth it, and how to migrate cleanly without losing state." url: https://openclawmu.neullabs.com/blog/openclaw-vs-openclawmu publishedAt: 2026-06-01T00:00:00.000Z tags: ["openclaw", "openclawmu", "multi-tenant", "fork", "migration"] cluster: cornerstone source: OpenClawMU --- Upstream OpenClaw is the AI gateway. One Node process bridges WhatsApp, Telegram, Slack, Discord, Signal, iMessage, Teams, Matrix, LINE, Lark, Google Chat, and WebChat to your LLM of choice, with skills, memory, sandboxing, voice wake-words, and a canvas UI. It's a remarkable single-user product. OpenClawMU is the same codebase with a multi-tenant surface added. The "MU" stands for multi-user / multi-tenant. This article is the precise diff: what's different, what's the same, when to switch, and how to migrate without losing state. ## What's the same Everything you love about upstream is in MU, unchanged: - **All channel adapters.** Same Baileys for WhatsApp, same grammY for Telegram, same Bolt for Slack. - **The Pi agent runtime.** Same SDK, same skill format, same canvas UI hooks. - **ClawHub.** Same skill registry, same install flow. - **CLI surface.** `openclaw agent`, `openclaw skills`, `openclaw onboard` — all unchanged. - **Voice wake-word + Whisper.** Same pipeline. - **The Discord community.** Shared with upstream. If you're an upstream user, the MU gateway will feel identical except for a handful of new commands. ## What's different The diff is in the parts that bear state and credentials. Specifically: ### 1. Tenant token authentication Every JSON-RPC method and every HTTP API endpoint requires a Bearer token. The dispatcher hashes it (SHA-256, constant-time compared) and resolves the tenant ID. No tenant-scoped method accepts an unauthenticated request. ### 2. Isolated directory layout ``` # upstream ~/.openclaw/sessions/ ~/.openclaw/memory/ ~/.openclaw/plugins/ ~/.openclaw/cron/ # MU ~/.openclaw/tenants/acme/sessions/ ~/.openclaw/tenants/acme/memory/ ~/.openclaw/tenants/acme/plugins/ ~/.openclaw/tenants/acme/cron/ ~/.openclaw/tenants/globex/sessions/ ... ``` Every state-bearing directory is per-tenant. The dispatcher resolves the tenant from the auth token and routes all path-taking operations against that tenant's root. ### 3. Sandboxed per tenant Both upstream and MU support bubblewrap and Docker sandboxes. The difference: in MU, the sandbox root is the tenant's `sandbox/` directory. A code-executing tool call run by tenant A cannot read tenant B's data, even if it tries to escape the sandbox (it can't, but defense in depth). ### 4. Per-tenant quotas Upstream has no quota concept (you're the user; you set your own limits). MU adds three knobs per tenant: tokens/day, USD/day, requests/minute. Exceed any and the gateway returns 429 with the next-reset timestamp. ### 5. Cost accounting Upstream records LLM usage in a single bucket. MU adds a tenant column to every billing row, plus a CSV report generator scoped per tenant per period. ### 6. Web terminal Upstream has terminal commands in the local CLI. MU adds a browser-based xterm.js UI that attaches to a per-tenant sandboxed pty over WebSocket. The terminal token-authenticates on every frame, not just the handshake. ### 7. Control-plane HTTP API Upstream's admin surface is the CLI. MU adds an HTTP control plane (admin-key authenticated) for tenant CRUD, quota updates, usage queries, backup triggers. The CLI is now a thin wrapper around this API. ### 8. S3 backup / restore Upstream doesn't bundle backup. MU has `openclaw tenants backup --to s3://...` and the reverse-symmetric restore, both path-traversal hardened. ### 9. Admin / tenant key separation In upstream, all keys live in the same config. In MU, certain keys are admin-only — LLM credentials, the rate card, S3 credentials. Tenant config overlays cannot override these (it's checked at load time). ### 10. OpenAI-compatible HTTP endpoints scoped per tenant MU exposes `/v1/chat/completions` and `/v1/responses` that accept a tenant Bearer token and route to that tenant's session/memory/tools. Point any OpenAI SDK at your gateway and it Just Works. ## When the MU fork is worth it Switch to MU if **any** of these apply: - More than one person uses your gateway. - You want to charge customers and need per-customer cost accounting. - You're building a SaaS / multi-customer product on top of OpenClaw. - You need sandbox isolation between code-executing workloads. - You want S3-portable tenant snapshots. - Your security or compliance team wants admin/tenant key separation. Stay on upstream if: - It's just you, on your own machine, no plans to share. - You contribute to upstream and want a smaller diff to reason about. - You're using a feature that's leading-edge in upstream and not yet rebased into MU. ## Migration: upstream → MU The MU CLI ships a one-shot importer that converts an upstream state directory into a default tenant: ```bash # 1. Stop upstream openclaw service stop # 2. Install MU npm install -g openclaw@latest --tag mu # 3. Import upstream state as a tenant named 'default' openclaw tenants import-from-upstream \ --upstream-dir ~/.openclaw-upstream-backup \ --as default # 4. Start MU openclaw service start # 5. Get the default tenant's token openclaw tenants token show default ``` After import, your sessions, memory, channels, and cron jobs are accessible via the `default` tenant. Channels stay paired (no need to re-scan WhatsApp QR). You can then add more tenants alongside. ## Migration: MU → upstream Less common but possible. Pick a single tenant; back up; install upstream; point upstream at the tenant's data directory. Multi-tenant data not on the chosen tenant is left behind (back it up too). ## Rebasing cadence The MU branch rebases onto upstream every 2–4 weeks. New channels, agent runtime improvements, skill features all land in MU automatically. The `OPENCLAWMU ADDITION` markers make the merge surface tractable — when upstream changes a function MU also touches, the conflict resolution is straightforward. If you're running MU in production, pin to a tagged release; if you want the leading edge, run from `main`. ## What stays free forever OpenClaw upstream: free, Apache-2.0. OpenClawMU: free, Apache-2.0. Neither charges per seat or per active user. Neither runs SaaS infrastructure you depend on. The bet is that more open, more usage, more contributions outweigh anything we'd extract via licensing. The bot platform incumbents charge a margin because they own the chokepoint; the open-source fork model says no thanks. ## Summary OpenClaw is the brilliant single-user product. OpenClawMU is the same code with the multi-tenant surface. Switch the moment you need more than one user or want to charge customers. Migration is one command. Rebase against upstream every few weeks. Both will be free forever.