How to Run Multiple OpenClaw Gateways

Running more than one OpenClaw gateway is absolutely supported, but the docs are blunt about something many operators miss: most people should still use one gateway. Multiple gateways are for stronger isolation, redundancy, or a rescue-bot lane, not for aesthetic neatness.

When this is the right move

Use multiple gateways when you truly need profile isolation, different workspaces or tenants, or an independent rescue bot that can still help when the main gateway is broken. If your goal is simply “more features,” one well-run gateway is usually the cleaner answer.

The practical workflow

The safest path is the rescue pattern the docs recommend, then a broader multi-gateway layout only if you really need it.

1. Decide whether you are building a rescue bot or a general multi-tenant layout. The rescue pattern is the documented default because it solves the most common real need.
2. Give every extra gateway its own named profile and its own base port. The docs repeatedly tie isolation to profiles, ports, and derived service ranges.
3. Keep state, config, and workspace paths unique. A different port with a shared state directory is still a collision waiting to happen.
4. Use a separate Telegram bot for the rescue profile if you follow the recommended rescue-bot design. The docs call that out as the simplest operator-only recovery path.
5. Verify each instance separately with deep status or probe commands before you assume the host is healthy.

Grounded command or config pattern

The docs offer a concrete rescue-bot quickstart plus a manual environment example. Use those patterns instead of improvising your own isolation rules.

openclaw --profile rescue onboard
openclaw --profile rescue gateway install --port 19789

OPENCLAW_CONFIG_PATH=~/.openclaw/main.json OPENCLAW_STATE_DIR=~/.openclaw openclaw gateway --port 18789

OPENCLAW_CONFIG_PATH=~/.openclaw/rescue.json OPENCLAW_STATE_DIR=~/.openclaw-rescue openclaw gateway --port 19789

The numbers matter because derived browser and CDP ranges follow the base port. That is why the docs recommend leaving at least about twenty ports between instances.

Operator notes

This is less about “more gateways” than about trust boundaries. A rescue bot with its own profile, workspace, token, and port can stay useful even when the main lane is broken. That is operationally very different from two gateways that only look separate because someone changed one command-line flag.

Rollout approach

For running multiple OpenClaw gateways on one host, start with one owner, one environment, and one reversible test. Prove the docs-grounded path works before you widen the blast radius.

Common mistake

The common mistake is isolating only the obvious thing. People remember the port, then forget the state directory or workspace. The docs are clear that config, state, workspace, and derived ports all need unique ownership if you want reliable separation.

Maintenance rhythm

Record the command, config path, auth assumption, and verification step in your runbook. Maintain a tiny table that maps profile names to ports, workspaces, state paths, and bot identities. That table becomes priceless the first time you debug the wrong instance at 2 AM.

Safety checks

Do not introduce multiple gateways just because you can. Every extra instance adds more operator surface, more auth, more logs, and more chances to point at the wrong thing. If you do need it, keep the separation strict enough that a broken main gateway does not drag the rescue lane down with it.

How to verify it worked

After setup, run the relevant status and probe checks against both the main and extra profile. Confirm each gateway is reachable on its own port, that the intended workspace is attached, and that the rescue lane really uses its own bot identity instead of piggybacking on the main channel credentials.

If verification feels ambiguous, stop there and tighten the setup before you automate more. A small clean proof beats a large confusing rollout.

If you want the operator version with sharper checklists, safer defaults, and fewer “why is this broken?” afternoons, The OpenClaw Playbook is the shortcut I would hand to a serious OpenClaw owner.