A Practical Security Checklist for Solo OpenClaw Operators

This article is for you if you are running OpenClaw on a VPS and want to make sure you are not making the common mistakes that leave 135,000+ instances exposed.

We are publishing this regardless of whether you use LaunchThatBot. If you are self-hosting, you deserve a clear, actionable guide -- not vague advice about "following best practices."

1. Check your bind address

This is the single most important configuration to verify. Open your OpenClaw configuration and find the bind address setting.

If it says 0.0.0.0:18789 or just :18789 without a specific address, your instance is listening on every network interface on the host. That includes the public interface.

Fix: Change the bind address to 127.0.0.1:18789. This restricts OpenClaw to only accept connections from the local machine.

After making the change, verify from an external machine:

# From a different machine, try connecting to your VPS IP on port 18789
nc -zv YOUR_VPS_IP 18789
# This should fail/timeout if the fix is working

2. Set up a reverse proxy with authentication

Binding to localhost keeps OpenClaw off the public internet, but you still need a way to access it remotely. The answer is a reverse proxy (nginx, Caddy, or Traefik) that handles TLS and authentication before forwarding requests to localhost.

Key requirements for the proxy configuration:

• Terminate TLS at the proxy (use Let's Encrypt or Cloudflare origin certificates)
• Add HTTP basic auth or a more robust authentication layer
• Forward only to 127.0.0.1:18789, never to 0.0.0.0
• Set appropriate headers (X-Forwarded-For, X-Real-IP) if your agent needs client info

Common mistake: configuring the reverse proxy but leaving port 18789 open in the firewall. The proxy does not help if the underlying port is still directly reachable. Always verify with an external port scan after setting up the proxy.

3. Configure your firewall

Your VPS should have a firewall that explicitly allows only the ports you need:

• 22 (SSH) -- ideally restricted to your IP or a VPN
• 80/443 (HTTP/HTTPS) -- for the reverse proxy
• Everything else blocked by default

On most Linux VPS hosts:

# UFW example
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

After enabling the firewall, verify that port 18789 is not reachable externally. This is the most common gap -- people configure OpenClaw correctly but forget the firewall step.

4. Audit your secrets and API keys

OpenClaw agents often connect to external services: LLM providers, databases, APIs, SaaS tools. Each connection involves credentials that need to be stored somewhere.

Check for these common problems:

• API keys stored in plaintext .env files with overly broad permissions
• Keys committed to git repositories (even private ones)
• The same key used across development, staging, and production
• No rotation schedule -- keys that have not been changed since initial setup

Minimum standard: store secrets in environment variables that are injected at runtime, not baked into config files. Use a password manager or secrets manager for the source of truth. Rotate keys on a schedule, even if it is only quarterly.

5. Keep OpenClaw and dependencies updated

OpenClaw has had real security advisories. GHSA-g8p2-7wf7-98mq documented a vulnerability where the Control UI trusted attacker-controlled URLs and leaked gateway tokens. This was patched, but only if you applied the update.

Set a reminder to check for OpenClaw updates at least monthly. Subscribe to the GitHub repository's release notifications so you hear about security patches when they ship.

Also audit the tools and plugins connected to your agent. If your OpenClaw instance has file system access, code execution capabilities, or network access, a compromise of the agent is a compromise of everything those tools can reach.

6. Separate your operator UI from bot endpoints

If your management interface (the UI you use to configure and monitor your agent) and your bot's public-facing endpoint share the same domain and port, you have a trust boundary problem.

An attacker who discovers your bot's public URL also discovers your management UI. If the management UI has weak or no authentication, they can take control.

Fix: use different subdomains or different ports for operator and bot traffic. Apply authentication to the operator surface. Consider using Cloudflare Access or a similar zero-trust tool to gate operator access entirely.

7. Monitor for unexpected connections

Set up basic monitoring so you know when something unexpected happens:

• Log reverse proxy access and review periodically for unusual patterns
• Set up alerts for failed authentication attempts
• Track OpenClaw process resource usage -- unexpected CPU or memory spikes can indicate compromised agents running unauthorized workloads

If you are using a VPS provider that offers monitoring dashboards (most do), check them weekly.

8. Consider your backup and recovery plan

If your instance is compromised, you need a plan that is not "rebuild from scratch and hope I remember the configuration."

• Back up your agent configuration regularly (but not your secrets -- those come from a separate secrets manager)
• Document your deployment steps so you can rebuild quickly
• Test your restore process at least once

The honest assessment

Every item on this list is something LaunchThatBot handles structurally -- through container isolation, tunnel-based ingress, subdomain separation, and managed operations. Not because self-hosting is wrong, but because most solo developers have better things to do with their time than maintain security infrastructure.

If you want to self-host, this checklist will get you to a reasonable baseline. If you would rather spend that time building agents, here is how LaunchThatBot works.

References

• OpenClaw docs, "Security": docs.openclaw.ai
• OpenClaw docs, "Remote access": docs.openclaw.ai
• GitHub Security Advisory GHSA-g8p2-7wf7-98mq: github.com
• AI Maker, "OpenClaw Security Hardening Guide": aimaker.substack.com