How to Secure Your OpenClaw Deployment (And What Most People Get Wrong)

In early 2026, security researchers discovered over 42,000 publicly exposed OpenClaw instances. Gateways running with no authentication, accessible to anyone on the internet. Shortly after, six CVEs were filed, including a critical Remote Code Execution vulnerability (CVE-2026-25253) that could be triggered with a single HTTP request.

Most of those 42,000 instances weren't run by careless people. They were run by developers who followed a tutorial, got the agent working, and assumed "working" meant "secure."

It doesn't. Here's what a properly secured OpenClaw deployment actually looks like.

The Core Risk: An Open Gateway

OpenClaw's gateway is the interface between the outside world and your agent. It handles incoming messages, executes tasks, and exposes the dashboard UI. If this gateway is accessible without authentication, anyone who finds it can interact with your agent, read its memory, execute commands, and potentially compromise the server it runs on.

The most common misconfiguration looks like this:

gateway running on 0.0.0.0:18789, no auth token set

This means the gateway is listening on all network interfaces, publicly reachable, with no password. Security scanners like Shodan index these automatically.

What Proper Security Actually Requires

Securing a self-hosted OpenClaw instance is not one step. It's a stack of decisions that all need to be right.

1. Always Set a Gateway Token

OpenClaw's gateway supports token-based authentication. You must set it:

node dist/index.js gateway --token your-secret-token-here

Without this flag, the gateway accepts all requests. The token should be long, random, and treated like a password. Do not use the same token across multiple instances.

2. Bind the Gateway to Localhost Only

The gateway should never listen on 0.0.0.0. Bind it to 127.0.0.1 so it is only reachable from the same machine:

node dist/index.js gateway --bind lan --token your-token

Verify this worked:

ss -tlnp | grep 18789
# Should show 127.0.0.1:18789, NOT 0.0.0.0:18789

If you see 0.0.0.0:18789, the gateway is exposed. Stop it immediately and restart with the correct bind flag.

3. Put a Reverse Proxy in Front

Direct access to the gateway port should never be the public endpoint. Use nginx (or Caddy) as the public-facing layer:

server {
    listen 443 ssl;
    server_name your-agent.yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    }
}

This gives you a single controlled entry point where you can enforce HTTPS, add rate limiting, and log access.

4. Enforce HTTPS

Running the dashboard over plain HTTP means your gateway token is transmitted in cleartext on every request. Anyone monitoring the network between you and your server can intercept it.

Use Let's Encrypt via Certbot to provision a free SSL certificate:

certbot --nginx -d your-agent.yourdomain.com --non-interactive --agree-tos --redirect

After this, Certbot will automatically redirect all HTTP traffic to HTTPS and renew the certificate before it expires.

5. Lock Down Your Firewall

Your VPS firewall should only allow traffic on the ports you actually need. For most OpenClaw deployments, that's SSH, HTTP, and HTTPS. Nothing else.

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw --force enable

Critically: do not add a firewall rule for port 18789. If the gateway is properly bound to localhost and proxied through nginx, it should never need a public firewall rule.

6. Never Run as Root

Running OpenClaw as root means a compromised process has full access to your server. Create a dedicated user:

useradd -m -s /bin/bash openclaw
su - openclaw
# run openclaw from here

If an attacker finds a way to execute code through your agent, they're contained to the openclaw user's permissions instead of having root access to everything.

7. Keep OpenClaw Updated

Six CVEs were filed against OpenClaw in less than three months of 2026. One was critical. If you're running a version that's more than a few weeks old, you may already be vulnerable to a known exploit.

Set a reminder to check for updates at least weekly:

npm install openclaw@latest

And verify your running version matches:

node dist/index.js --version

8. Be Careful With Skills

ClawHub, the community skills registry, had 824+ malicious skills identified in early 2026. A compromised skill runs inside your OpenClaw environment and can access your API keys, read your memory files, and make outbound requests.

Only install skills from sources you trust. Treat installing a skill like installing software. Read what it does before you run it.

What This Looks Like in Practice

A properly secured self-hosted OpenClaw deployment has all of the following:

Requirement	Status
Gateway token set	✅ Required
Gateway bound to localhost	✅ Required
HTTPS via nginx + Let's Encrypt	✅ Required
Firewall blocks direct gateway access	✅ Required
Running as non-root user	✅ Strongly recommended
Auto-updates or update monitoring	✅ Strongly recommended
Skills reviewed before install	✅ Strongly recommended

If any item in the first four rows is missing, your deployment has a meaningful security exposure.

The Pairing System as a Defense Layer

One underappreciated security feature in OpenClaw is its pairing system. When a new user sends your bot a message on Telegram or Discord, OpenClaw does not respond until you explicitly approve them. Even if someone finds your bot and starts messaging it, they get nothing until you pair them.

This is particularly valuable for public-facing bots. The pairing approval means your agent is inherently semi-private. You control who can interact with it at the messaging layer, independently of the gateway token.

Why Most People Still Get This Wrong

The gap between "getting OpenClaw running" and "running OpenClaw securely" is significant. Most tutorials optimize for getting the agent up as fast as possible. Firewall configuration, certificate provisioning, gateway binding: these steps come after the agent is working, so they get skipped.

The result is the 42,000-instance problem. Every one of those deployments had OpenClaw working. None of them had it secured.

If You Don't Want to Think About Any of This

All of the above, gateway isolation, HTTPS enforcement, firewall rules, token management, and update monitoring, is handled automatically when you deploy through Clawdtopia.

Every instance gets its own dedicated server environment with the gateway properly isolated, HTTPS enforced, and the firewall configured correctly out of the box. Your API keys and bot tokens go directly into your instance and are never stored in our database.

If your goal is to use OpenClaw rather than secure it, that's what Clawdtopia is for.