Bot developers
Graduate a prototype to a product
You built a single-user assistant that works — now customers want their own, isolated and billed.
The problem
- Your single-user OpenClaw bot is a hit, and now people want their own instance — but you don't want to maintain a fork per customer.
- You'd rather not rewrite the agent logic you already have working just to make it multi-tenant.
- You need paid tiers, but you have no metering and no way to keep one customer's usage from spilling into another's.
With OpenClawMU
- OpenClawMU keeps every upstream OpenClaw channel and agent feature, then layers tenant token auth and per-tenant isolation on top — your agent behaviour is unchanged.
- Fork commits are labelled OPENCLAWMU ADDITION so you can rebase against upstream cleanly and keep pulling upstream improvements.
- The OpenAI- and OpenResponses-compatible tenant API means your existing client code points at the gateway with a token and just works — sessions, memory and quotas apply per tenant automatically.
How it works
Getting there, step by step.
- 1
Move to the MU gateway
Run your existing OpenClaw configuration on OpenClawMU — the multi-tenant fork keeps the same channels and agent features.
- 2
Turn each customer into a tenant
Create a tenant per customer; each gets an isolated directory and a token.
- 3
Point clients at the tenant API
Swap the base URL to your gateway's OpenAI-compatible endpoint and pass the tenant token — no SDK changes for your users.
- 4
Add plans with quotas
Attach quotas per tenant to back your free and paid tiers, and export usage for billing.
# one gateway, many tenants
npm install -g openclaw@latest
openclaw onboard --install-daemon
# a tenant per customer / team
openclaw tenants create acme Frequently asked
FAQ — graduate a prototype to a product
Every question here is also emitted as FAQPage JSON-LD — so Google AI Overviews, Perplexity, and ChatGPT browsing extract the answers cleanly. Crawler-friendly fallback below for screen readers and bots that don't run JS.
No. OpenClawMU preserves upstream OpenClaw's channels and agent features; the fork adds isolation and multi-tenancy around them. Additions are labelled so you can rebase against upstream cleanly.
Yes — it exposes OpenAI-compatible /v1/chat/completions and OpenResponses /v1/responses endpoints, scoped to a tenant by token, so any OpenAI SDK works unchanged.
Related use cases
-
Ship a multi-tenant bot platform
The agent platform you're building needs isolation between customers without inventing it from scratch.
Read → -
Bridge many messaging channels
Reach users where they already are — 12+ messaging channels bridged into one AI gateway, per-tenant.
Read → -
How isolation works
The load-bearing change vs. upstream — tokens, per-tenant directories, path-traversal hardening.
Read the deep dive →
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.