Remote Access

Most remote access mistakes come from one bad instinct: people treat convenience like permission. They need OpenClaw from another laptop, so they crack open a port and hope for the best. That is the digital version of hiding a house key under the doormat.

OpenClaw gives you a cleaner pattern. Keep one gateway alive on a trusted machine, keep it private by default, and bring yourself to the gateway through a tunnel or a tailnet. Same convenience, less regret.

What remote access means in OpenClaw

One gateway owns the important state: sessions, auth profiles, channels, tools, and node connections. Your other devices are clients. They connect to that gateway instead of each running their own isolated universe.

That matters because modern OpenClaw remote access is simpler than a lot of older guides imply. The gateway WebSocket is the center of gravity. CLI commands, the Control UI, and WebChat can all work through that same remote path.

• Gateway host: the machine that runs OpenClaw full-time
• Operator device: your laptop, desktop, or workstation
• Nodes: phones, tablets, or other machines that attach to the gateway

The safe default: keep the gateway on loopback

The best baseline is still boring in the best way. Bind the gateway to 127.0.0.1 and bring remote traffic in through a trusted transport.

There is a reason the industry moved from Telnet to SSH. The old lesson was simple: remote access is useful, but raw exposure ages badly. OpenClaw follows that same pattern. Private by default first, convenience second.

When the gateway stays loopback-only, you avoid the most common failure mode: a management port sitting on the public internet longer than intended.

Option 1: Remote over SSH

If you want the universal fallback, use an SSH tunnel. One forwarded port is enough for most remote OpenClaw work.

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

That command forwards your local 18789 to the remote gateway on the same port. Once the tunnel is up, your local tools can talk to ws://127.0.0.1:18789 as if the gateway were running beside you.

This setup is great for:

• CLI usage from a laptop
• Temporary admin sessions
• Secure access over untrusted networks
• Machines where you already trust SSH more than another networking layer

Persisting remote defaults

If you connect often, store the remote target in your config so the CLI knows where to look after the tunnel is open.

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

One important detail: when you override the gateway URL directly, send the credentials explicitly too. That is not OpenClaw being annoying. That is OpenClaw refusing to guess on a security boundary.

Option 2: Tailscale for everyday remote access

If SSH is the universal fallback, Tailscale is often the nicest day-to-day setup. It gives your devices a private network without asking you to expose the gateway publicly.

There are two practical patterns:

• Tailscale Serve: keep the gateway on loopback and let Tailscale handle HTTPS and routing inside your tailnet
• Tailnet bind: bind the gateway to the tailnet IP when you want direct access from other tailnet devices

Tailscale Serve

This is the clean option for a gateway that stays online all the time. The gateway remains private on the host, while Tailscale acts like the guarded reception desk in front of it.

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

With this mode, you usually get the best mix of safety and comfort: loopback on the host, HTTPS in the tailnet, and fewer moving parts on client machines.

Direct tailnet binding

If you want plain network-style access from other tailnet devices, bind directly to the tailnet interface and keep auth enabled.

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

This is straightforward, but it is less private than loopback plus Serve. Good for homelabs. Not my first choice for casual internet exposure.

Option 3: Public access only when you truly need it

Sometimes you do need a public entry point. Maybe you are testing a client on a device that cannot join your tailnet. Maybe you are sharing temporary operator access with a tightly controlled workflow. Fine. Just treat it like production infrastructure, not a shortcut.

OpenClaw documentation recommends a password-protected setup for public Tailscale Funnel access. In plain English: if you go public, shared-secret auth stops being optional.

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

If you are wondering whether you need this, you probably do not. SSH or a tailnet is usually the better answer.

WebChat and Control UI over remote access

Older mental models can trip people up here. WebChat no longer needs a separate web port. The current remote pattern is simpler: forward or expose the gateway path correctly, then let WebChat ride the same connection.

That means one good remote setup can cover:

• Control UI access
• CLI commands
• WebChat sessions
• Health checks and status inspection

If your goal is browser-based access from anywhere, pair this guide with the WebChat setup article. Remote networking first, chat UX second.

Remote nodes and browser control

Remote access is not only for you. It is also how the rest of your OpenClaw system stays coherent.

Imagine one always-on gateway on a home server, your phone connected as a node, and a separate desktop handling browser automation. The gateway remains the decision-maker. It receives the message, runs the agent, calls the browser node or mobile node when needed, then sends the result back out.

If you want a browser on another machine, run a node host on that browser machine and keep both sides on the same tailnet or secure remote path. That avoids the ugly version of this setup, which is inventing a second public control surface you now have to defend forever.

Common remote access patterns

Always-on home server

Run the gateway on a Raspberry Pi, mini PC, or spare desktop. Use Tailscale Serve or SSH from your laptop. This is the sweet spot for most serious personal setups.

Laptop as temporary gateway

Keep OpenClaw local on your laptop, then tunnel into it from another machine when needed. Good for travel. Less ideal if the laptop sleeps constantly.

VPS as permanent gateway

Use a VPS when you want stable uptime and less dependence on your home internet. Still keep the gateway private by default. Public VPS does not mean public gateway.

Troubleshooting

The tunnel works, but commands still fail

• Check that the gateway is really listening on port 18789
• Make sure your remote config points at ws://127.0.0.1:18789 after forwarding
• Confirm you supplied the right token or password for the chosen auth mode

Tailscale connects, but the Control UI does not load

• Verify whether you chose serve or direct tailnet binding
• Check that Tailscale is logged in on both devices
• Make sure your gateway auth settings match the exposure mode

WebChat works locally but not remotely

• Confirm the gateway path is what you exposed, not an old separate chat port assumption
• Check browser console and gateway logs for failed WebSocket handshakes
• Re-test with a simple SSH tunnel before blaming the app layer

Remote browser automation is flaky

• Keep the browser machine on the same tailnet as the gateway
• Make sure the node host is paired and healthy
• Do not use public Funnel as your first attempt for browser control

Remote access security checklist

• Default to loopback: let SSH or Tailscale do the reaching
• Use auth on non-loopback binds: token, password, or a trusted proxy setup
• Do not expose the gateway casually: public ports have a habit of staying open
• Keep one gateway in charge: nodes are peripherals, not competing gateways
• Test the simple path first: if SSH tunnel access is solid, the rest of the stack is easier to debug

That last point matters more than it sounds. Good remote access is less about clever networking and more about disciplined boundaries. One host owns the state. Everything else reaches it on purpose.

What to do next

• Read Home Server & Raspberry Pi if you still need a stable host
• Set up WebChat once your remote path is working
• Review security best practices before exposing anything broader than your laptop