How to Secure OpenClaw Remote Access

Remote access is where a self-hosted system either feels elegant or gets accidentally exposed in embarrassing ways. OpenClaw's remote-access docs are strong because they keep repeating the right default: one gateway, loopback-bound, reached through a controlled tunnel or tailnet rather than through casual public exposure.

Default to the smaller surface area

The core remote model is simple. The gateway host is where the agent lives. It owns sessions, auth profiles, channels, and state. Clients and nodes connect to that host. For operators, SSH tunneling is the universal fallback. For nodes, the connection is to the gateway WebSocket over LAN, tailnet, or an SSH tunnel as needed. That keeps the trust boundary centered on one real gateway instead of several half-trusted copies.

That default is a recurring OpenClaw theme. The platform usually gives you a convenient path and a safer path, and the docs are pretty clear that the safer path should win unless you genuinely need something broader. If you treat every network, auth, and execution option as interchangeable, you will create problems that look like product bugs but are really trust-boundary mistakes.

Documented setup pattern

The docs show the baseline SSH tunnel, then a remote-mode config that points the CLI at the forwarded local URL and an explicit token. They also explain a lot of auth precedence detail, which is worth respecting. URL overrides do not automatically reuse implicit credentials. Client-side remote credentials are not the same as server-side auth configuration. Those distinctions are exactly what keep remote access from becoming guessy and dangerous.

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

{
  gateway: {
    mode: "remote",
    remote: {
      url: "ws://127.0.0.1:18789",
      token: "your-token",
    },
  },
}

• Keep the gateway on loopback unless you have a documented reason to bind more broadly.
• Use SSH or Tailscale Serve for remote operator access instead of punching a random public hole.
• Treat browser control like operator access and keep it behind deliberate pairing and trusted paths.
• When you override a URL explicitly, pass the credentials explicitly too.

Checks before you call it done

Operationally, I would start with loopback plus SSH even if I planned to add Tailscale later. It gives you one concrete, testable path and teaches you the topology. Once that works, you can decide whether Tailscale Serve improves the UX enough to justify it. The docs also show how to make the SSH tunnel persistent on macOS with a LaunchAgent, which is a nice touch when remote access is part of the daily workflow.

The biggest mistake is treating non-loopback binds as harmless convenience. They are not. The docs say short version: keep the gateway loopback-only unless you are sure you need a bind. Another easy mistake is confusing client-side remote credentials with server auth. If you blur those concepts, you end up feeling secure without actually having configured the server side correctly.

Secure remote access should feel slightly boring. That is a compliment. 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.

I also appreciate the explicit discussion of Tailscale identity headers, trusted-proxy mode, and insecure private WebSocket break-glass behavior. Those are the kinds of edge conditions that quietly define whether “remote access” is robust engineering or just hopeful networking.

The safest default is repeated throughout the docs for a reason: keep the gateway bound to loopback and forward access to it. A simple SSH tunnel like ssh -N -L 18789:127.0.0.1:18789 user@host is much easier to reason about than exposing the gateway directly and hoping every auth surface is perfect.

It is also worth remembering that gateway.remote.token and gateway.remote.password are client credential sources, not server-side protection by themselves. That distinction is where a lot of remote-access misunderstandings begin.