How to Run Multiple OpenClaw Instances on One Machine (and Why Containers Win)

OpenClaw is built for one user, one machine, one config directory. That works fine until you need a second instance: a separate project with different LLM providers, a dev environment alongside production, a team member who needs their own agent workspace on a shared server. The moment you try to run two OpenClaw gateways on the same host, things break in quiet, frustrating ways.

This article explains what goes wrong, compares the three common workarounds, and shows why containers are the clear winner for running multiple OpenClaw instances on one machine. If you want to skip the manual configuration entirely, Zedly Setup handles multi-instance deployments in a single session.

The Problem with Multiple OpenClaw Instances

OpenClaw assumes a single installation per machine. Its defaults reflect that: one config directory at ~/.openclaw/, one gateway port, one memory store, one cron scheduler. Running a second instance without changes creates collisions at every layer:

The core issue is shared state. OpenClaw was not designed with multi-tenancy in mind, and patching around these collisions manually is fragile. You can make it work, but every workaround adds maintenance burden and new failure modes.

Three Approaches (and Which One Wins)

There are three common strategies for running multiple OpenClaw instances on one machine. They differ significantly in isolation quality, maintenance cost, and reliability:

The first two approaches fight against OpenClaw's single-instance assumption. Containers remove the problem entirely: each container is its own machine as far as OpenClaw is concerned, with its own filesystem, its own ports, and its own process space.

Why Containers Are Best Practice for Running Multiple OpenClaw Instances on One Machine

OS-level containerization gives you everything multi-instance OpenClaw deployments need, without any of the fragility of manual workarounds:

• Complete isolation: each container has its own ~/.openclaw/, its own Node.js environment, its own installed plugins. No cross-contamination between projects.
• Resource limits: set CPU and memory caps per container. A runaway agent in one instance cannot starve the others. Docker enforces these at the kernel level.
• Independent versioning: pin OpenClaw to a specific version per container. Upgrade one project to the latest release while keeping another on a stable version that your production workflows depend on.
• Reproducible setup: your Dockerfile captures the entire installation: OpenClaw version, Node.js version, plugins, config structure. Rebuilding from scratch takes seconds, not hours.
• Clean teardown: done with a project? docker rm removes everything. No orphaned config files, no leftover cron jobs, no stale gateway processes.
• Port mapping: each container's gateway runs on the default port internally. Docker maps it to a unique host port (-p 10005:3000, -p 10006:3000). No port override hacks needed.

Containers are not just for multi-instance setups. Even if you only run a single OpenClaw instance, a container is the recommended approach. It gives you a reproducible environment that survives OS upgrades, a clean uninstall path, version pinning, and resource limits that prevent a misbehaving agent from consuming your entire machine. Starting with a container from day one means you never have to migrate later when you add a second instance.

The overhead is minimal. Each idle OpenClaw container uses roughly 80-120 MB of RAM. A standard developer machine with 16 GB can comfortably run 4-6 instances with active agents. On macOS, OrbStack runs Linux containers with near-native performance: file I/O, networking, and process startup are effectively as fast as running directly on the host. If you have been avoiding Docker on Mac because of the performance tax, OrbStack removes that objection entirely.

Getting started on a Mac takes two commands:

That gives you a fully isolated OpenClaw instance in under a minute. Need a second instance? Change the name and port:

Each container is fully independent from the moment it starts. Its own config, its own gateway, its own plugins. You can run one openclaw instance as production and the other as experimental/testing.

On Windows, WSL2 gives you the same story. Docker Desktop runs containers on a real Linux kernel under Hyper-V, so CPU, memory, and file I/O inside the container are near-native Linux speed. The same docker run command works identically.

The one thing to avoid: mounting Windows folders (like /mnt/c/) into the container. The cross-filesystem bridge is slow. Keep OpenClaw's working files inside the container where they belong, and performance matches a bare Linux install.

What a Multi-Instance Setup Looks Like

In practice, each OpenClaw instance runs inside its own container with a dedicated gateway port, config directory, and (optionally) its own Zedly Shield daemon for runtime security. A typical multi-instance deployment on one machine looks like this:

Each container has its own openclaw.json with provider keys, model routing rules, plugin configs, and memory paths. Changes to one instance never affect the others.

The Zedly Setup dashboard reflects this architecture. Each session targets one instance, whether it runs in a container or on bare metal, on macOS or Linux. The dashboard tracks every session's status, connection health, and machine type:

Notice the mix of Docker containers (with mapped ports like :18794, :18795, :18797) and native macOS instances. Several of these are running via OrbStack on Mac, where containers perform identically to bare-metal installs. The setup process is the same regardless: create a session, run the tunnel command, and the engineer configures that specific instance. For teams running budget models on some instances and frontier models on others, each container gets its own routing rules optimized for its workload.

What Zedly Setup Configures for Multi-Instance Deployments

Each Zedly Setup session targets one instance via a secure reverse SSH tunnel. For containerized deployments, the setup engineer enters each container in turn and configures it independently. Here is what gets handled per instance:

The engineer verifies each instance end-to-end before moving to the next: providers respond, the gateway starts, a test agent runs, and Shield logs the event. No instance is left half-configured.

Security Across Instances: Why Shield Matters More with Multiple Agents

Running multiple OpenClaw instances multiplies your attack surface. Each instance has its own agents with shell access, file system control, and connections to LLM providers. Without per-instance guardrails, a prompt injection or misconfigured agent in one container can exfiltrate data through its own model connection, completely independent of what the other instances are doing.

Zedly Shield runs as a local daemon inside each container, sitting between the agent and the LLM provider. Each instance gets its own security boundary:

• Per-instance PII redaction: credit card numbers, SSNs, email addresses, and phone numbers are detected and stripped before data leaves the container. Each instance's redaction rules are independent.
• Per-instance deny lists: define blocked keywords, file patterns, or topics per project. A contract analysis instance blocks client names; a dev instance blocks production database credentials.
• Per-instance audit logs: tamper-evident JSONL logs record every tool call, every policy decision, and every redaction event. Each container's log is self-contained and exportable.
• Fleet dashboard: the optional cloud dashboard aggregates events from all containers into a single view. One screen shows which instances triggered policy violations, which agents accessed sensitive files, and which redactions fired.

Without Shield, multi-instance deployments create blind spots. You might secure one instance carefully while another runs unmonitored. Per-container Shield daemons ensure every instance has the same baseline protection, regardless of who configured it or when it was created.