There are hundreds of self-hosted OpenClaw instances running right now with their API endpoints exposed to the public internet. No authentication. No rate limiting. No encryption in transit.
If you're running OpenClaw on a VPS and you haven't explicitly locked down the networking, your instance is probably one of them.
This isn't a hypothetical risk. It's the default state of a standard Docker deployment.
The Five Security Problems
1. Exposed API Endpoints
A default OpenClaw Docker deployment binds to 0.0.0.0:3000. That means the management API — the one that lets you read conversation history, modify agent configuration, and access stored credentials — is accessible to anyone who finds your IP address.
There's no built-in authentication layer. If your VPS firewall isn't configured (or doesn't exist because you're using a basic DigitalOcean droplet), your entire agent's memory and configuration is public.
The fix if self-hosting: Set up Tailscale or WireGuard to create a private network. Only access the management interface through the VPN. Configure iptables to block all external traffic on port 3000.
On Clawfleet: Your instance runs in an isolated container behind our authentication layer. The management API is only accessible through the Clawfleet dashboard, which requires your login credentials and enforces rate limiting.
2. Credential Storage
Your OpenClaw agent needs API keys to function: Anthropic API key, Telegram bot token, email service credentials, CRM tokens, and potentially your clients' credentials.
In a self-hosted setup, these are stored in environment variables or a .env file on disk. If your VPS is compromised, every credential is exposed in plaintext.
Worse — many agencies copy their .env file across multiple instances, so a breach on one VPS exposes credentials for all clients.
The fix if self-hosting: Use a secrets manager (HashiCorp Vault, AWS Secrets Manager, or Doppler). Never store credentials in .env files in production. Rotate keys regularly.
On Clawfleet: Credentials are stored in encrypted key-value storage, separated per instance. Each client's credentials are isolated — a vulnerability in one instance cannot access another's secrets.
3. Unpatched Containers
The OpenClaw Docker image is based on a Node.js base image. That base image has dependencies. Those dependencies have CVEs (Common Vulnerabilities and Exposures) that get discovered regularly.
How often do you rebuild your Docker image? How often do you check for security patches in the base image? Most self-hosters deploy once and never update.
Six months later, they're running an image with 47 known vulnerabilities, 3 of which are rated "critical."
The fix if self-hosting: Set up automated image scanning (Trivy, Snyk, or Docker Scout). Rebuild and redeploy regularly. Pin specific image versions and track upstream security advisories.
On Clawfleet: We patch and update the base infrastructure continuously. Your instance runs on the latest stable version with security patches applied automatically.
4. No Audit Logging
When something goes wrong on a self-hosted instance — a conversation leaks, a credential is misused, or the agent sends something it shouldn't — there's no built-in audit trail.
You can't answer "who accessed the agent at 3am?" or "when was this API key last used?" because there's no logging infrastructure. You added OpenClaw to a VPS. You didn't add monitoring, alerting, or audit logging.
The fix if self-hosting: Deploy a logging stack (ELK, Loki+Grafana, or Datadog). Configure OpenClaw to output structured logs. Set up alerts for anomalous access patterns. This is easily 8–12 hours of additional DevOps work.
On Clawfleet: Every API call, configuration change, and agent action is logged. The dashboard shows activity history per instance, and you can export logs for compliance.
5. Network Security Misconfigurations
Self-hosted OpenClaw typically runs alongside other services on the same VPS. Maybe you're also running a database, a monitoring tool, or another application.
If OpenClaw's container can reach the host network (which is the default Docker networking mode), a compromised agent could potentially access other services on the same machine. This is called "container escape" and it's one of the most common VPS security incidents.
The fix if self-hosting: Run containers with --network=none by default and only expose the specific ports needed. Use Docker's user namespacing. Never run containers as root. Limit container capabilities with --cap-drop=ALL.
On Clawfleet: Each instance runs in full network isolation. One agent cannot see or reach another. The container runtime is hardened with restricted capabilities, no root access, and egress filtering.
The Agency-Specific Risks
For agencies, the security stakes are higher than for individual users. You're handling:
- Client credentials — Ad accounts, analytics access, social media logins
- Client conversations — Potentially sensitive business discussions with the AI agent
- Client data — CRM records, customer lists, financial information
A breach doesn't just affect your agency. It affects every client whose data passes through your OpenClaw instance. That's a legal liability, a contractual violation, and a reputation-ending event.
Agencies running OpenClaw for client work need SOC 2-level security practices. Most agencies don't have the DevOps expertise or budget to implement them on self-hosted infrastructure.
The 21-Step Hardening Checklist
If you do choose to self-host, here's the minimum security configuration you should implement. This list is derived from the common failures we see in exposed instances:
- Configure a firewall (UFW or iptables) blocking all ports except 22 (SSH) and 443 (HTTPS)
- Set up SSH key authentication and disable password login
- Install and configure Tailscale or WireGuard for private network access
- Move the OpenClaw management API behind the VPN — no public access
- Set up Nginx or Caddy as a reverse proxy with SSL termination
- Obtain and auto-renew Let's Encrypt certificates
- Store all credentials in a secrets manager, not
.envfiles - Enable Docker user namespacing
- Run containers with
--cap-drop=ALLand add back only required capabilities - Disable inter-container communication unless explicitly needed
- Set up container resource limits (CPU, memory, disk)
- Install and configure fail2ban for SSH brute-force protection
- Enable automatic security updates for the host OS
- Set up Docker image vulnerability scanning
- Configure structured logging with log rotation
- Set up monitoring and alerting for anomalous activity
- Create and test a backup strategy with encrypted offsite storage
- Document and rotate all API keys on a quarterly schedule
- Set up separate instances (or at minimum, separate containers) per client
- Test your disaster recovery process — can you rebuild from scratch?
- Review this checklist monthly
That's 20+ hours of DevOps work to reach baseline security. And it requires ongoing maintenance — every month, every quarter.
The Managed Alternative
On Clawfleet, all 21 items on that checklist are handled for you. Your instance is deployed into an isolated, hardened container with encrypted storage, no public API access, continuous patching, and audit logging — out of the box.
You spend zero hours on security configuration and zero hours on ongoing maintenance. Your clients' data is protected by infrastructure-level isolation, not by your ability to remember to update iptables rules.
For agencies, this isn't just a convenience. It's a business decision. The cost of a Clawfleet instance is a fraction of the cost of the DevOps hours needed to properly secure self-hosted OpenClaw — and infinitely cheaper than the cost of a data breach.
Secure your OpenClaw deployment without the DevOps burden. Start your $1 trial on Clawfleet — enterprise-grade security from day one.