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

try { if(localStorage) { let currentUser = localStorage.getItem('current_user'); if (currentUser) { currentUser = JSON.parse(currentUser); if (currentUser.id === 3861942) { document.getElementById('article-show-container').classList.add('current-user-is-article-author'); } } } } catch (e) { console.error(e); } KinthAI Posted on Apr 28 • Originally published at blog.kinthai.ai OpenClaw Multi-Tenancy: Why a VM Per User Does Not Scale (and What Does) #openclaw #multitenancy #ai #infrastructure Vanilla OpenClaw runs as a single-tenant system. One user, one instance, one VM. For a small group — 5 to 30 people — this works. Beyond 30-50 users, it falls apart. Here is why, and what actual multi-tenancy looks like. The "Use a VM" Answer Is Technically Correct You can absolutely give each user their own OpenClaw VM. It will work. But four things go wrong as you scale: 1. Predictable Costs Regardless of Usage A VM costs $5-15/month at standard cloud pricing whether the user talks to their agent daily or abandoned it after day one. At 100 users, you are paying $500-1500/month. At 1000 users, $5000-15000/month. Most of those VMs are idle most of the time. 2. Onboarding Friction Kills Conversion The setup sequence: create account → provision VM → install OpenClaw → configure provider API keys → create SOUL.md → initialize gateway. Most users drop off at the provisioning step. The gap between "I want to try this" and "I am talking to my agent" should be seconds, not minutes. 3. Maintenance Across N Installations With 100 separate OpenClaw instances, you need to push updates to all of them. Most users will never upgrade on their own. You end up with a fleet of stale, vulnerable installations and no central way to push patches. 4. Cross-Tenant Features Become Impossible Agent marketplaces, shared skill libraries, agent-to-agent communication — none of these work across isolated VMs. If Agent A lives on VM-1 and Agent B lives on VM-2, they cannot collaborate without a networking layer that defeats the purpose of isolation. What Real Multi-Tenancy Actually Requires Multi-tenancy is not "put everyone on the same server." It is five distinct engineering problems: Tenant Identity Propagation Every API call, every file operation, every memory query must carry a tenant_id. File operations must be restricted to /workspace/<tenant_id>/. Missing a single code path creates a data leak vulnerability. Resource Quotas Token budgets, CPU/memory caps, and rate limiting — all per tenant, not per agent. An agent-level budget is easy to game (create more agents). Tenant-level aggregate spending is what actually matters. Authentication and Authorization Two levels: platform operations (deploy, install plugins, manage billing) and tenant operations (chat with agent, configure personal settings). OpenClaw's session model was not designed for this distinction. Data Isolation Separate storage for: workspace files, memory indexes (vector stores), conversation sessions, and plugin state. A memory search for Tenant A must never return Tenant B's data, even if the embeddings are similar. Operational Tooling Monitoring, logging, and metrics sliced by tenant. When something breaks at 3am, you need to know which tenant is affected, not just which server. Implementation Effort Component Timeline Primary Challenge Tenant identity propagation 1-2 weeks Missing code paths = security holes Per-tenant token budgets 1-2 weeks Agent-level budgets fail; tenant aggregation required…

This excerpt is published under fair use for community discussion. Read the full article at DEV Community.