Multiple Gateways

Running multiple gateways is a bit like adding a fire escape to a building. Most days you ignore it. On the day the main stairwell fills with smoke, you are very glad it exists.

That is the real use case. Not vanity. Not architecture cosplay. Just controlled isolation when one OpenClaw gateway is not enough.

The current official docs make the default pretty clear: most people should run one gateway per machine. One gateway can already handle multiple channels and agents. You only split it when you want redundancy, stronger separation, or a rescue bot that can still reach the system when the main lane is broken.

When multiple gateways make sense

Use a second gateway on purpose, not by accident. The strongest cases are:

• Rescue bot: a fallback operator path that stays alive if the main gateway or main bot configuration breaks
• Operational isolation: separate workspaces, state, and profiles for different teams or roles
• Channel separation: keeping one gateway for customer-facing traffic and another for internal ops
• Tenant separation: when shared state would be messy or risky

If your real reason is just, “I have two bots,” stop there. One gateway can usually handle that already.

The rescue-bot setup is the best default

The OpenClaw docs recommend a simple pattern for most multi-gateway setups: keep your main gateway on the default profile, then create a separate rescue profile with its own Telegram bot and a different base port.

This is the part many people miss. A rescue bot is only useful if it is actually independent. If it shares the same profile, state directory, token, and ports, it is not a rescue path. It is the same staircase painted a different color.

In practice, the rescue gateway gets its own:

• profile and config file
• state directory
• workspace root
• base port and derived browser ports
• Telegram bot identity

What must stay unique per gateway

This is the non-negotiable checklist. Each gateway instance needs its own isolated values for:

• OPENCLAW_CONFIG_PATH
• OPENCLAW_STATE_DIR
• agents.defaults.workspace
• gateway.port or the port you pass with --port
• derived browser control and CDP ports

Share any of those and weird things start happening. Config races. Port collisions. One instance stepping on another instance’s browser state. None of it is fun.

Why port spacing matters

Current OpenClaw docs recommend leaving at least 20 ports between gateway base ports. That sounds fussy until you remember the gateway also derives browser and CDP ports from the base port.

Think of the base port as the first domino in a short line. If you place two domino lines too close together, you do not have two systems. You have a shared accident.

Example layout

A clean two-gateway layout might look like this:

# Main gateway
openclaw setup
openclaw gateway --port 18789

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

The exact onboarding prompts can vary with your setup, but the pattern stays the same: different profile, different bot, different port range.

Manual environment separation

If you prefer explicit environment control, OpenClaw also supports separating instances by config path and state directory directly:

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

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

This makes the isolation obvious. It also makes mistakes easier to spot when you come back three months later and wonder what past-you was thinking.

How gateway lock behavior helps you

OpenClaw has a gateway lock mechanism specifically to stop two instances from fighting over the same base port on one host. On startup it checks the lock state and the port listener, then fails fast if another process is already in control.

That is a good thing. If you ever see a lock or EADDRINUSE-style conflict, the system is warning you before silent corruption gets a turn.

Useful checks after setup

After you install a second gateway, verify the layout instead of assuming it worked:

openclaw gateway status --deep
openclaw --profile rescue gateway status --deep
openclaw --profile rescue gateway probe
openclaw status
openclaw --profile rescue status

According to the current docs, it is normal for probe output to warn about multiple reachable gateways when that is exactly what you intended. The key question is not whether OpenClaw notices both. The key question is whether both are isolated cleanly.

Common mistakes

1. Splitting too early

Some operators reach for multi-gateway layouts before they have a stable single-gateway setup. That is like adding a backup cockpit to a plane with loose bolts. Stabilize the basics first.

2. Reusing the same bot identity

A rescue gateway should not depend on the same Telegram bot as the main gateway. If the main bot path is broken, your rescue lane may be broken too.

3. Forgetting workspace separation

Separate ports are not enough. If both gateways point at the same workspace and state, isolation becomes mostly decorative.

4. Pinning browser or CDP settings the same way twice

The docs call this a common footgun for a reason. If you manually pin identical browser control or CDP values on two instances, you can create conflicts even when the main gateway ports differ.

One gateway vs multiple gateways

Use one gateway when you want simplicity, shared control, and fewer moving parts. Use multiple gateways when you deliberately need fault isolation, separate operator paths, or cleaner tenancy boundaries.

If you are unsure, stay with one gateway. Simpler setups fail in simpler ways.

Summary

Multiple gateways are not the normal OpenClaw path. They are the advanced path for people who know exactly what problem they are solving.

If that problem is real, the answer is simple: isolate everything that matters, keep ports well separated, give the rescue lane its own identity, and verify the result with status checks before you trust it.