Harden Your Self-Hosted Instance

This guide covers the steps needed to secure a self-hosted OpenClaw instance. The hardening steps are the same regardless of which cloud provider you use — the differences between providers are limited to firewall configuration syntax, which is noted where relevant. The steps are ordered by impact. Work through them in sequence.

If you’d rather shut down your instance entirely instead of hardening it, see Terminate Your Instance. Not sure which path to take? See the Security Overview for context.

Before you start

Check if you’re already exposed. Look up your server’s public IP on the OpenClaw Exposure Watchboard. If your instance appears there, it is actively reachable from the internet. Find your public IP with:

curl -s https://ifconfig.me

If you are on the watchboard, assume your instance may have already been accessed and rotate all credentials after completing these steps.

Step 1: Update OpenClaw

The single most impactful step is running a current version. Several critical vulnerabilities — including the ClawJacked WebSocket hijack (CVE-2026-25253, CVSS 8.8) — were patched in v2026.2.25. Older versions remain vulnerable regardless of other hardening steps.

openclaw update

Verify your version:

openclaw --version

You should be on v2026.2.25 or later. The full list of security advisories is maintained on the OpenClaw GitHub security page.

Do not run openclaw update or npm install -g openclaw inside a running Coral sandbox — this causes a supervisord retry race and puts the instance into a FATAL state. Coral handles OpenClaw updates automatically.

Step 2: Block the gateway port

This is the most impactful single step for instances running on a public VPS. OpenClaw’s gateway listens on port 18789 by default. Blocking inbound access to this port from the internet makes your instance invisible to the scanners that found 258,305 exposed instances.

UFW (Ubuntu/Debian)
firewalld (RHEL/CentOS/Fedora)
iptables
Cloud firewall console

sudo ufw default deny incoming
sudo ufw allow ssh
sudo ufw enable
sudo ufw status

If you need to allow access from a specific trusted IP only:

sudo ufw allow from YOUR_TRUSTED_IP to any port 18789

sudo firewall-cmd --set-default-zone=drop
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

# Drop all inbound except SSH
sudo iptables -P INPUT DROP
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Save rules
sudo iptables-save > /etc/iptables/rules.v4

Step 3: Bind the gateway to localhost

Even with a host firewall, configure OpenClaw itself to listen only on the loopback interface. This is a defense-in-depth measure: if a firewall rule is ever misconfigured or temporarily disabled, the gateway is not reachable from the network. Edit ~/.openclaw/openclaw.json (JSON5 format):

{
  gateway: {
    bind: "loopback"   // Only listen on 127.0.0.1
  }
}

Restart the gateway after making changes:

openclaw restart

On versions prior to v2026.1.29, the default was "all" (binds to 0.0.0.0). On v2026.1.29 and later, "loopback" is the default — verify your config explicitly if you upgraded from an older version.

Step 4: Enable strong authentication

Verify that authentication is configured and set a strong auth token (32+ characters):

openclaw config set auth.mode token
openclaw config set auth.token "$(openssl rand -hex 32)"

To view your current token:

openclaw config get auth.token

Do not reuse this token as a password anywhere else. Store it in a password manager. Anyone who obtains this token has full control of your agent and everything it’s connected to.

Step 5: Use zero-trust access for remote connections

If you need to access your instance remotely, use a zero-trust tunnel instead of opening ports. Tailscale is the most commonly cited option in community hardening guides — it creates an encrypted overlay network and makes your instance completely invisible to internet scanners. Install Tailscale on your server:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Once connected via Tailscale, access your OpenClaw gateway over the Tailscale IP. Your gateway remains bound to localhost; a local port forward through the Tailscale connection brings it to your client machine. WireGuard is an alternative if you prefer to manage your own VPN infrastructure.

Step 6: Put a reverse proxy in front

If you need public HTTPS access (e.g., for webhook integrations), put a reverse proxy in front of the gateway rather than exposing the gateway port directly. The proxy adds TLS termination, authentication headers, and rate limiting.

Caddy
Nginx

Caddy handles TLS certificates automatically via Let’s Encrypt.

your-domain.example.com {
    basicauth /* {
        # Generate password hash: caddy hash-password
        youruser $2a$14$...hash...
    }
    reverse_proxy 127.0.0.1:18789
}

See Caddy documentation for full configuration options.

server {
    listen 443 ssl;
    server_name your-domain.example.com;

    ssl_certificate /etc/letsencrypt/live/your-domain.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.example.com/privkey.pem;

    auth_basic "OpenClaw";
    auth_basic_user_file /etc/nginx/.htpasswd;

    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;
    }
}

See Nginx documentation and HAProxy’s OpenClaw authentication guide for further options.

Step 7: Lock down file permissions

OpenClaw credential files in ~/.openclaw/ are protected only by filesystem permissions. Restrict access:

chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/credentials/*
chmod 600 ~/.openclaw/openclaw.json

Run OpenClaw under a dedicated non-root service user. Do not run as root or your personal user account:

sudo useradd --system --shell /bin/false openclaw-svc
sudo -u openclaw-svc openclaw start

Step 8: Audit and lock down skills

Koi Security audited the ClawHub marketplace and found 341 malicious skills out of 2,857 reviewed. One of them was the #1 most-downloaded skill. The count later grew to 1,184 as more were identified. For each installed skill:

Review the skill’s source code before enabling it
Check the ClawHavoc report for the skill name
Disable any skill you didn’t explicitly install or can’t verify

Disable automatic skill installation in ~/.openclaw/openclaw.json:

{
  skills: {
    autoInstall: false
  }
}

Enable Docker sandbox isolation for tool execution (this limits the blast radius if a skill is malicious):

openclaw config set sandbox.mode docker

Step 9: Rotate all secrets

If your instance was ever publicly reachable — even briefly — assume that credentials may have been read. Rotate everything the agent had access to:

Gateway token — Generate a new one as described in Step 4
LLM API keys — OpenAI, Anthropic, Google, or any other provider key stored in ~/.openclaw/
Connected account tokens — Any OAuth tokens or API keys for integrations (Gmail, Slack, GitHub, Notion, etc.)
SSH keys — If the agent had SSH access, generate new keys and remove old authorized keys

For each integration, revoke the old token/OAuth grant and create a new one with the minimum scope needed.

Step 10: Ongoing monitoring

Enable audit logging

OpenClaw records session transcripts (tool calls, arguments, results) as local files. Enable and review these regularly:

openclaw config set logging.level audit

For centralized logging (recommended if the host is shared), configure the optional OpenTelemetry exporter documented in the OpenClaw docs.

Run the built-in security audit

OpenClaw ships a built-in security check command:

openclaw security audit --deep

Run this after initial hardening and periodically thereafter. It checks authentication configuration, network binding, file permissions, and known-vulnerable skill versions.

Monitor for brute-force attempts

Install fail2ban to automatically block IPs that repeatedly fail authentication:

sudo apt-get install fail2ban

Configure a jail for OpenClaw’s auth log path. See the fail2ban documentation for setup details.

Pin versions and review changelogs

OpenClaw has had 90+ security advisories. Pin to a specific version and review the release notes and security advisories before updating:

openclaw config set updates.auto false

Community hardening guides

The security community published extensive hardening resources in response to the 2026 exposure crisis. The following guides are cited sources for this documentation:

Next steps

If you’ve completed the steps above but would rather move to a managed setup where this hardening is handled for you, see how Coral approaches OpenClaw security. If you’ve decided to shut down your instance entirely, see Terminate Your Instance.

Overview

Self-Hosted Hardening

Terminate Your Instance

​Before you start

​Step 1: Update OpenClaw

​Step 2: Block the gateway port

​Step 3: Bind the gateway to localhost

​Step 4: Enable strong authentication

​Step 5: Use zero-trust access for remote connections

​Step 6: Put a reverse proxy in front

​Step 7: Lock down file permissions

​Step 8: Audit and lock down skills

​Step 9: Rotate all secrets

​Step 10: Ongoing monitoring

​Community hardening guides

​Next steps

Before you start

Step 1: Update OpenClaw

Step 2: Block the gateway port

Step 3: Bind the gateway to localhost

Step 4: Enable strong authentication

Step 5: Use zero-trust access for remote connections

Step 6: Put a reverse proxy in front

Step 7: Lock down file permissions

Step 8: Audit and lock down skills

Step 9: Rotate all secrets

Step 10: Ongoing monitoring

Community hardening guides

Next steps