# OpenClaw Gateway The Gateway is [[OpenClaw]]'s control plane. It is a single long-running process that bridges chat applications, tools, and the AI agent runtime, exposing a unified WebSocket network at `ws://127.0.0.1:18789` (the default loopback bind). Channels (Discord, Slack, Signal, Telegram, …), clients (Control UI, Dashboard, TUI, WebChat), tools (browser, exec, MCP), nodes (iOS/Android), and the agent runtime all attach to the same gateway over typed events. The docs describe it as the "single source of truth for sessions, routing, and channel connections." Without the gateway nothing routes; with the gateway you have one process to deploy, monitor, secure, and scale. ## Default Agent Surface Out of the box the gateway runs the bundled [[Pi Mono|Pi]] binary in RPC mode with per-sender sessions. That gives a usable agent the moment the gateway is up, before any model provider, [[OpenClaw ACP Agents|ACP backend]], or [[OpenClaw Sub-Agents|sub-agents]] are configured. ## Remote Access By default the gateway binds to localhost. Two recommended ways to expose it: - **Tailscale Serve/Funnel**: keep the gateway on loopback locally and reach it via the Tailscale mesh ; no public attack surface - **SSH tunnel**: forward `18789` over an existing SSH connection Both keep secrets and credentials inside the trust boundary the operator already owns. ## Multiple Gateways A team or family deployment can run several gateways with distinct roles (e.g., one per environment, one per office) ; the docs include a "Multiple Gateways" guide. Cross-gateway communication is intentional and explicit, not implicit clustering. ## Cloud Sessions and Multi-User (OpenClaw 2.0) Since [[2026-10-03 OpenClaw 2.0 - easier setup, shared sessions, same security defaults|OpenClaw 2.0]] (August 2026), the Gateway stays the owner of every conversation even when the work runs elsewhere. A session can run on the Gateway host (default), on a **paired device** (`openclaw connect`), or on a throwaway **cloud worker** leased through [[Crabbox]]. Model inference stays proxied through the Gateway, so provider credentials never reach the remote machine. Shared cloud sessions make the Gateway multiplayer: several people can join the same live session with the agent's context intact, and owners decide who can read, suggest, or participate. The docs are explicit about the limit: **one trust boundary per Gateway**. Multi-user controls are for people who trust each other, not a hard tenant boundary between adversarial users; for that, run separate Gateways with separate credentials. ## Operational Surface Documented gateway concerns include: - **Configuration reference** ; `openclaw.json` keys - **Authentication** ; user and service credentials - **Discovery & transports** ; how clients find the gateway - **Health checks** ; liveness/readiness for orchestrators - **Logging** ; event tracking and debug output - **OpenTelemetry export** + **Prometheus metrics** ; observability ## CLI Anchors ```bash openclaw gateway --port 18789 --verbose # start openclaw status --all # health openclaw doctor # diagnostics openclaw agents list --bindings # multi-agent routing topology ``` ## References - Gateway runbook: https://docs.openclaw.ai/gateway - Configuration reference: https://docs.openclaw.ai/gateway/configuration - Security: https://docs.openclaw.ai/gateway/security - Cloud sessions: https://docs.openclaw.ai/gateway/cloud-sessions ## Related - [[OpenClaw]] - [[OpenClaw Multi-Agent Routing]] - [[OpenClaw Channels]] - [[OpenClaw Sub-Agents]] - [[Pi Mono]]