OpenClaw Tailscale Remote Access: Keep Your AI Gateway Private

OpenClaw Tailscale remote access is the cleanest way to reach your AI agent Gateway from another device without turning the Gateway into a public web app. That distinction matters. OpenClaw is not exposing a brochure site. It is exposing the Control UI and the Gateway WebSocket, which means it sits close to sessions, channels, model access, and node tools.

The right default is boring: keep the Gateway on loopback, let Tailscale handle the network path, and use Serve for tailnet-only access. Reach for Funnel only when you knowingly want a public HTTPS URL. If that sounds cautious, good. Remote agent control should be convenient, but it should not become casual.

Why OpenClaw Tailscale remote access exists

OpenClaw runs one Gateway as the master process. The Gateway owns sessions, auth profiles, channels, and state. Operators, CLI clients, native apps, and nodes connect to it over the Gateway WebSocket. By default, that WebSocket binds to 127.0.0.1 on port 18789.

That default is sane for a local install. It means random machines on your LAN cannot talk to the Gateway just because they can see your computer. It also means a VPS install, home server, or laptop needs a deliberate remote-access path before another device can control the agent.

The OpenClaw docs lay out three main remote patterns: Tailscale Serve or a trusted tailnet bind, SSH tunneling, and identity-aware proxy setups such as Cloudflare Access. Tailscale sits in a useful middle ground. It gives you a stable private address and HTTPS without making you maintain a full reverse-proxy stack for a one-person or small-team agent setup.

That is the real reason this integration exists. It is not “VPN because VPN sounds secure.” It is a way to keep OpenClaw bound to a local interface while still making it reachable from your phone, laptop, or node host inside the same tailnet.

The short version: use Serve first

If you remember one rule, make it this: use Tailscale Serve unless you have a specific reason to make the Gateway public. In OpenClaw config, that looks like this:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

With that setup, OpenClaw keeps the Gateway bound to 127.0.0.1. Tailscale Serve provides the HTTPS URL on your tailnet. You open the Control UI at the device’s MagicDNS HTTPS address, and devices outside the tailnet do not get a public route.

Tailscale’s own Serve docs describe the same basic model: Serve routes traffic from other devices on your tailnet to a local service running on a device. It can proxy to a local port, serve local files, or serve static text. For OpenClaw, the important case is the local-port proxy.

What Serve exposes

OpenClaw-managed Serve/Funnel is scoped to the Gateway dashboard and WebSocket port. It does not expose the entire server. It also does not require the Gateway to listen on every interface. That is a big difference from binding a service to 0.0.0.0 and hoping every firewall rule stays perfect.

OpenClaw holds the managed Serve or Funnel route as a foreground Tailscale claim. Startup succeeds only after the claim is active, and stopping or losing the Gateway releases that route. That ownership model matters because stale remote routes are easy to forget. A route that vanishes with the Gateway is less likely to become old hidden infrastructure.

The docs also call out a subtle status point: gateway.tailscale.mode: "off" means OpenClaw is not managing Serve or Funnel. It does not mean the local Tailscale daemon is stopped, logged out, or disabled. That avoids a bad assumption during audits.

Why identity headers matter

Tailscale Serve can add identity headers to tailnet traffic, including Tailscale-User-Login. Tailscale says it removes incoming versions of those headers before forwarding, which helps prevent simple header spoofing. OpenClaw adds its own verification step for managed Serve: it checks the forwarded address with the local Tailscale daemon and matches it to the login header before accepting tokenless Tailscale identity for the relevant Control UI auth flow.

Do not overread that. Tailscale identity headers are not magic permission slips for every HTTP route. OpenClaw limits where that tokenless path applies, and normal API routes still follow the configured Gateway auth mode. That is exactly the right trade. Operator convenience gets easier, but tool and API surfaces stay behind ordinary Gateway auth.

If untrusted local code may run on the same Gateway host, turn off the Tailscale identity shortcut and require a token or password. Localhost is only a strong boundary when you trust the processes sharing that host.

When to use a direct tailnet bind

Serve is best for the browser Control UI. There is also a direct tailnet option:

{
  gateway: {
    bind: "tailnet",
    auth: { mode: "token", token: "your-token" },
  },
}

This has the Gateway listen directly on the Tailnet IP instead of using Serve or Funnel. A native or CLI client from another tailnet device can connect to the WebSocket at ws://<tailscale-ip>:18789.

The catch is in the OpenClaw docs: do not use that plain HTTP address for the browser Control UI. Remote plain HTTP cannot create browser device identity, and token or password auth is not a replacement for that browser identity flow. For the Control UI, Serve is the better answer because it gives you HTTPS and the managed route OpenClaw expects.

Direct tailnet bind is useful when you have a native or CLI client and want fewer moving pieces. It is not the neatest browser story.

When Funnel is the right tool

Tailscale Funnel is the public version. It routes traffic from the broader internet to a local service in your tailnet through a Funnel URL. Tailscale describes Funnel as beta, available on all plans, and meant for cases where the person opening the URL does not need to be in your tailnet.

For OpenClaw, public access should be rare. It may make sense for a temporary demo, a tightly controlled remote operator setup, or a machine you cannot put into the tailnet. But the moment you use Funnel, you are no longer relying on tailnet membership as the first gate. You need application-level auth.

OpenClaw enforces that by refusing managed Funnel startup unless Gateway auth mode is password. A reasonable config looks like this:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "funnel" },
    auth: { mode: "password", password: "replace-me" },
  },
}

In practice, do not write the password into a committed config file. Use OPENCLAW_GATEWAY_PASSWORD or a secret provider. Public endpoints and hard-coded passwords age badly.

Funnel requirements and limits

Tailscale’s Funnel docs list a few hard requirements: Tailscale v1.38.3 or later, MagicDNS, HTTPS enabled for the tailnet, and a funnel node attribute in the tailnet policy. Funnel also listens only on ports 443, 8443, and 10000, and only over TLS.

Those limits are not trivia. They affect incident response and debugging. If Funnel will not start, do not stare at OpenClaw first. Check the Tailscale version, MagicDNS, HTTPS certificates, and the tailnet policy. Tailscale also notes that public DNS records can take up to 10 minutes to appear for a Funnel URL, so a short delay after setup is not always an OpenClaw problem.

Why OpenClaw requires password auth for Funnel

Funnel traffic is public. Tailscale still encrypts the path and hides the device’s public IP, but anyone with the Funnel URL can try to connect. That changes the threat model.

OpenClaw requiring password auth for Funnel is not friction for its own sake. It prevents the worst configuration: a public Gateway URL with no meaningful application gate. Even if you think the URL is obscure, treat it as discoverable. URLs get pasted into chats, logs, browser history, screenshots, and monitoring tools.

The safer pattern is simple: Serve for private daily use, Funnel with a strong password for public cases, and no public Funnel for browser-control workflows unless you have a very good reason.

Tailscale vs SSH tunnels vs Cloudflare Tunnel

Tailscale is not the only way to reach OpenClaw remotely. SSH tunneling is the universal fallback:

ssh -N -L 18789:127.0.0.1:18789 user@gateway-host

With that tunnel running, local CLI commands can reach the remote Gateway through ws://127.0.0.1:18789. This is excellent when you already have SSH and need a quick, temporary path. It is less pleasant as a daily mobile or multi-device setup because every client needs the tunnel story sorted out.

Cloudflare Tunnel and Access can be a good fit for teams that already operate Cloudflare Access and want identity-aware policy at the edge. That comes with its own setup: Access tokens, trusted-proxy auth, scoped headers, and edge-auth configuration. It is powerful, but it is more machinery than most solo OpenClaw installs need on day one.

Tailscale Serve sits between those options. It is easier to live with than ad hoc SSH tunnels and narrower than a public reverse proxy. For a homelab, VPS, or always-on personal Gateway, that is usually the sweet spot.

Browser control: pair a node, do not expose the browser

OpenClaw’s Tailscale docs make a point that is easy to miss: if the Gateway runs on one machine but the browser runs on another, run a node host on the browser machine and keep both machines on the same tailnet. The Gateway proxies browser actions to the node. You do not need a separate browser control server.

Avoid Funnel for browser control. Pair the node like operator access and keep the browser machine inside the trust boundary. Browser automation often touches logged-in websites, local profiles, cookies, screenshots, downloads, and files. That is not a surface you want to drag onto the public internet just because a tunnel command made it easy.

This is a pattern worth applying beyond OpenClaw. Remote control of an agent is one thing. Remote control of the machine the agent can see is another. Keep those mental boxes separate.

Practical setup checklist

For most OpenClaw users, the checklist is short:

• Install the Tailscale CLI on the Gateway host and log in.
• Enable MagicDNS and HTTPS certificates for the tailnet if Serve prompts for them.
• Keep gateway.bind set to "loopback".
• Set gateway.tailscale.mode to "serve" for private tailnet access.
• Use "tailnet" bind only for direct native or CLI WebSocket access.
• Use "funnel" only when public access is intentional, and require password auth.
• Use OPENCLAW_GATEWAY_PASSWORD or a SecretRef instead of committing a password.
• For browser automation on another device, run an OpenClaw node on that device.
• Run openclaw doctor when old Serve/Funnel routes or bind settings look suspicious.

Also remember the pricing reality. Tailscale’s pricing FAQ says the Personal plan is free forever for personal use, and the current Personal plan allows 6 users. That makes Serve a realistic default for small personal OpenClaw setups. For company domains and production infrastructure, read the business-plan terms instead of assuming the personal tier applies.

FAQ

Is Tailscale Serve enough for OpenClaw remote access?

For most private setups, yes. Serve gives you tailnet-only HTTPS access while OpenClaw keeps the Gateway bound to loopback. It is the best default for the Control UI.

Should I use Funnel for my everyday OpenClaw Gateway?

Usually no. Funnel is public internet access. Use it for intentional public access, demos, or special cases, and protect it with password auth. Serve is the calmer daily choice.

Can I connect directly to the Tailscale IP instead?

Yes, for native or CLI WebSocket clients. Configure gateway.bind: "tailnet" and use token auth. Do not use the direct plain-HTTP address for the browser Control UI.

Does Serve remove the need for OpenClaw authentication?

No. Managed Serve can use verified Tailscale identity for part of the Control UI auth flow, but other API routes still follow Gateway auth. If you do not fully trust local code on the Gateway host, require token or password auth.

What is the safest fallback if Tailscale is not available?

Use an SSH tunnel to forward 127.0.0.1:18789 from the Gateway host to your local machine. It is not as tidy for daily multi-device use, but it is predictable and keeps the Gateway loopback-only.

Final take

OpenClaw’s Tailscale support is best understood as a restraint, not an exposure feature. The point is to avoid opening the Gateway broadly while still making it reachable from the devices that belong in your operating loop.

Use Serve first. Use direct tailnet bind when a native or CLI client needs the WebSocket without the browser Control UI. Use Funnel only when public access is the point, and then make password auth non-negotiable. That simple split keeps remote access useful without turning your AI Gateway into another forgotten public endpoint.

For the next step, read the OpenClaw Tailscale docs, then check your current Gateway with openclaw doctor. If the Gateway is still loopback-only and Serve owns the route, you are on the right side of the line.