Why you should never put your OpenClaw Gateway on the public internet

Why this rule exists

It’s tempting, once OpenClaw runs on a server, to just open the Gateway’s port so you can reach the dashboard from your phone. Here’s what that door opens onto. The Gateway is not a website — it’s the control channel for an agent that can execute shell commands, read and write files, and drive a browser on its machine. OpenClaw’s security documentation spells out the threat model for an exposed Gateway: an attacker can trigger arbitrary commands, go through the filesystem — including your agent’s memory and any credentials it can reach — and manipulate the agent itself with crafted messages (prompt injection). One exposed port turns “my agent’s home” into “a stranger’s shell on my server, with my model key attached.”

And exposed ports get found. Anyone who has run a server with SSH open has watched the login attempts roll in within hours — automated scanners sweep the whole internet continuously. A Gateway on a public port isn’t hiding; it’s waiting.

The defaults are on your side — until you fight them

Out of the box you can’t make this mistake: the Gateway binds to loopback, so only programs on the same machine can talk to it. Trouble arrives via well-meaning changes — binding to 0.0.0.0 “just to test,” a Docker port mapping that publishes the Gateway to all interfaces, a too-generous firewall rule. Each looks harmless in the moment; each is the exact misconfiguration the docs warn about. If you take one habit from this guide: after any networking or config change, run openclaw security audit — checking network exposure is one of the specific things it’s for.

How to reach your agent remotely, safely

The legitimate need behind the mistake is real: an always-on agent you can only reach from one machine is barely an agent. The safe patterns all share one shape — the Gateway stays private, and something that authenticates you carries you to it.

• Chat channels — the everyday answer. Telegram, WhatsApp, Discord and the rest connect outward from the Gateway to the chat service; nothing about your server is exposed, and OpenClaw’s pairing and allowlists control who can talk to the agent. For daily use, this is the remote access.
• An SSH tunnel — the operator’s answer. If you administer the server anyway, an SSH tunnel gives your laptop a temporary private line to the dashboard. Free and safe; clunky on a phone.
• An identity-checking proxy — the polished answer. For a dashboard you can open from anywhere, put an authenticating reverse proxy or identity-aware tunnel in front of the private Gateway, and use OpenClaw’s support for proxy authentication (trusted-proxy mode, with trustedProxies configured) so it knows, cryptographically, who’s knocking. Done right, you sign in with your identity, and no Gateway port ever faces the internet. Done wrong, it’s worse than nothing — the docs require the proxy to overwrite forwarded headers so identity can’t be spoofed, which is exactly the kind of detail that separates a safe setup from a confident-feeling one.

That third pattern is what we build at Everpod: every pod’s gateway stays off the open internet with no inbound ports, and you reach your agent’s control panel through an authenticated, private path — sign in with your email, and you’re the only one it lets through. It’s the pattern the docs recommend, operated so you don’t have to get the details right yourself.