How to Expose OpenClaw Control UI with Tailscale Serve

Tailscale Serve is the nice path for reaching the OpenClaw Control UI from your own devices without binding the Gateway to a public or LAN interface. OpenClaw can manage Serve for the Gateway dashboard and WebSocket port, so you get HTTPS and tailnet routing while the Gateway itself stays on 127.0.0.1.

30-second answer

Set gateway.bind to loopback and gateway.tailscale.mode to serve, or start the Gateway with openclaw gateway --tailscale serve. Use the MagicDNS HTTPS URL for Control UI and WebSocket access. If gateway.auth.allowTailscale is true, Control UI/WebSocket auth can use verified Tailscale identity headers, but HTTP API routes still require normal Gateway auth.

When this pays off

Use this when you want a clean remote operator UI from your phone, laptop, or another trusted device on the tailnet. It is especially useful for small business operators who want always-on Gateway access without owning reverse-proxy infrastructure. Compared with public hosting, Serve keeps the audience to the tailnet by default.

Operator runbook

1. Install and log in to Tailscale on the Gateway host first. OpenClaw can automate Serve or Funnel, but it depends on the tailscale CLI being available and authenticated. Serve also requires HTTPS enabled for the tailnet, and the Tailscale CLI may prompt if that prerequisite is missing.
2. Keep the Gateway bind mode loopback. The docs show the safest Serve config as gateway.bind loopback with tailscale.mode serve. That means OpenClaw listens locally while Tailscale provides the HTTPS route. Do not switch to a LAN bind unless you have a separate reason.
3. Decide whether Tailscale identity headers are acceptable. With gateway.auth.allowTailscale true, Control UI and WebSocket auth can use verified Tailscale identity headers from Serve. OpenClaw verifies the x-forwarded-for address through tailscale whois before trusting the header.
4. Remember the API exception. The docs explicitly say HTTP API endpoints such as /v1/*, /tools/invoke, and /api/channels/* do not use Tailscale identity-header auth. They still follow normal Gateway HTTP auth mode, so configure token, password, trusted-proxy, or private-ingress behavior intentionally.
5. Avoid Funnel unless public access is intentional. Tailscale Funnel exposes public HTTPS, and OpenClaw refuses funnel mode unless auth mode is password. Serve is tailnet-only and is the right default for operator access.
6. Verify with both browser and CLI. Open the Control UI through the MagicDNS HTTPS URL, then run Gateway status or health through the same network path you expect operators to use. If HTTP APIs are part of the design, test bearer auth separately.

Verification

The proof is: Control UI loads over the Tailscale Serve URL, the Gateway remains loopback-bound locally, WebSocket connects, and API routes still reject missing credentials. If browser control is involved, follow the docs and run a node host on the browser machine inside the same tailnet rather than exposing a separate browser control server.

Common mistakes

Do not read tailscale.mode off as meaning Tailscale itself is off; the docs say it only means OpenClaw is not managing Serve or Funnel. Do not assume Funnel has the same trust model as Serve. And do not use Tailscale identity headers as a general-purpose auth replacement for every Gateway HTTP endpoint.

Turn it into a repeatable operating system

The Playbook helps you choose between SSH tunnels, Tailscale Serve, tailnet bind, and public Funnel. The right choice depends on who needs access, what tools are enabled, and how expensive a mistake would be. Serve is often the best operator UX with the least drama.

Before rollout

Before rollout, verify access from a device on the tailnet and from a device outside it. The outside device should fail. That negative test is important because Serve, Funnel, direct tailnet bind, and custom reverse proxies can look similar when you only test from your own laptop.