mirror of
https://github.com/openclaw/openclaw.git
synced 2026-04-05 14:21:32 +00:00
2.5 KiB
2.5 KiB
summary, read_when, title
| summary | read_when | title | |||
|---|---|---|---|---|---|
| Network hub: gateway surfaces, pairing, discovery, and security |
|
Network |
Network hub
This hub links the core docs for how OpenClaw connects, pairs, and secures devices across localhost, LAN, and tailnet.
Core model
Most operations flow through the Gateway (openclaw gateway), a single long-running process that owns channel connections and the WebSocket control plane.
- Loopback first: the Gateway WS defaults to
ws://127.0.0.1:18789. Non-loopback binds require a valid gateway auth path: shared-secret token/password auth, or a correctly configured non-loopbacktrusted-proxydeployment. - One Gateway per host is recommended. For isolation, run multiple gateways with isolated profiles and ports (Multiple Gateways).
- Canvas host is served on the same port as the Gateway (
/__openclaw__/canvas/,/__openclaw__/a2ui/), protected by Gateway auth when bound beyond loopback. - Remote access is typically SSH tunnel or Tailscale VPN (Remote Access).
Key references:
Pairing + identity
- Pairing overview (DM + nodes)
- Gateway-owned node pairing
- Devices CLI (pairing + token rotation)
- Pairing CLI (DM approvals)
Local trust:
- Direct local loopback connects can be auto-approved for pairing to keep same-host UX smooth.
- OpenClaw also has a narrow backend/container-local self-connect path for trusted shared-secret helper flows.
- Tailnet and LAN clients, including same-host tailnet binds, still require explicit pairing approval.