How to Use OpenClaw with Tailscale

Tailscale is one of the nicest remote-access companions for OpenClaw because it lets you keep the gateway bound tightly while still making the control surface reachable in a sane way. The docs are very clear that the gateway can stay on loopback and let Tailscale handle the HTTPS, routing, and identity layer.

Start with one clean path

The first decision is mode. Serve is tailnet-only and keeps the gateway on 127.0.0.1. Funnel is public HTTPS and requires password auth. Off means no Tailscale automation at all. Those are good defaults because they force you to think about exposure before you think about convenience. If you only need tailnet access, Serve is the clean path. If you truly need public exposure, Funnel makes you bring an explicit shared secret.

That restraint matters. The fastest way to make a channel integration feel noisy is to turn on every surface at once. OpenClaw gets better when you bring one route online, verify the auth model, check the session behavior, and only then expand into alerts, commands, or additional accounts.

Base configuration

The documented config examples are refreshingly small. For Serve, bind loopback and set tailscale.mode to serve. For direct tailnet binding, bind tailnet and use token auth. For Funnel, bind loopback, set tailscale.mode to funnel, and configure password auth. The docs also include CLI forms for starting the gateway with Tailscale flags, plus notes on prerequisites such as the tailscale CLI being installed and logged in.

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

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

openclaw gateway --tailscale serve
openclaw gateway --tailscale funnel --auth password

• Use Serve for tailnet-only access when you want the safest smooth remote path.
• Use Funnel only when you intentionally need public HTTPS and can enforce password auth.
• Keep bind loopback unless you specifically want direct tailnet binding.
• Remember that Serve injects Tailscale identity headers while Funnel does not.

Operational habits that keep it sane

Operationally, I would start with Serve and only move beyond it when the use case clearly demands it. The docs also mention browser-control routing through a node host on the same tailnet, which is a good reminder that Tailscale access is not just about the dashboard UI. It can also provide a cleaner topology for remote nodes and browser execution without inventing extra public infrastructure.

The common mistakes are using Funnel for convenience instead of necessity, forgetting the password requirement, or assuming tailnet and loopback behave the same. They do not. The docs specifically note that 127.0.0.1 will not work if you bind directly to the Tailnet IP. That is the kind of subtle networking truth that saves hours when you know it early.

When used conservatively, Tailscale makes remote OpenClaw feel modern without making it sloppy. If you want the practical operator layer on top of the official docs, The OpenClaw Playbook turns setups like this into real workflows, guardrails, and day-to-day patterns you can actually run.

It is also smart that the docs call out Serve identity headers and the option to disable allowTailscale if the gateway host itself is not fully trusted. Remote access is never just about the network path. It is also about which identity signals you are willing to trust on the receiving host.

The auth story is the part to internalize. Serve can use Tailscale identity headers for the Control UI and WebSocket when gateway.auth.allowTailscale is true, but ordinary HTTP API endpoints still follow the gateway's normal HTTP auth mode. That is a subtle boundary, and an important one.

Funnel is intentionally stricter. The docs refuse to start it unless auth mode is password, which is exactly the kind of opinionated safety check you want before putting a gateway surface on the public internet.