How to Host OpenClaw for Multiple Clients in Production

The first OpenClaw deployment is usually straightforward.

You provision a machine, configure one agent, connect a few tools, and watch it complete a real task. If something breaks, you inspect the logs, fix the configuration, and restart the process.

That is a valid way to prove the use case. It is not yet a production architecture.

The category changes when an agency, SaaS company, consultant, or internal platform team needs to run OpenClaw for multiple clients. Every agent now belongs to a tenant, holds state, uses credentials, controls browser sessions, changes files, and can create external side effects. A failure is no longer just a failed process. It can become a missed client task, a duplicated email, a corrupted workspace, or an access-control incident.

The right question is therefore not, "How many OpenClaw containers can this server run?"

It is, "How many client environments can our team operate safely, recoverably, and without adding one human babysitter for every few agents?"

This guide presents a practical architecture and deployment checklist for answering that question.

Start with the correct unit of architecture

Do not model an OpenClaw fleet as a list of processes. Model it as a list of client cells.

A client cell is the complete operating boundary for one tenant or one agent. It includes:

• the OpenClaw process and its configuration;
• its resource envelope: reserved and maximum RAM, CPU cores, burst allowance, and priority;
• the persistent workspace and task artifacts;
• credentials and integration permissions;
• browser profiles, cookies, and active sessions;
• email, phone, or chat identity;
• logs, events, and audit history;
• recovery policy and human owner.

This distinction matters because a process can be healthy while the client cell is broken. The daemon may still respond, but its CRM credential has expired. The container may be running, but the browser session is stuck behind a login prompt. The agent may have restarted successfully, but its workspace contains a bad configuration from the previous run.

A useful mental model looks like this:

Fleet control plane
  |
  +-- Client A cell
  |     +-- OpenClaw runtime
  |     +-- RAM and CPU envelope
  |     +-- workspace and versions
  |     +-- scoped credentials
  |     +-- browser session
  |     +-- communication identity
  |     +-- recovery policy
  |
  +-- Client B cell
  |     +-- same boundaries, different state
  |
  +-- Client C cell
        +-- same boundaries, different state

Shared infrastructure can still be efficient underneath. The important requirement is that ownership, state, access, recovery, and resource allocation remain explicit at the client-cell level.

1. Isolate more than compute

Giving each client a separate container is a start, but container separation alone is not a complete tenant boundary.

For each client, identify everything that must not leak into another environment:

• files and generated artifacts;
• long-term memory and task context;
• environment variables and secrets;
• OAuth connections and API tokens;
• browser profiles, cookies, downloads, and local storage;
• logs and task transcripts;
• email addresses, phone numbers, and chat accounts;
• queues, schedules, and webhooks.

Then define the lifecycle of that boundary. How is it created? Who can inspect it? How is access revoked? What happens when the client leaves? Can the environment be exported, archived, or destroyed without affecting another tenant?

Isolation also includes resource behavior. If one agent enters a loop or consumes memory aggressively, it should not starve every neighboring agent on the same node. Resource guarantees and limits belong inside the tenant boundary, not in a separate spreadsheet that operators remember only during an incident.

The test is simple: one client's bad task, bad credential, or resource spike should remain that client's incident.

2. Give every client cell a RAM and CPU envelope

OpenClaw workloads are rarely flat. An agent can sit mostly idle, then open several browser tabs, process files, run local tools, and consume a burst of memory and CPU. If every client is sized only from average usage, simultaneous bursts turn a healthy shared node into a noisy-neighbor incident.

Define a resource envelope for every client cell:

Control	Purpose
Reserved RAM	Memory capacity the cell can rely on during normal operation
Maximum RAM	Hard ceiling that prevents one cell from exhausting the node
Reserved CPU	Guaranteed share of CPU time, expressed as cores or millicores
Maximum CPU	Burst ceiling that protects neighboring cells from sustained saturation
Concurrency budget	Maximum number of heavy browser or tool tasks allowed at once
Priority class	Which workloads keep capacity when the node is under pressure
Pressure policy	Whether to throttle, queue, restart, reschedule, or evict the cell

Why one fixed VM per client is the easy answer, not necessarily the efficient one

The obvious deployment model is one virtual machine per client. The isolation boundary is easy to understand, the client has a fixed number of cores and a fixed amount of RAM, and an incident inside one VM is less likely to consume another client's allocation.

That simplicity has a cost. You must size every VM for the client's likely peak, not its average. A small VM looks economical until an agent opens several browser tabs, runs local tools, or processes a large file. A larger VM survives the burst, but good VMs with enough RAM and CPU are expensive, and most of that paid capacity sits idle between tasks. Across dozens of clients, the fleet becomes a collection of separately billed safety margins that cannot help one another.

A fixed-size VM also creates a hard local ceiling. Even if the physical cluster has idle RAM and cores elsewhere, that agent cannot normally use them without a resize, migration, or a different instance type. The cheap VM is easy to exhaust; the comfortable VM is expensive to leave idle.

This is why a shared pool with controlled overcommit can paradoxically deliver better effective performance than one fixed VM per agent. "Overcommit" sounds like giving every tenant less, but well-managed overcommit does something more useful: it gives each client cell a guaranteed reservation while allowing short bursts into capacity that other agents are not using. Bursty workloads can borrow from the pool instead of hitting a fixed VM ceiling.

That benefit exists only when the platform is disciplined. Controlled overcommit needs admission control, real node headroom, per-cell minimums and maximums, workload priorities, continuous telemetry, and the ability to throttle, queue, move, or evict workloads before pressure becomes an outage. Unmanaged oversubscription is simply a noisy-neighbor problem with better marketing.

The practical choice is therefore not "VMs or no isolation." It is fixed, stranded capacity per client versus isolated client cells scheduled across a larger resource pool with explicit guarantees and controlled burst capacity.

RAM and CPU need different policies.

CPU is compressible. When several agents compete for cores, they usually become slower before they fail. CPU limits and scheduling weights can preserve fairness, but sustained saturation still increases task latency and recovery time.

RAM is not compressible in the same way. When memory is exhausted, the kernel or runtime must reclaim memory or terminate something. That means every node needs unused headroom, and every cell needs a maximum. A fleet scheduler should reject or move new workloads before the node reaches the point where the operating system chooses what dies.

A simple capacity rule is:

usable node capacity = physical capacity - system reserve - failure headroom

admit a new client cell only if:
sum of reservations + required burst headroom <= usable node capacity

Do not allocate 100 percent of physical RAM or cores to tenants on paper. Keep capacity for the operating system, fleet supervision, recovery work, and traffic spikes. Otherwise the platform has no room to repair an agent at the exact moment the fleet is under pressure.

Measure real usage by workload type, not only fleet-wide averages. A browser-heavy research agent, a messaging agent, and a code agent can have very different RAM, CPU, and concurrency profiles. Track median usage, high-percentile bursts, restart frequency, throttling time, and out-of-memory events for each profile. Then adjust reservations and limits from evidence.

The control plane should show both allocation and consumption per cell. Operators need to see:

• reserved versus used RAM;
• reserved versus used CPU;
• throttling and queue time;
• active browser and tool concurrency;
• recent memory-pressure or out-of-memory events;
• which node hosts the cell and how much headroom remains;
• whether the cell should be resized or moved.

This turns capacity management into a normal fleet operation. Without it, teams discover their true density only when several clients become busy at once.

3. Separate durable state from disposable runtime

An OpenClaw process should be replaceable. The client state around it should not disappear when it is replaced.

List the state that must survive a restart or redeployment:

• configuration;
• workspace files;
• task inputs and outputs;
• browser downloads;
• integration references;
• checkpoints and approval state;
• the last known task position.

Store that state outside the lifecycle of the running process. Then make important workspace changes inspectable and reversible.

Persistence alone is not enough. If an agent overwrites a client file with incorrect data, reliably persisting the bad file does not help. Operators need version history, diffs, restore points, and a clear link between a task and the changes it produced.

For every production workspace, you should be able to answer four questions:

1. What changed?
2. Which agent action changed it?
3. What was the last known-good state?
4. Can we restore that state without rebuilding the environment?

This is also why "restart the container" is not a complete recovery plan. A fresh process can immediately load the same corrupted state and fail again.

4. Treat identities and tools as production dependencies

An autonomous agent does useful work through systems outside itself. Its effective runtime includes every browser session, integration, inbox, and phone number it depends on.

Create an identity map for every client cell:

Identity type	Questions to answer
App credentials	Which tenant owns them? What scopes are granted? How are they revoked?
Browser profile	Where is session state stored? What happens when login expires?
Email identity	Can the agent send, receive, and be audited independently?
Phone or SMS identity	Who owns the number? How are calls, SMS, and 2FA events routed?
Human approver	Who receives an escalation, and how much context do they get?

Use the least privilege that still allows the workflow to succeed. An agent that drafts a client email does not automatically need permission to send it. An agent that reads a CRM may not need record-deletion rights. A browser worker that downloads reports should not inherit access to unrelated admin pages.

Also decide what happens when a dependency becomes unavailable. If an OAuth token expires, the task should move into a known blocked state. It should not retry indefinitely or silently switch accounts. If a website requests manual verification, the agent should create a handoff with the target page, task goal, previous actions, and expected next step.

For workflows that use websites without APIs, browser state is infrastructure. Monitor it and recover it accordingly.

5. Define recovery by side effect, not by error code

The hardest recovery question is not whether a failed step can run again. It is whether it is safe to run again.

Classify operations before production:

Operation	Typical recovery policy
Read a page or fetch a record	Retry with backoff
Generate a local draft	Retry or regenerate
Modify a versioned workspace file	Restore or retry from checkpoint
Submit a form	Verify whether submission occurred before retrying
Send an email or message	Require an idempotency record or human review
Delete data or change billing	Stop and require explicit approval

This policy should live with the task, not in an operator's memory.

Record an idempotency key or external-action receipt for actions such as sending messages, creating tickets, updating customer records, or submitting forms. After a crash, recovery can check whether the external action already happened before repeating it.

The recovery flow should usually follow this order:

1. Detect that progress has stopped or a dependency has failed.
2. Capture the last known task state and external side effects.
3. Decide whether retry, resume, rollback, or escalation is safe.
4. Restore runtime or workspace state if required.
5. Continue from a checkpoint, not blindly from the beginning.
6. Attach a concise post-mortem to repeated failures.

Process monitoring tells you that something stopped. Task-aware recovery tells you what can safely happen next.

6. Build fleet operations before the fleet becomes large

The time to design fleet controls is before you have a wall of nearly identical terminals.

At minimum, your control plane should let an operator:

• create and destroy a client cell;
• see its owner, version, region, and current health;
• inspect recent task events and workspace changes;
• pause external actions without deleting state;
• rotate or revoke integrations;
• restore a known-good workspace version;
• restart or recreate the runtime;
• transfer a task to a human;
• export or offboard a tenant cleanly.

Health should be more specific than "process running." Track at least four layers:

• infrastructure health: compute, memory, storage, and network;
• runtime health: OpenClaw process and configuration;
• dependency health: browser, integrations, and communication channels;
• task health: progress, repeated failures, and unresolved human approvals.

A running VM is not a functional agent

This requirement does not disappear if every client has a dedicated VM. A cloud provider can report the VM as online while the OpenClaw process is dead, the configuration is corrupted, a browser is stuck at login, a credential has expired, an integration is returning errors, or the agent is looping without completing work.

Treat health as four separate questions:

1. Is the infrastructure available?
2. Is the OpenClaw runtime alive and correctly configured?
3. Are the browser, credentials, integrations, and communication channels usable?
4. Is the agent making valid progress toward its assigned task?

The first question is VM monitoring. The other three require agent-aware observability.

Define service objectives for each layer. A 99.9 percent VM or process uptime number is not meaningful if tasks can remain stuck for hours without detection. Useful monitoring needs functional checks, dependency status, task-progress events, side-effect records, and alerts that include enough context for recovery or human handoff.

VMs can provide a compute and isolation boundary. They do not provide operational proof. Whatever deployment model you choose, you still need the full observability and recovery layer around the agent.

Infrastructure health should include scheduling pressure, not just raw utilization. Alert on shrinking node headroom, repeated CPU throttling, cells approaching their RAM ceilings, and failed admission attempts before customers experience a fleet-wide slowdown.

7. Upgrade in rings, not across the whole fleet

Multi-client hosting creates version drift. Some clients need stability, some need a new capability, and some have workflows that depend on old behavior.

Avoid a single fleet-wide "latest" setting. Track the OpenClaw version and configuration version for every client cell, then upgrade in rings:

1. internal test agents;
2. low-risk pilot clients;
3. a small production cohort;
4. the remaining fleet.

For each ring, define success signals, rollback conditions, and observation time. Keep the previous workspace and configuration available until the cohort is stable.

An upgrade is not complete because the process started. It is complete when the agent can still authenticate, use its tools, load its workspace, execute a representative task, and recover from a controlled failure.

This staged approach turns upgrades from a fleet-wide gamble into a reversible operation.

8. Make human handoff a first-class state

Human handoff should not mean, "Something failed, please investigate."

A useful handoff package contains:

• the client and agent identity;
• the original task goal;
• the last successful step;
• external actions already taken;
• current browser or integration state;
• relevant files and diffs;
• the exact decision or manual action required;
• the safest recommended next step.

Treat waiting for a human as a normal task state with an owner and deadline. That prevents blocked work from being mistaken for healthy idle time.

It also protects margins. A fleet that constantly needs context reconstruction does not scale even if every agent technically runs on the same server.

9. Decide what to build and what to buy

Self-hosting can be the correct choice. If you have a small internal deployment, low availability requirements, and a platform team that wants full control, a VPS or container platform may be enough.

For a multi-client fleet, "one VM per customer" should be costed honestly. Include the capacity reserved for peaks but paid for while idle, the operational work of resizing and migrating instances, and the observability layer still required above the VM. The VM bill is not the cost of an operational agent. It is only the cost of its machine boundary.

The build decision changes when agents serve paying clients, operate around the clock, use sensitive credentials, or require browser sessions, dedicated identities, recovery, workspace versioning, and deployment across different environments.

Estimate the ownership cost of the whole client cell, not only the compute bill. Include:

• on-call and incident response;
• tenant provisioning and offboarding;
• workspace backup and restore;
• browser and integration maintenance;
• secret rotation and access reviews;
• fleet dashboards and lifecycle APIs;
• safe upgrades and rollback;
• customer support created by downtime.

If those capabilities are core intellectual property, building them may be justified. If they are support infrastructure around the product you actually sell, a managed OpenClaw environment can remove a large amount of undifferentiated work.

One example is Molted's managed OpenClaw hosting, which combines fleet recovery, versioned workspaces, browser automation, app integrations, per-agent email and voice identity, lifecycle controls, and managed cloud or on-premise deployment. The relevant comparison is not Molted versus a single VPS line item. It is a managed client-cell operating layer versus owning that layer yourself.

Production checklist

Before onboarding a second client, verify the architecture can answer all of these questions.

Tenant boundary

• Does every client have isolated files, credentials, memory, browser state, logs, and communication identities?
• Does every client cell have documented reserved and maximum RAM and CPU?
• Can one client's resource spike or broken task affect another client?
• Is there enough node headroom to absorb simultaneous bursts and recovery work?
• Are concurrency, throttling, rescheduling, and eviction policies explicit?
• Can a tenant be exported, revoked, and destroyed cleanly?

State and recovery

• Does important state survive a process or node replacement?
• Are workspace changes versioned and attributable to a task?
• Can operators restore a known-good state after a bad edit or delete?
• Does recovery distinguish safe retries from irreversible external actions?

Tools and identity

• Are credentials scoped per tenant and per required capability?
• Are browser sessions monitored as dependencies?
• Does each agent have the correct email, phone, or chat identity?
• Is there a defined process for expired login sessions and human verification?

Fleet operations

• Can operators see infrastructure, runtime, dependency, and task health separately?
• Does monitoring prove that the agent is functional and progressing, not merely that its VM and process are online?
• Can they see resource reservations, live consumption, throttling, and node headroom per client cell?
• Can they pause actions, inspect state, recover an instance, and hand work to a human?
• Are OpenClaw and configuration versions tracked per client cell?
• Are upgrades staged with explicit rollback criteria?

Business operations

• Who owns after-hours incidents?
• What response time has been promised to clients?
• Are you paying for peak-sized VMs that remain mostly idle between agent tasks?
• How many agents can the current team support without adding manual operators?
• Which parts of the run layer are strategic enough to build internally?

Final takeaway

Hosting OpenClaw for multiple clients is not mainly a VM or container-count problem. It is an operating-model problem.

The production unit is the client cell: runtime, RAM and CPU envelope, state, credentials, browser sessions, communication identity, recovery policy, and human ownership. Once those boundaries are explicit, teams can share infrastructure efficiently without sharing failures.

Build the architecture around recoverable client environments, not disposable processes. That is what turns a successful OpenClaw demo into a service customers can rely on.

---

Disclosure

Kylian Cros is co-founder and CMO/GTM at Molted. Molted provides managed operating environments for autonomous agents, including OpenClaw-based fleets.