Tailscale and UFW Are a Good Start. Here Is Why They Are Not Enough.

If you have done this on your OpenClaw VPS, you are already ahead of most operators:

1. Installed Tailscale and joined your server to a tailnet
2. Configured OpenClaw to bind to loopback so the gateway is only reachable through Tailscale
3. Set up UFW with default deny incoming and SSH allowed only on the Tailscale interface
4. Installed and enabled Fail2ban
5. Set up an allowlist so only your number can message the bot
6. Ran openclaw security audit --deep

That is a real security posture. It puts you in a better position than the 135,000+ instances sitting on 0.0.0.0:18789 with no firewall, no proxy, and no authentication. You should feel good about it.

But here is the thing: every item on that list was a manual step. And manual steps have a shelf life.

What Tailscale actually gives you

Tailscale is excellent software. It creates an encrypted mesh network between your devices using WireGuard under the hood. When you bind OpenClaw to loopback and access it only through Tailscale, you have effectively removed the public attack surface. Nobody can reach your instance unless they are on your tailnet.

That solves the exposure problem documented in our earlier article about 135,000 exposed OpenClaw instances. If the gateway is not listening on a public interface, there is nothing to scan and nothing to connect to. That is genuinely good.

What Tailscale does well:

• Encrypted tunnel between your devices and your server
• No inbound ports required (outbound-only NAT traversal)
• Identity-based access control through Tailscale ACLs
• Simple setup -- usually one command to join the tailnet

What UFW and Fail2ban add

UFW blocks everything except what you explicitly allow. Fail2ban watches for brute-force patterns and temporarily bans offending IPs. Together they handle the two most common attack vectors on a VPS: port scanning and SSH bruteforcing.

A typical hardened config looks like this:

ufw default deny incoming
ufw default allow outgoing
ufw allow in on tailscale0 to any port 22
ufw --force enable

That is a solid baseline. SSH is only reachable through the Tailscale interface. Everything else is blocked.

So what is missing?

The setup above protects one server running one agent. It works. But it has structural limitations that become more visible as your needs grow.

1. No edge protection

Tailscale creates a private mesh, but it does not provide edge security services. There is no DDoS mitigation, no rate limiting, no WAF, and no bot detection. If you ever need your agent to be reachable by external services -- webhooks from Slack, Discord callbacks, API integrations -- you have to punch a hole in the private mesh and handle edge security yourself.

LaunchThatBot routes all traffic through Cloudflare Tunnels. That means DDoS protection, rate limiting, and TLS termination happen at the edge before traffic reaches your container. Your server's IP address is never exposed in DNS records. There is nothing to scan because there is no A record pointing to your VPS.

2. No container isolation

When you install OpenClaw directly on a VPS with Tailscale, the process runs on the host's network stack. It shares resources, filesystem access, and process space with everything else on that machine. If the OpenClaw process is compromised -- through a tool exploit, a prompt injection that escapes the sandbox, or a vulnerability in a connected MCP server -- the attacker has access to the host.

LaunchThatBot runs every agent inside an isolated container. The container has its own network namespace, its own filesystem, and its own process tree. A compromised agent cannot see other agents, cannot access the host filesystem, and cannot interact with other deployments on the same server.

3. Manual maintenance does not scale

Here is what ongoing security maintenance looks like for a single Tailscale + UFW server:

• Monitor Tailscale ACLs as you add devices or team members
• Keep UFW rules updated as your networking needs change
• Review Fail2ban logs for patterns that need attention
• Apply OpenClaw security patches when they ship
• Rotate API keys stored in .env files
• Update the OS and all packages for security fixes
• Renew or manage TLS certificates if you expose any endpoints

Now multiply that by ten agents across three servers. Or fifty agents across twelve servers. Each one needs its own Tailscale node, its own UFW rules, its own Fail2ban configuration, its own key rotation schedule. There is no dashboard. There is no unified view. You are SSH-ing into each machine individually.

LaunchThatBot applies a security profile at provisioning time. Every server gets UFW, Fail2ban, SSH hardening, and (in the production profile) unattended security updates -- automatically. The Cloudflare Tunnel is configured during deployment. You never touch a firewall rule or an SSH config.

4. Secrets live on the host in plaintext

In a typical Tailscale + UFW setup, your API keys (OpenAI, Anthropic, whatever provider you use) sit in a .env file on the host filesystem. That file is readable by the OpenClaw process, by root, and by anyone who gains shell access to the machine.

There is no rotation. There is no audit trail. There is no way to know if someone read the file without checking access logs that most operators never configure.

LaunchThatBot stores secrets in the user's own Convex environment variables -- encrypted at rest, scoped to the deployment, and verifiable through the Convex dashboard. The .env file inside the container receives only what that specific agent needs, injected at runtime.

5. No separation of operator and bot surfaces

When you access your OpenClaw instance through Tailscale, both your management interface and your bot's operational endpoints share the same access path. If you share your tailnet with a teammate so they can interact with the bot, they also have access to the operator controls.

LaunchThatBot separates these surfaces architecturally. The operator dashboard, deployment controls, and configuration UI are behind authenticated access on a per-user subdomain. Bot-facing routes (webhooks, chat endpoints, API integrations) are independently configurable with their own access policies.

The comparison is not about quality

Tailscale is genuinely good software. UFW does exactly what it is supposed to do. Fail2ban handles brute-force mitigation well. The security audit command in OpenClaw catches real issues.

The gap is not in the quality of these tools. It is in the model.

The DIY approach requires you to be the security engineer. You pick the tools, you configure them, you maintain them, you monitor them, and you respond when something needs attention. For one agent on one server, that is manageable. For a fleet, it becomes a full-time responsibility.

What LaunchThatBot adds beyond the DIY stack

Here is a direct comparison of what you get with each approach:

Capability	Tailscale + UFW	LaunchThatBot
Firewall	UFW (manual config)	UFW (auto-configured at provisioning)
Brute-force protection	Fail2ban (manual)	Fail2ban (auto-configured)
Private ingress	Tailscale mesh	Cloudflare Tunnels (outbound-only)
DDoS protection	None	Cloudflare edge
TLS certificates	Manual or Tailscale certs	Cloudflare (automatic)
Container isolation	None (bare process)	Docker per agent
Secrets management	Plaintext .env on host	Convex env vars (encrypted, auditable)
SSH hardening	Manual	Auto-applied (production profile)
Security updates	Manual	Unattended-upgrades (production profile)
Operator/bot separation	Same access path	Separate subdomains and access policies
Multi-agent scaling	Manual per server	Managed fleet-wide
Access control	Tailscale ACLs	Cloudflare Access + tenant isolation

The right choice depends on your situation

If you are running a single agent for personal use and you enjoy the hands-on security work, the Tailscale + UFW approach is solid. Keep doing it. The security checklist we published can help you verify you have not missed anything.

If you are running multiple agents, or you want to stop worrying about whether you remembered to update the firewall rules on server three, or you need your agents to be reachable by external services without punching holes in a private mesh -- that is the problem we built LaunchThatBot to solve.

The security is structural, not manual. It comes from the architecture, not from remembering to run the right commands.

See how the deployment security works.

References

• OpenClaw docs, "Remote access (SSH, tunnels, and tailnets)": docs.openclaw.ai
• OpenClaw docs, "Security": docs.openclaw.ai
• Tailscale, "How Tailscale works": tailscale.com
• Cloudflare Tunnel documentation: developers.cloudflare.com
• Bitdefender, "135,000+ OpenClaw AI agents exposed online": bitdefender.com