OpenClaw Multi-Tenancy: Why a VM Per User Doesn’t Scale (and What Does)

If you’re running OpenClaw and thinking about giving more than one person an agent — a small team, a family, customers — you’ll quickly run into the same wall everyone else does. Vanilla OpenClaw is single-tenant. Each “user” needs their own workspace, their own configuration, their own session state. The natural workaround is one OpenClaw instance per user, usually one VM per user.

This works. It also doesn’t scale. We hit this wall while building KinthAI and ended up rebuilding the multi-tenancy layer ourselves. Here’s why “one VM per user” breaks down past a small handful of people, and what the alternative actually requires.

The “use a VM” answer is technically correct

The most common advice — and it’s not wrong — is: just give each user a VM. They get isolated state, isolated processes, isolated credentials. OpenClaw doesn’t need to know multi-tenancy exists; the operating system handles it.

For a single team of 5, this is fine. For 50, it’s painful. For 500, it doesn’t work. The reasons compound:

1. Fixed cost per user, regardless of activity A VM with enough RAM to run OpenClaw plus a model client costs roughly $5-15/month at standard cloud pricing. That’s before any LLM API costs. At 100 users, that’s $500-1500/month in pure server cost — money you’re paying whether the user logs in once a week or never.

2. Setup friction kills conversion “Sign up → use the product” is a different experience from “Sign up → wait 90 seconds while we provision a VM → SSH in → install OpenClaw → configure your providers → write a SOUL.md → run the gateway → finally talk to your agent.” The latter loses most casual users at the provisioning step. If you’re building anything consumer-facing, the per-VM provisioning model is a non-starter.

3. Stale fleet problem OpenClaw releases regularly. Plugins update. Security patches need to ship. With one instance per user, you have N versions of OpenClaw in production. Most users will never upgrade. Within a few months you have a fleet of stale, vulnerable installations and no central way to push updates.

4. Cross-tenant features are impossible The interesting features that make a multi-user platform worth using — agent marketplaces, shared skill libraries, agent-to-agent communication across tenants — don’t work in N isolated VMs. Each VM is its own island.

These four together make per-VM untenable past a small scale. You either accept the constraints (and stay small) or you build real multi-tenancy.

What “real multi-tenancy” actually requires

Building multi-tenancy on top of vanilla OpenClaw isn’t impossible, but the moving parts are non-trivial. Here’s the rough shape of what you end up needing:

Tenant identity propagation

Every request that enters the system needs a tenant_id attached at the boundary, and that ID needs to flow through every operation. OpenClaw doesn’t have first-class tenancy, so you reconstruct this from session keys, channel-adapter metadata, or whatever signal you have at the entry point.

The tricky part: every plugin, every skill, every cron job needs to be tenant-aware. If a plugin writes to a shared workspace by accident, you have a cross-tenant data leak. We ended up wrapping the OpenClaw runtime so every file system operation is rooted in /workspace/<tenant_id>/, with a guard that prevents path traversal.

Resource quotas

Without per-tenant limits, one tenant’s runaway agent loop can consume the entire system’s compute or LLM budget. You need:

• Token budgets per tenant, with the dispatcher backing off as the cap approaches
• CPU/memory caps per tenant — usually via cgroups or container limits
• API rate limits per tenant — to prevent one tenant from exhausting your provider rate limits and starving everyone else

The token budget piece is where most homegrown implementations fail. Per-agent budgets feel safer but don’t bound what the tenant can spend in aggregate. We’ve written more about this design choice in a separate post on multi-agent coordination.

Authentication and authorization

OpenClaw assumes the operator is the user. In multi-tenant mode, the operator (you) is different from the user (your customer), and the user shouldn’t be able to do operator things. You need:

• A real authentication layer (OpenClaw’s bearer-token model isn’t designed for end-user auth)
• A permission model that distinguishes platform-level operations (deploy, configure providers, install plugins) from tenant-level operations (chat, configure their own agent)
• Clear rules about which actions are gated by tenant permissions vs. platform permissions

Data isolation

Tenants must not see each other’s data. This sounds obvious but is easy to get wrong:

• Workspace files — separate roots per tenant
• Memory / learnings — per-tenant indexes (we built kinthai-self-improving-user for this specifically)
• Sessions and history — separate per tenant, never accidentally cross-listed
• Plugin state — plugins that maintain state need to be made tenant-aware, otherwise tenant A’s plugin state leaks to tenant B

Most plugins were not designed with multi-tenancy in mind. Audit each one before exposing it to multiple users.

Operational tooling

Now you need monitoring, logs, and metrics that are sliced by tenant. “What’s tenant 47 doing right now?” needs to be answerable. “Which tenant is generating most of our cost?” needs to be answerable. Without this you operate blind, and the first time something goes wrong with a paying customer you can’t diagnose it.

What this looks like in practice

If you’re considering building this yourself, the rough shape of the work is:

Layer	Effort	Pitfall
Tenant identity propagation	1-2 weeks	Easy to miss a code path; security implications
Per-tenant token budgets	1-2 weeks	Per-agent budgets are wrong; needs to be at tenant level
Container/resource limits	1 week	OS-level configuration, mostly solved
Auth layer (vs operator-as-user)	2-3 weeks	The “session vs identity” model in OpenClaw is awkward
Per-tenant plugin state	Variable	Depends on which plugins; some are hard
Operational tooling (per-tenant metrics)	1-2 weeks	Easy to under-invest; bites you later
Total	~2 months	Most of the cost is in the long tail of edge cases

Two months sounds bad until you compare it to the alternative of running 100 separate VMs forever. The breakeven point is roughly 30-50 users — below that, VMs are fine; above that, multi-tenancy starts being clearly worth it.

The managed alternative

If you don’t want to build this, several managed OpenClaw services exist:

• CrewClaw — focused on agent template deployment
• ClawAgora — bundled message-based pricing
• ClawCloud / ClawRunway / OpenClaw Cloud — focused on hosted server provisioning (these are essentially per-VM hosting, just managed; they don’t solve the multi-tenancy problem so much as automate the per-tenant provisioning)
• KinthAI — what we built; multi-tenant from day 1, with persistent memory, agent-to-agent collaboration, and a marketplace layer

The right choice depends on what you’re optimizing for:

• If you have a small team and want zero ops overhead → managed per-instance hosting
• If you want to expose OpenClaw agents to many users (employees, customers, communities) → multi-tenant managed service
• If you have specific requirements that don’t fit any of the above → build it yourself, knowing it’s a 2-month project before you’ll have something solid

Why we ended up here

We started building KinthAI because we wanted to give regular people access to AI agents that remembered them, learned from them, and could collaborate with other agents — not just have a chat interface to a model. Doing this at scale meant we couldn’t ask each user to spin up a VM and manage their own OpenClaw install. The user count would never get past our friends and family.

So we built the multi-tenancy layer above. It took roughly the two months estimated. We open-sourced the per-user learnings piece (kinthai-self-improving-user) because that one generalizes. The rest is platform code.

If you’re at the “we’re considering multi-user OpenClaw” stage, the honest answer is: it’s harder than it looks, but it’s not magic. Build it if you have a specific reason to own the stack; use a managed service if you don’t.

If you want to see what multi-tenant OpenClaw feels like as a user (rather than as a builder), you can try it for free here. $24.90/month if you want a private agent with persistent memory after the trial. We figured the easiest way to make the case for multi-tenancy was just to let people use a multi-tenant deployment and see for themselves.