Platform builders
Ship a multi-tenant bot platform
The agent platform you're building needs isolation between customers without inventing it from scratch.
The problem
- You're building a product where each customer gets their own AI assistant, but you don't want to run a separate process — or a separate server — per customer.
- Rolling your own tenant isolation means auth tokens, per-tenant directories, sandbox roots, quota accounting and backup — 6–8 weeks of undifferentiated plumbing before you ship a single feature.
- Get isolation subtly wrong and one customer can read another's session history. That's a launch-ending incident.
With OpenClawMU
- OpenClawMU is one gateway process that demultiplexes tenants by a SHA-256-hashed token. Every state-bearing surface — sessions, memory, plugins, sandboxes, cron, channel credentials — lives in a per-tenant directory.
- The dispatcher allow-lists 59 tenant-scoped JSON-RPC methods and refuses to route a message to the wrong tenant, even on malformed input. Path-traversal is rejected at the boundary.
- Because it's Apache-2.0 and self-hosted, you keep your margins and your customers' data on your own infrastructure — no per-seat SaaS tax underneath your product.
How it works
Getting there, step by step.
- 1
Stand up the gateway
Install the OpenClaw CLI (npm, pnpm, or Docker) and run the onboarding wizard to bring up a single gateway process on your infrastructure.
- 2
Provision a tenant per customer
Call the control-plane API (or `openclaw tenants create <name>`) when a customer signs up. Each call mints a SHA-256 token and creates an isolated tenant directory.
- 3
Scope your product's calls by token
Your app authenticates to the tenant-scoped HTTP API (OpenAI- and OpenResponses-compatible) with that tenant's Bearer token. Sessions, memory and quotas apply automatically.
- 4
Enforce plans with quotas
Set per-tenant quotas so a free-tier customer can't burn your LLM budget; upgrades are a quota change, not a redeploy.
# one gateway, many tenants
npm install -g openclaw@latest
openclaw onboard --install-daemon
# a tenant per customer / team
openclaw tenants create acmeFrequently asked
FAQ — ship a multi-tenant bot platform
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. One Node process runs the gateway; tenants are demultiplexed by token. Isolation is at the directory and sandbox level, not the OS process — so a thousand tenants don't mean a thousand processes.
Use the control-plane HTTP API for admin resource management, or shell out to `openclaw tenants create`. Both mint a token and provision the tenant directory. Wire it into your signup flow.
Related use cases
-
Run AI assistants as a service
Offer a self-hosted AI assistant as a paid product to many customers, each isolated and independently billed.
Read → -
Graduate a prototype to a product
You built a single-user assistant that works — now customers want their own, isolated and billed.
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.