If you're deploying OpenClaw on a VPS, chances are you've found plenty of tutorials that walk you through spinning up a server and running the install script. What none of them tell you is how to think about what you've actually built—and more importantly, what's exposed. A DEV.to post from developer dean0x drops the guide that should have existed from day one: a risk-surface-first breakdown of four security postures for self-hosted AI gateways, ranging from 'just me on a weekend project' to full enterprise SSO with device posture checks.

What Is an AI Gateway, Really

Before diving into hardening, you need to understand the asset you're protecting. OpenClaw runs as a single long-running process sitting between your messaging channels (Telegram, Discord, Slack, WhatsApp) and your LLM providers (OpenAI, Anthropic, local models). Users hit a bot; the gateway dispatches messages to an agent; the agent calls an LLM and responds. The gateway holds three categories of secrets: LLM provider credentials, channel bot tokens, and its own dashboard auth token. Everything else—agent configs, session history, workspaces—is state, not secrets. That distinction matters because it determines how you protect each piece.

The Four Security Levels

The post frames security as four progressive levels, each shippable independently. Level 1 (Personal) covers host hardening, firewall rules, and loopback-only gateway access—ideal if you're the only user accessing the dashboard over SSH tunnel. Level 2 (Small Team) adds Cloudflare Tunnel with Access or Tailscale ACLs for identity-aware edge protection, config hardening, and session isolation. This is where most two-to-five person teams should land. Level 3 (Production) brings secrets manager integration so no plaintext credentials sit on disk, plus systemd hardening—necessary if you're facing compliance audits like SOC 2 or ISO 27001. Level 4 (Enterprise) layers in SSO, trusted-proxy auth, device posture checks via WARP, SSH certificates, and infrastructure-as-code governance.

What's Actually at Risk

The risk surface analysis is where this guide earns its keep. The author ranks exposure by likelihood: open port scanning happens within minutes of a VPS going live; exposed dashboards with shared tokens are trivial to reach if you skip identity-aware access; leaked or unrevoked tokens from departed employees represent the most common real-world breach vector at small teams; prompt injection in chat channels can escalate if tool access isn't restricted; and plaintext secrets on disk become catastrophic if any account gets compromised. The key insight: layered security means an attacker needs to break multiple independent systems to reach anything sensitive.

Picking Your Tunnel

Cloudflare Tunnel plus Access gives you a public hostname with identity verification, DDoS absorption at the edge, and CDN benefits—all free for most small teams. The tradeoff is moving DNS to Cloudflare and routing your traffic through their infrastructure. Tailscale offers device-to-device access over WireGuard without any public hostname; devices on your tailnet reach each other directly, but every user needs the client installed. For personal use, rolling your own with nginx and Let's Encrypt works fine until you realize you're back in the certificate management and port-exposure business.

Traps That'll Waste Your Weekend

Two specific gotchas stand out as must-knows for anyone deploying on cloud VMs. First: IPv6 routing issues cause misleading "DNS lookup failed" errors when Node.js resolves an unreachable IPv6 address that your provider doesn't actually route. The fix is a single environment variable telling Node to prefer IPv4—check this before blaming datacenter IP blocks or downgrading versions. Second: OAuth-backed providers (subscription ChatGPT accounts rather than API keys) sometimes route certain paths through bot-mitigation layers that return HTML block pages instead of JSON responses, making the gateway report connection errors when the real problem is upstream filtering.

When to Level Up

The upgrade signals are concrete. Move from Level 1 to 2 when a second person needs dashboard access or you want browser-based access without SSH forwarding. Graduate to Level 3 when someone asks about your secrets-at-rest posture in due diligence or you're uncomfortable with plaintext API keys in config files. Head to Level 4 when you can't track who has the shared token, need per-user audit trails, or your team exceeds five people requiring SSO integration.

Operational Hygiene Beats Fancy Tools

The author's closing argument cuts through security theater: most breaches at small companies aren't zero-days—they're access that should have been revoked, tokens that should have rotated, hosts that should have patched. Quarterly access reviews (calendar it), an offboarding runbook tested before you need it, and automated security audits on a schedule matter more than AppArmor profiles or custom WAF rules you'll never maintain. The post includes a reusable setup prompt for coding agents that walks through all four levels interactively—no environment-specific assumptions baked in.

Key Takeaways

  • Security levels are incremental—ship Level 1, stop when you've hit the right posture for your situation
  • Shared bearer tokens work fine at Levels 2-3 where identity-aware access gates the edge first
  • Trusted-proxy auth requires containerized tunnel daemons with non-loopback IPs—don't try it on day one
  • Check IPv6 routing before debugging "DNS failures" from Node.js on cloud VMs
  • Quarterly access reviews and tested offboarding runbooks outperform most security tooling