OpenClaw multi-tenant hosting starts with a blunt rule: one tenant trust boundary gets one Gateway. Not one shared Gateway with clever session IDs. Not one agent with tenant labels in a database. A real boundary means a separate OpenClaw instance, and Fleet calls that instance a cell.
That may sound heavier than the usual SaaS answer, but AI agents change the math. A tenant’s agent may hold provider keys, channel credentials, memory, browser access, file access, session history, and automation tools. Once those pieces sit behind the same trusted control plane, a bug is no longer just a data leak. It can become delegated action in the wrong tenant’s name.
OpenClaw’s docs take the safer position. A Gateway is a trusted operator domain. If two organizations do not share that trust, they should not share that Gateway.
OpenClaw multi-tenant hosting in plain English
In OpenClaw, multi-tenant hosting means running multiple isolated Gateway cells on the same host, usually through the `openclaw fleet` command. Each cell is a full OpenClaw Gateway in its own hardened container. It has its own state, credentials, workspace, channel accounts, Gateway token, container network, and loopback-only host port.
The important word is “full.” Fleet is not carving one OpenClaw process into tenant slices. It is supervising many complete OpenClaw instances from the host. That design is less magical and much easier to reason about when something goes wrong.
The source docs describe Fleet as experimental. Commands, flags, output shapes, and the container profile can change without a long warning period. It is tested on Linux and macOS hosts, while Windows hosts are currently untested. That matters if you are planning a hosted service: this is an operator tool you should pin, test, and document, not a black-box billing platform.
Why one shared Gateway is the wrong boundary
The common mistake is to treat sessions as tenant isolation. In OpenClaw, session IDs select routing. They do not authorize one tenant against another.
That distinction is not academic. OpenClaw’s security docs say an authenticated operator inside one Gateway has a trusted control-plane role. In the default trust model, tool-enabled agents and session tools are built for a trusted operator or a mutually trusting team. They are not meant to keep hostile customers apart inside the same process.
This is where many “multi-tenant AI agent” designs get too cute. They start by sharing the expensive parts: one process, one control plane, one channel adapter, one scheduler, one memory service. Then they try to rebuild isolation inside the application with tenant IDs, filters, scopes, and prompt instructions. That can work for ordinary SaaS features. It is a shaky answer for agents with tools.
A prompt-injected message, a mis-scoped session read, or a badly placed admin tool should not be able to cross into another customer’s world. The cleanest way to get there is not a better label. It is a separate Gateway process with separate persistent state and separate credentials.
What a Fleet cell actually isolates
A Fleet cell is a complete OpenClaw instance. The container runs the official `ghcr.io/openclaw/openclaw` image by default, and the Gateway listens on port `18789` inside the container. The host publishes that Gateway only to `127.0.0.1:<allocated-port>`, so it is not accidentally exposed on every interface.
Fleet also gives each cell its own user-defined bridge network. Separate bridges stop direct container-IP traffic between cells while keeping outbound NAT available for providers and chat channels. That is a sensible baseline. It reduces accidental cross-cell chatter without pretending that one Linux host has become a separate company.
State is separate too. A tenant’s mounted Gateway state lives under a per-cell directory such as `<state-dir>/fleet/cells/<tenant>/`. That state includes sensitive material. The docs warn that current OAuth access, refresh, and ID-token values are stored as plaintext in SQLite under the ordinary state mount. In plain English: treat cell backups like credentials.
Each cell has its own channel accounts. Fleet does not provide a shared WhatsApp, Telegram, Slack, or other channel account that routes inbound messages to tenants. That missing feature is a feature in disguise. A shared ingress layer would need a real identity and authorization model. Without one, it would be a shortcut through the tenant wall.
The isolation ladder
The docs give operators a useful ladder. Start with the baseline, then move up when your tenant risk changes.
1. Hardened container baseline
The default Fleet profile drops Linux capabilities, uses `no-new-privileges`, applies PID, memory, CPU, and optional writable-layer disk limits, gives each cell separate mounts and networks, and publishes only to loopback. The Fleet CLI reference shows defaults such as `2g` memory, `2` CPUs, and a PID limit of `512` for new cells.
This baseline is a good fit when tenants trust the host operator and the operator trusts the workload enough to run it in containers. It is not magic. Bridge networking leaves outbound egress open by default. Podman cells can use `–network internal` to block egress while preserving the loopback Gateway port. Docker internal networks break that published port, so OpenClaw rejects that combination and points operators toward host firewall policy such as Docker’s `DOCKER-USER` chain.
2. Stronger container or VM isolation
For higher-risk tenants, Fleet can sit on top of stronger runtime choices. Docker documents alternative runtimes through containerd shims, including gVisor and Kata Containers. OpenClaw’s docs are careful here: `–runtime docker|podman` chooses the container CLI, not the lower-level OCI isolation backend. If you want gVisor, Kata, or a microVM setup, that is host runtime work.
This rung is for the uncomfortable middle: tenants belong on the same machine for cost or operational reasons, but the plain container boundary does not feel like enough. The price is complexity. You now own runtime compatibility, image behavior, logging, upgrades, and failure cases under that stronger runtime.
3. Separate machines for hostile tenants
When tenants do not trust the same host operator, stop trying to squeeze them into one host. OpenClaw’s docs say the host and Fleet operator are trusted by every tenant. A host administrator can inspect container config and environment, read mounted cell data, replace images, or enter containers. Gateway tokens and `–env` values are visible to an administrator through Docker or Podman inspection.
That is not a flaw in Fleet. It is the truth about who owns the machine. If the host operator is outside the tenant’s trust boundary, use separate VMs, separate hosts, or a provider-managed boundary that matches the risk.
How to create and operate a tenant cell
The quick start is simple:
openclaw fleet create acme
openclaw fleet status acme
openclaw fleet list`fleet create` prints the generated Gateway token once along with the local cell URL. Store that token immediately. Then open the reported `http://127.0.0.1:<port>` URL on the Fleet host, authenticate with that tenant’s token, and configure provider credentials and channel accounts inside that tenant’s cell.
Tenant IDs are intentionally boring. The Fleet CLI accepts 1 to 40 lowercase letters, digits, and internal hyphens. No uppercase letters. No underscores. No slashes, dots, whitespace, or traversal strings such as `../acme`. That ID becomes part of the container name: `openclaw-cell-<tenant>`.
Upgrades preserve the important tenant pieces: the same host port, mounted data, resource profile, user-supplied environment, restart policy, and Gateway token. A replacement is committed only after the new Gateway answers `/healthz`; if the new container fails, Fleet restores the previous one. That is the right bias for hosted infrastructure. A bad image should not casually take down a working tenant.
Backups are equally serious. Fleet backs up one stopped cell at a time, creates archives with restrictive file mode, and treats restore as an operator-privileged action. Since cell state can include tokens, backup archives are not “just data.” Store them like secrets.
What Fleet does not do yet
Fleet is a single-host lifecycle supervisor. It creates, inspects, starts, stops, replaces, backs up, restores, and removes local cells through Docker or Podman. It does not become a SaaS control plane.
The docs are clear about the missing surfaces:
- No shared channel account or shared ingress router.
- No slim per-tenant host process instead of a full OpenClaw instance.
- No remote cell hosts managed by one supervisor.
- No tenant self-service portal, billing plane, or delegated admin UI.
That list is useful because it keeps operators honest. A shared ingress router, for example, sounds like a convenience feature until you list what it needs: identity, routing, authorization, replay handling, channel ownership, error isolation, and audit logs. Without those contracts, “shared” means “easy to get wrong.”
How this compares to broader multi-tenancy advice
Kubernetes frames multi-tenancy as a spectrum. Sharing can cut cost and simplify operations, but it creates security, fairness, and noisy-neighbor problems. For hard multi-tenancy, Kubernetes points operators toward stronger data-plane isolation and, in more extreme cases, dedicated clusters or hardware.
OpenClaw lands in the same practical camp, but at the agent layer. Namespaces, quotas, and network policies are good platform tools. They do not change OpenClaw’s application trust model. One Gateway is still one trusted operator domain.
OWASP ASVS is another useful lens. It gives teams a way to verify application security controls. But verification starts from the design you actually have. If the design says multiple hostile tenants share one control plane, every auth check and audit rule has to prove that boundary. OpenClaw avoids that fight by making the Gateway cell the boundary.
Practical checklist before hosting customers
Before you host another organization on OpenClaw, run through this list:
- Map one tenant trust domain to one Fleet cell.
- Keep the cell URL bound to loopback unless an approved reverse proxy, SSH tunnel, or tailnet is in front of it.
- Store the generated Gateway token immediately after `fleet create`.
- Configure provider keys and channel accounts inside the tenant’s own cell.
- Treat the cell state directory and backups as credential-bearing material.
- Set memory, CPU, PID, and disk policy deliberately instead of accepting density guesses forever.
- Decide whether outbound egress should be open, blocked with Podman internal networking, or governed by Docker host firewall rules.
- Use stronger runtimes or separate machines when tenants or workloads deserve it.
- Run `openclaw security audit` on exposed or changed deployments.
- Document what the Fleet operator can see and do. The host admin is trusted by design.
The last point is the one teams most often avoid saying out loud. If you are the host operator, you can see a lot. Do not sell Fleet as protection from you. Sell it as protection between tenants who trust your host boundary.
Who should use OpenClaw multi-tenant hosting?
Fleet makes sense for agencies, consultants, internal platform teams, and small hosted-agent providers who need to run several OpenClaw deployments on one machine without mixing tenant state. It is also a clean way to give departments, clients, or experiments their own Gateway without building a private platform from scratch.
It is not the right answer if tenants need full administrative separation from the host operator. It is also not a finished SaaS layer. There is no customer portal, billing system, shared inbound router, or delegated tenant admin surface. You can build those around it, but you should not pretend Fleet already did that work.
That is the trade-off. Fleet gives you a clear, inspectable unit: one cell, one tenant, one Gateway, one set of credentials, one local port. Boring boundaries age better than clever ones.
FAQ
Can I host multiple tenants inside one OpenClaw Gateway?
You can host multiple trusted users or personas inside one Gateway, but that is not hostile tenant isolation. For organizations or users that do not share a trust boundary, the docs say to run a separate Gateway cell per tenant.
Does a session ID protect one tenant from another?
No. OpenClaw treats session IDs as routing selectors, not authorization tokens. Do not use session naming as a security boundary.
Does Fleet encrypt tenant state?
No. The docs say current OAuth token values are stored as plaintext in SQLite under the normal cell state mount. Protect state directories and backups as secrets.
Can Fleet manage remote Docker or Podman hosts?
No. Fleet expects a local Docker or Podman endpoint because its bind paths and loopback URLs belong to the local host.
Should I use Docker or Podman?
Use the runtime your host operations already support. Podman has a useful internal network option for blocking egress while preserving the loopback Gateway port. With Docker, keep bridge networking and enforce outbound policy with host firewall rules when needed.
When should I move tenants to separate machines?
Move when tenants do not trust the same host operator, when the workload is hostile, or when regulation, contracts, or incident response require a stronger administrative boundary than one shared host can provide.
Bottom line
OpenClaw multi-tenant hosting is conservative in the best sense. It does not ask operators to believe that prompt discipline, session labels, or app-level filters can replace a real trust boundary. Each tenant gets a Gateway cell. The host operator remains trusted. Stronger isolation is available, but it belongs in the runtime or infrastructure layer.
If you are planning to host agents for customers, start there. Make the boundary boring, visible, and easy to destroy or restore one tenant at a time. Then build the nicer product layers around it.
AI visual disclosure: the featured image for this post was generated with an AI image model and reviewed before upload.
