SECURITY

Securing Your
Self-Hosted Openclaw

2026-01-28 • 14 min read

Why Security Matters More When You Self-Host

When you run Openclaw on your own VPS, you gain privacy and control—but you also inherit the security responsibilities that managed SaaS providers normally handle. The Openclaw/Moltbot docs assume a reasonably hardened Linux host; this article turns that into a practical checklist tailored to the ClawdInstaller flow.

We’ll look at risks across four layers:

  1. VPS & SSH access.
  2. Openclaw gateway & services.
  3. API keys & secrets.
  4. Messaging channels (Telegram, WhatsApp, etc.).

1. VPS & SSH Hardening

Openclaw is “just another process” on your VPS. If someone compromises the VPS, they own Openclaw and everything behind it. Start with basic Linux hardening:

1.1 Create a dedicated user

Don’t run your gateway as root. Use a dedicated user like clawd (the installer already does this, but you can verify): 

sudo useradd -m -s /bin/bash clawd
sudo id clawd

1.2 Restrict SSH

  • Use a strong password or, ideally, SSH keys.
  • In /etc/ssh/sshd_config:
    • Disable root login (PermitRootLogin no after you have a non‑root user).
    • Disable password auth once keys are set up (PasswordAuthentication no).
  • Restart SSH: sudo systemctl restart sshd (or sshd.service depending on distro).

1.3 Firewall + basic intrusion protection

The official Openclaw install guides typically assume you’ll enable a simple firewall and, optionally, fail2ban: 

# Allow SSH + Openclaw gateway (if you expose it)
sudo ufw allow ssh
sudo ufw allow 18789/tcp
sudo ufw --force enable

# Optional: fail2ban for brute-force protection
sudo apt-get install -y fail2ban

Many setups keep the Openclaw dashboard bound to 127.0.0.1 and only expose it via SSH tunnel—which is even safer (no public firewall rule for 18789).

2. Gateway & Service Security

The Openclaw gateway process is what processes user messages and talks to providers. Compromising it means an attacker can impersonate your bot and see all traffic.

2.1 Run as non-root with systemd

A typical service file (similar to the official docs and our installer guide) looks like: 

[Unit]
Description=Openclaw Gateway Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=clawd
Group=clawd
WorkingDirectory=/home/clawd
ExecStart=/home/clawd/.local/bin/openclaw gateway --bind lan --port 18789
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

The critical detail: User=clawd. If that user is compromised, the attacker still doesn’t own root.

2.2 Keep the gateway updated

  • Follow Openclaw/Moltbot release notes and periodically update.
  • Re-run the official install script or update via the documented method (e.g. openclaw self-update if available in your version).
  • Restart the service after updates and verify with systemctl status.

2.3 Don’t expose the dashboard directly to the internet

The Openclaw docs generally treat the dashboard as an internal admin UI. Instead of binding it to 0.0.0.0, keep it on 127.0.0.1 and use SSH tunneling, as shown in our post‑install guide: 

ssh -L 18789:127.0.0.1:18789 clawd@YOUR_VPS_IP
# then visit http://127.0.0.1:18789/ locally

If you absolutely must expose it, put it behind a reverse proxy (nginx, Caddy, or Cloudflare Tunnel) with auth, TLS, and IP allow‑listing.

3. API Keys & Secrets

Openclaw uses API keys for providers like Anthropic (Claude) or OpenAI. Per official guidance:

  • Enter keys only into the setup wizard (`openclaw onboard`) running on your VPS.
  • Never paste them into the installer site or external tools.
  • Store them in the config files under ~/.openclaw/, which the wizard manages for you.

3.1 Rotate keys periodically

Both Anthropic and OpenAI allow you to rotate keys. A safe pattern:

  1. Generate a new key in the provider dashboard.
  2. Run openclaw onboard again and update the key.
  3. Test the assistant.
  4. Delete the old key from the provider dashboard.

3.2 Don’t log secrets

When you’re debugging, be careful not to print full tokens or keys in logs. The Openclaw gateway and installer intentionally avoid logging secrets; follow that pattern in any custom scripts or skills you write.

4. Messaging Channels (Telegram, WhatsApp, etc.)

Telegram bot tokens, WhatsApp Cloud API credentials, and webhook URLs are all powerful secrets. Compromise one and an attacker can impersonate your bot or read user traffic.

  • Store tokens only on the VPS, via openclaw channels login.
  • Use environment variables or Openclaw’s encrypted config mechanisms where documented.
  • Enable two‑factor auth on Telegram/Meta/Facebook accounts that control these bots.
  • For WhatsApp Cloud API, restrict the app to only necessary permissions and keep webhooks scoped to the Openclaw gateway URL.

5. Installer Service & Credentials Handling

ClawdInstaller itself is designed to minimize credential risk:

  • SSH credentials are AES-256 encrypted at rest in the Turso DB.
  • Credentials are used only during the ~5 minute install window.
  • Both the Durable Object and Lambda callback paths explicitly set ssh_password and any SSH key fields to NULL once the install finishes or fails.

Even with that in place, you should treat the installer as one piece of a larger security story:

  • Use unique VPS credentials per customer; don’t reuse root passwords across machines.
  • Consider switching the VPS to SSH‑key‑only auth after installation is complete.
  • Audit Turso access & API tokens periodically.

6. Monitoring & Incident Response

Even with a hardened setup, things can go wrong. Basic observability and response planning goes a long way:

  • Enable and monitor system logs:
    • journalctl -u openclaw -n 100 for recent gateway logs.
    • /var/log/auth.log to spot brute‑force SSH attempts.
  • Keep regular VPS snapshots or backups (most providers support this).
  • Have a plan:
    • Rotate all API keys.
    • Rotate Telegram/WhatsApp tokens.
    • Rebuild the VPS from a clean image if compromise is suspected.

6.1 Let Openclaw Audit Itself (`openclaw security audit`)

The official Moltbot/Openclaw security docs ship a built‑in audit command that uses Claude to reason about your gateway configuration and filesystem state: openclaw security audit (formerly openclaw security audit).[docs.molt.bot] 

# Basic audit
openclaw security audit

# Deeper probe
openclaw security audit --deep

# Apply safe guardrails automatically
openclaw security audit --fix

The audit looks for common “footguns” (over‑open DM/group policies, gateway exposure, weak file permissions, overly permissive plugins, etc.) and, with --fix, can automatically tighten configs back to sane defaults. It’s worth running after any major config change or before you open Openclaw up to more users.[docs.molt.bot]

7. Quick Security Checklist

  • ✅ Non‑root user (clawd) runs the gateway.
  • ✅ SSH hardened (keys only, root login disabled once safe).
  • ✅ UFW firewall enabled; only required ports open.
  • ✅ Dashboard bound to 127.0.0.1 and accessed via SSH tunnel.
  • ✅ API keys only stored on VPS, rotated periodically.
  • ✅ Bot tokens (Telegram/WhatsApp) never committed to Git.
  • ✅ Installer credentials used once, then nulled from DB.
  • ✅ Logs monitored; backup and incident plan in place.

Combined with ClawdInstaller’s zero‑retention approach to SSH creds, these practices let you enjoy the privacy benefits of a self‑hosted AI assistant without sleep‑losing levels of risk.

← Back to Blog