.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
OpenClaw is useful for the same reason it can be dangerous. It can run commands, read files, and act on your behalf. If you deploy that on a public VPS with sloppy defaults, you have basically built a remote admin panel for strangers.
This guide is the “boring security” version of OpenClaw hosting. It focuses on a realistic threat model, then builds defense in depth. If you do only one thing, do this: keep the OpenClaw Gateway private and never bind it to the public internet.
If you want background context first, read what OpenClaw is and how it works. If you’re setting up multiple chat apps, pair this with OpenClaw multi-channel setup.
The threat model for OpenClaw on a VPS
With a normal web app, a breach is often “data leaked.” With OpenClaw, a breach can be “commands executed.” That changes the stakes.
These are the common ways OpenClaw deployments go wrong.
Open ports and exposed services
Attackers scan public IP ranges all day. If your VPS exposes SSH, databases, dashboards, or the OpenClaw Gateway without strong access control, it will get probed. If the Gateway is reachable and unauthenticated, compromise can happen quickly.
Prompt injection
Prompt injection is when OpenClaw reads untrusted text that contains instructions, then follows those instructions because it cannot reliably tell “data” from “commands.” This can happen through an issue tracker, a pasted log file, a message in a chat room, or a web page the agent browses.
In an agent context, prompt injection is not a theoretical problem. It is a direct path to credential exfiltration or destructive commands unless you scope tools tightly.
Over-privileged tools and tokens
If OpenClaw has full shell access but only needs to read a directory, that is extra risk for no benefit. Same for API tokens. If your GitHub token is org admin but you only need repo read, that is a gift to anyone who gets the agent to misuse it.
Unvetted skills and dependencies
Community skills can be great. They can also be a supply-chain risk. Only install skills you can audit. The same goes for packages used by channel integrations.
Credential sprawl
Agents tend to accumulate secrets. API keys in .env files, SSH keys in home directories, tokens in logs, credentials stored with loose permissions. If someone gets filesystem access, this is where the real damage happens.
Weak container isolation
Docker can help, but only if you do it right. Running as root, mounting your entire home directory, or enabling privileged mode can turn “container” into “easy host compromise.”
The secure default mindset
Before the step-by-step, here is the mindset that keeps you safe:
- Assume OpenClaw will ingest untrusted text
- Assume an integration token will leak someday
- Assume a firewall rule will be misclicked
- Assume you will forget what you set up 6 months from now
Security that survives those assumptions is not one magic setting. It is layers.
Layer 1: Keep the Gateway private
The Gateway should never listen on 0.0.0.0. Bind it to localhost only.
Example gateway config:
{
"gateway": {
"bind": "127.0.0.1",
"port": 18789
}
}Verify the bind address on the VPS:
ss -tulpn | grep 18789You want to see 127.0.0.1:18789, not 0.0.0.0:18789.
This single change blocks the most common failure mode: “I opened the port and forgot.” Even if your firewall is messy, the service is not reachable from the public network.
Layer 2: Lock down the VPS network perimeter
Use a firewall. On Ubuntu, UFW is fine and easy to audit.
Basic policy:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw limit 22/tcp
sudo ufw enable
sudo ufw status numberedThat keeps inbound surface small. If you do not host anything else, you can skip 80 and 443.
Extra tip: if you can, restrict SSH to your IP or to a private network. Most brute force noise disappears instantly.
Layer 3: Access the Gateway through a private tunnel
If you need to reach OpenClaw remotely, do not expose the Gateway port. Use a private tunnel.
Tailscale is a common choice because it is simple and it gives you an encrypted private network between your devices and the VPS. Their docs are here: Tailscale knowledge base.
Minimal setup:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upThen serve the Gateway over your tailnet only:
sudo tailscale serve --bg https:18789 http://127.0.0.1:18789This gives you remote access without opening a public port to the world.
Layer 4: Add Gateway authentication
Even if the Gateway is private, add auth anyway. Defense in depth means you assume a tunnel config might be wrong someday.
Example token-based auth:
{
"gateway": {
"bind": "127.0.0.1",
"port": 18789,
"auth": {
"enabled": true,
"mode": "token",
"token": "replace-with-a-long-random-token"
}
}
}Generate a token:
openssl rand -hex 32Store it outside of repos. Treat it like an API key.
Layer 5: Restrict who can message the bot
Multi-channel is convenient, but it multiplies the ways someone can reach the agent. Make access explicit per channel.
WhatsApp allowlist example
{
"channels": {
"whatsapp": {
"dmPolicy": "allowlist",
"allowFrom": ["+15551234567"]
}
}
}Telegram allowlist example
{
"channels": {
"telegram": {
"allowFrom": ["@yourusername"],
"groups": {
"*": { "requireMention": true }
}
}
}
}Discord role gating
Discord is good for teams because it has roles. Make “who can trigger actions” a role, not a vibe.
If you need a deeper multi-channel view, see how to run OpenClaw across WhatsApp, Telegram, Discord and Slack.
Layer 6: Tool scoping and least privilege
This is where most people fail because it is less fun than picking a model.
The goal is simple: OpenClaw should only see the files and commands it needs for the job you want it to do.
Filesystem scoping example:
{
"tools": {
"filesystem": {
"allowRead": ["/home/molt/documents", "/home/molt/projects"],
"allowWrite": ["/home/molt/projects/tmp"],
"deny": ["/root", "/etc", "/home/molt/.ssh", "/home/molt/.aws", "/home/molt/.kube"]
}
}
}Shell scoping example:
{
"tools": {
"shell": {
"allowlist": ["ls", "cat", "grep", "find"],
"denylist": ["rm", "chmod", "chown", "sudo", "curl", "wget"]
}
}
}This does two things. It reduces damage from prompt injection, and it reduces damage from honest mistakes. Agents make mistakes. You want those mistakes to be boring.
If you are still deciding between model providers, read Claude vs OpenAI model choice for OpenClaw. Stronger reasoning helps, but it does not replace tool scoping.
Docker sandboxing that is worth doing
Running OpenClaw inside Docker can reduce blast radius if you harden the container.
Here is a hardened docker-compose example you can adapt. It runs as a non-root user, drops Linux capabilities, makes the root filesystem read-only, and binds the Gateway to localhost only.
version: "3.8"
services:
openclaw:
image: openclaw/agent:latest
user: "1000:1000"
read_only: true
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
tmpfs:
- /tmp:rw,noexec,nosuid,size=64M
volumes:
- ./config:/home/openclaw/.openclaw:ro
- ./state:/home/openclaw/state:rw
- ./work:/work:rw
ports:
- "127.0.0.1:18789:18789"
restart: unless-stoppedNotes that matter:
- Do not mount your whole home directory into the container
- Do not run privileged containers
- Keep a single “work” directory that OpenClaw can touch
If you want the canonical Docker hardening guidance, Docker maintains docs on security practices: Docker Engine security.
Step-by-step hardened VPS setup
This is a reasonable baseline on Ubuntu 24.04.
1) SSH hardening
Create a non-root user, use SSH keys, and disable password login.
sudo adduser molt
sudo usermod -aG sudo moltEdit SSH config:
sudo nano /etc/ssh/sshd_configSet these:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers moltRestart:
sudo systemctl restart ssh2) Firewall
Use the UFW rules from earlier. Keep inbound minimal.
3) Install OpenClaw and create a locked config directory
mkdir -p ~/.openclaw
chmod 700 ~/.openclawKeep tokens in environment variables where possible and lock file permissions for anything stored on disk.
4) Bind Gateway to localhost and enable auth
Do this before you add channels. No exceptions.
5) Add channels with allowlists
Start with one channel. Confirm access control is correct. Then add the next one.
6) Add tool restrictions
Start overly strict, then loosen only when you hit a real limitation. This is less painful than tightening later after you have grown comfortable.
7) Add a private tunnel for remote access
Tailscale is the simplest option for most setups. Keep the Gateway private.
Incident response if you suspect compromise
If you think OpenClaw ran something it should not have, treat it as a real incident.
- Stop the service or container
- Rotate all keys and tokens that might be reachable by the agent
- Review logs and channel history for the triggering instruction
- Rebuild the VPS from a clean image if compromise is likely
Do not waste time “cleaning” a VPS you do not trust. Rebuild, then restore only what you understand.
Common mistakes that cause real breaches
- Binding the Gateway to 0.0.0.0
- Opening port 18789 to the public internet
- Running SSH with passwords
- Running the container as root
- Mounting secrets into the agent workspace
- Letting any phone number or username DM the agent
- Giving the agent full shell access because it is “easier”
- Installing skills you have not read
Why a VPS helps security when you do it right
A VPS is not secure by magic. It helps because it is isolated from your personal machine and it is easier to lock down a purpose-built environment than a laptop full of random files.
If you are building a OpenClaw box that stays online, choose a VPS that gives you clean KVM isolation and solid network controls.
