If you've tried to self-host an AI gateway like OpenClaw, you've probably noticed something frustrating: every tutorial stops right before the hard part. They'll get you from 'apt update' to 'it's running,' then leave you staring at a dashboard with zero guidance on what happens when someone actually pokes at it. That's the gap this post fills—not just the commands, but the mental model for deciding how much security your deployment actually needs.

What You're Actually Deploying

An AI gateway like OpenClaw is a single long-running process sitting between your messaging channels (Telegram, Discord, Slack, WhatsApp) and your LLM providers (OpenAI, Anthropic, local models). Users talk to a bot; the gateway dispatches messages to an agent; the agent calls an LLM and responds. There's also a web dashboard for configuration and monitoring. The critical distinction: this process holds three categories of secrets—LLM provider credentials, channel bot tokens, and its own auth token—and everything else (agent configs, session history, workspaces) is state that needs backup, not encryption.

Why Bother Self-Hosting?

Managed platforms handle security, scaling, and uptime for you. But they also dictate which models you can use, what data flows where, and how much you pay per seat. For a small team that wants specific models, data on their own infrastructure, or relief from per-user SaaS pricing, self-hosting makes sense. The catch: security is now your responsibility. Nobody's patching the host, rotating secrets, or monitoring access logs unless you set it up.

The Four Security Levels

Not every deployment needs Fort Knox. Most guides get this backwards—either 'we'll add security later' (and never do) or 'enterprise-grade auth on day one' (and stall under complexity). Think of it as four levels, each building on the last: Level 1 (Personal) covers host hardening, firewall, and loopback-only gateway for solo use. Level 2 (Small team) adds Cloudflare Tunnel + Access and config hardening for teams under five people who trust each other. Level 3 (Production) introduces secrets manager integration with zero plaintext on disk—essential if anyone asks about your secrets-at-rest posture for SOC 2, ISO 27001, or due diligence. Level 4 (Enterprise) adds SSO, trusted-proxy auth, device posture checks, and infrastructure-as-code governance for teams that need per-user identity end-to-end.

The Real Threat Surface

When you put a gateway on a public server, here's what actually goes wrong in rough order of likelihood: automated scanners hitting open ports within minutes (fix: no inbound web ports via outbound tunnel), someone reaching the dashboard without authorization if there's no identity-aware edge, leaked or unrevoked shared tokens (the 'access that should have been revoked three jobs ago' problem), prompt injection through chat channels enabling unrestricted tool access, and plaintext secrets on disk readable by anyone who can access the config file. Things NOT worth optimizing for at small scale: zero-day exploits in Node.js, cloud provider data-at-rest access, npm supply-chain attacks. Real risks, but your time is better spent on the five items above.

Tunnel Smackdown: Cloudflare vs Tailscale

Two mainstream options get you off port 443 and into identity-aware access. Cloudflare Tunnel + Access gives you a public hostname protected by identity verification, DDoS absorption, and CDN—free tier covers most small teams. The tradeoff: traffic flows through Cloudflare and you need to move DNS there (or at least the subdomain). Tailscale gives device-to-device access over WireGuard with no public hostname needed; devices on your tailnet reach each other directly. Tradeoff: every user needs Tailscale installed and there's no identity-aware edge for a public URL. Great for 'only our devices can reach this, period.' Rolling your own nginx + Let's Encrypt is fine for personal use but puts you back in certificate management and DDoS exposure land.

The Traps That'll Waste Your Weekend

Two specific issues that bit the author and will probably bite you: IPv6 on cloud VMs causes misleading 'DNS lookup failed' errors when Node.js defaults to an unreachable IPv6 address—test with curl -4 vs curl -6, fix with a one-line environment variable forcing IPv4 preference. OAuth endpoint paths get caught in bot-mitigation layers that return HTML block pages instead of JSON API responses—the gateway reports 'connection error' and masks the real problem until you bypass it and test upstream directly with curl.

The Shared-Token Problem (And When It Stops Being Fine)

At Levels 1-3, OpenClaw uses a shared bearer token. Everyone accesses the dashboard with the same credential—no per-user audit trail, no revocation without rotating for everyone. This bugs people, but it's fine at small scale because Cloudflare Access authenticates per-user at the edge before anyone even sees the token form. The pragmatic posture: share through a password manager, rotate on team changes or every 90 days (whichever comes first), and plan migration to per-user auth around five to ten users. When you can't track who has the shared token anymore, that's your signal to level up.

Key Takeaways

  • Deploy in layers: each addresses a different failure mode and fails independently—misconfigured firewall doesn't matter if the gateway is on loopback behind a tunnel.
  • Use an outbound tunnel (Cloudflare Tunnel or Tailscale) so there's nothing for scanners to find—no inbound ports, no probe surface.
  • Don't conflate secrets with state: credentials need protection at rest; session history needs backup and isolation.
  • The shared token is defense-in-depth, not primary access control—Access handles identity, the token guards against bypass attempts.
  • Quarterly access reviews are boring but the single most effective security practice for small teams.

The Bottom Line

The gap between 'it runs' and 'it's hardened' isn't a weekend of work—it's understanding which layer you're actually missing. Most deployments need Level 2: an outbound tunnel with identity-aware access and config hardening against prompt injection. That's shippable on day one. Everything else comes when your situation demands it, not because a checklist said so.