Multi-tenant OpenClaw, explained

What multi-tenant OpenClaw means

Multi-tenancy is one platform serving many separate customers, where each tenant's agents, data and credentials are isolated from every other tenant's. It is what you need the moment you stop running agents for yourself and start giving an agent to each client, each team or each employee.

This is different from multi-agent. Running several agents on one install is a multi-agent setup, and they are usually all yours. Multi-tenancy adds a hard requirement: tenant A must never see, reach or destabilise tenant B.

Why OpenClaw is single-tenant by default

OpenClaw was built to be your own personal agent on your own machine. One gateway, one workspace, one set of credentials, full trust. That design is exactly why it is so good for a single owner, and exactly why multi-tenancy is not something you flip on.

There is an open, much-discussed request for native multi-tenant and multi-agent support on a single gateway, and a handful of community projects that bolt a platform layer (container isolation, encrypted vaults, team sharing) on top. The fact that those projects exist tells you the base runtime leaves the tenancy problem to you.

The DIY routes, and where they stop

Teams usually reach for one of three do-it-yourself approaches, and each runs into the same wall.

• A container per tenant: clean isolation, but now you operate orchestration, recovery and memory limits for every container, and costs climb to one heavy server per customer.
• A separate gateway per tenant: simple to reason about, expensive to run and update, and you still hand-roll provisioning, monitoring and billing.
• One shared gateway with an encrypted vault and routing: cheap, but a single bug or memory spike can leak across tenants or take several down at once.

The four hard parts of multi-tenancy

Whichever route you pick, the same four problems decide whether the platform survives contact with real customers.

• Isolation: one tenant's agent must never read another's files, secrets or memory, even when they share hardware.
• Secret management: every tenant brings its own model keys and app credentials, which must be stored encrypted and never exposed to other tenants or to the agent's host.
• Noisy neighbours: agents spike in RAM, so running many tenants on shared capacity is what makes the economics work, and also what crashes a machine if nothing protects it.
• Per-tenant billing and observability: you need to meter, bill, monitor and recover each tenant independently, not as one undifferentiated blob.

Multi-tenancy as managed infrastructure

This is the layer Molted is built to be. It runs OpenClaw as multi-tenant infrastructure: per-tenant isolation, encrypted per-instance secrets that never sit inside the agent itself, per-agent resource limits and self-healing that catches a crash in under 60 seconds, with 90% resolved before the client notices. On top sits a white-label, multi-tenant dashboard and a REST API, so you can hand each customer their own agent under your brand.

The same team runs molted.cloud, where this serves 300+ clients, in the cloud or on-premise. If you are wrapping, reselling or rolling out OpenClaw to many people, multi-tenancy is the part you do not want to build twice.