Configure OpenClaw Gateway: Setup Guide for Production

Ever tried to manage multiple bot instances and realized your session management is a total mess? It is a common headache when you are trying to keep everything synced without hitting rate limits or losing connections. That is where the Gateway comes in.

The Gateway (openclaw gateway) is your central hub. It is a single process that stays running to handle channel connections and the WebSocket control plane. Think of it as the traffic controller for your entire setup.

This content has been merged into Network. See that page for the current guide.

Core rules

• Stick to one Gateway per host. This process is the boss of the WhatsApp Web session. If you need rescue bots or want strict isolation, you can run multiple gateways with separate profiles and ports. Check out Multiple gateways for that.
• Start with loopback. The Gateway WS defaults to ws://127.0.0.1:18789. Even if you stay on loopback, the wizard creates a gateway token. If you need tailnet access, use openclaw gateway --bind tailnet --token ... because you need tokens for any bind that isn’t loopback.
• Nodes talk to the Gateway WS over LAN, tailnet, SSH, or local tunnels. Don’t use the legacy TCP bridge; it is deprecated.
• The Gateway HTTP server handles the Canvas host on the same port (default 18789). You will find it at these routes:
  • /__openclaw__/canvas/
  • /__openclaw__/a2ui/ When you configure gateway.auth and the Gateway binds beyond loopback, these routes get protected. Node clients use specific capability URLs tied to their active WS session. See Gateway configuration for details on canvasHost and gateway.
• For remote access, stick to SSH tunnels or a tailnet VPN. You can find more details in Remote access and Discovery.

AI Setup Assistant

Next Steps

• Gateway configuration
• Remote access
• Discovery
• Multiple gateways