OpenClaw is open-source and self-hostable. That's not in question. What's worth examining in real technical detail is what keeping a self-hosted instance genuinely secure actually requires on an ongoing basis — not as a hypothetical, but against the platform's real, publicly-tracked disclosure history.
The disclosure history is real, and it's not small
OpenClaw has accumulated well over 100 publicly tracked CVEs and GitHub Security Advisories. That's not unusual for a fast-growing, widely-adopted open-source project — disclosure volume often correlates with active use and scrutiny, not just bad code. But it means "install it once" is never the actual security posture; "patch continuously, correctly, and promptly" is.
A few representative examples from the platform's own disclosed advisory history, illustrating the categories of risk involved:
Beyond formal security advisories, the project's own GitHub repository averages dozens of new issues daily across every category — not all security-related, but a real, ongoing indicator of how much active maintenance a fast-moving platform like this genuinely requires. Enough that third-party tools and services now exist specifically to diagnose and repair broken self-hosted installations, which is itself a telling signal about how common these problems are in practice.
Trusted-proxy Control UI WebSocket accepted client-declared authentication scopes before pairing completed — a client could claim administrative scope during the handshake itself.
Remote code execution via the gateway's node-invocation approval flow — directly relevant to any deployment exposing the gateway itself.
Hook-triggered CLI runs could receive owner-level MCP tool authority — a privilege escalation path through an automation trigger, not a direct exploit.
None of these are unusual or uniquely damning for OpenClaw specifically — they're the normal shape of vulnerabilities in a complex, actively-developed agent platform with a large attack surface (multiple chat integrations, an exec/tool system, a Control UI, plugin loading). The point isn't that OpenClaw is uniquely risky. It's that treating "we installed it" as "we're secure" is the actual mistake, regardless of platform.
The Control UI itself won't work without HTTPS
This is a hard technical requirement, not a hardening recommendation you can defer. OpenClaw's Control UI uses the browser's WebCrypto API to generate device identity for authentication — and that API is only available in what browsers call a secure context: HTTPS, or literally localhost. Access it over plain HTTP from anything else — a LAN IP, a public IP, a domain without a certificate — and the browser refuses to run the API at all. The result is an authentication failure (control ui requires device identity: use HTTPS or localhost secure context), not degraded functionality.
Concretely, this means self-hosting on a remote server requires standing up one of the following before the dashboard is usable at all:
- A real reverse proxy with a valid certificate (Traefik, Caddy, or nginx), kept renewed
- An SSH tunnel back to the server for every session (workable for solo/dev use, not for a team)
- A service like Tailscale to get an HTTPS-reachable private address
None of this is exotic, but it's real, mandatory setup work with its own ongoing maintenance (certificate renewal, proxy configuration staying correct across upgrades) — before you've even gotten to the security hardening covered below.
Costs can run away without anyone noticing
Without spending controls, a self-hosted agent can consume far more in API tokens than expected before anyone catches it. This isn't a hypothetical: a MacStories writer documented spending $3,600 in a single month running a self-hosted setup; a developer on a community forum reported burning $500 in three days. Neither involved a compromise or misuse — just normal operation without a budget ceiling in place. Setting one up yourself means configuring and monitoring it as a separate, ongoing task.
Channel setup is manual, one integration at a time
Connecting each messaging channel — WhatsApp, Telegram, Slack, Discord, email — involves its own OAuth configuration, webhook setup, and channel-specific security settings like DM-pairing policy, typically done by directly editing configuration files rather than through a guided interface. Getting one wrong doesn't always fail loudly; a misconfigured DM policy, for example, can silently leave a channel more open than intended.
Configuration mistakes aren't always graceful
The gateway's own configuration file has a specific expected shape for every field, and it isn't always forgiving about deviations. One documented case: adding a single unrecognized key to the config file put the gateway into a crash-loop — over 377 restart attempts with no backoff — making the server completely unresponsive and requiring a hard reboot from the hosting console to recover. Separately, providing a field in the wrong shape (a string where an object is expected, for example) can fail silently rather than raising a clear error.
Resource planning becomes your job too
Real-world reports from self-hosted operators describe a modest VPS (2GB RAM, 2 vCPU) running into out-of-memory conditions from a single background job scheduled too frequently — a CRM sync cron job running every 30 minutes was enough to overload the CPU and make the server unresponsive. Sizing the server correctly for actual usage, and noticing when a scheduled job is too aggressive for available resources, is left entirely to whoever runs the instance.
What correct, ongoing patching actually involves
Beyond initial setup, this is more involved than apt upgrade. A few specifics that matter in practice:
- Recreating, not restarting. Pulling a new container image and running
docker restartdoes not apply it — the container must be recreated (docker compose up -dafter a pull) or the old image keeps running under the new tag. - Post-upgrade migrations. OpenClaw's own
openclaw doctor --fixhandles many breaking config changes automatically across version jumps — but only if it's actually run, and its output actually read. - Plugin versions drift independently. Installed plugins (WhatsApp integration, for example) carry their own version numbers and need separate update commands after a core upgrade — easy to miss since the core upgrade "succeeding" doesn't mean plugins came along.
- A stale local package index can silently break provisioning entirely — a real, specific failure mode we've hit and had to fix in our own automated pipeline: a fresh install failing because the base OS image's package index pointed at Docker package versions no longer available upstream.
- The update process itself has a documented failure mode: OpenClaw's own update mechanism runs as a child process of the gateway. If the gateway is stopped while an update is in progress, the update script can be killed mid-way, leaving the gateway down until someone notices and restarts it manually.
What "secure by default" doesn't mean
OpenClaw ships with several settings that are safe defaults for a developer running it locally, but are real hardening gaps in an internet-facing deployment if left unchanged:
- Sandboxing is off by default.
- Agents are not denied the
gatewaytool by default — meaning, out of the box, a successful prompt injection could call the gateway's own config-modification API and undo security settings from within a conversation. - Filesystem tools aren't restricted to an agent's own workspace by default.
- Tool-loop detection isn't enabled by default.
None of these are secrets — they're checkable directly with open-source tooling like openclaw-carapace, which evaluates a deployed instance against 110 automated rules spanning both configuration hardening and known-CVE exposure. Running that audit against a genuinely fresh, unmodified OpenClaw installation is a useful exercise for anyone self-hosting: know what "default" actually means for your specific deployment before deciding it's fine.
Installed skills and plugins are a separate, real risk of their own. Independent security researchers have documented malicious skill packages distributed through OpenClaw's own plugin marketplace, and the pattern has been significant enough to draw attention on general technical discussion forums, not just security-specific ones. Every third-party skill installed on a self-hosted instance should be treated as untrusted code and scanned before use — it isn't vetted for you by default.
Side by side
| Category | Self-Hosted | OpenClaw for Business (Managed) |
|---|---|---|
| Security patching | Your responsibility, on an ongoing basis, requiring correct recreate-not-restart procedure | Handled as part of a scheduled, tested upgrade process |
| Configuration hardening | Default settings are not maximally secure; requires knowing which of 100+ possible settings to change | Hardened defaults applied at provisioning — independently audited, 100% of applicable controls in place |
| Control UI access | Requires setting up HTTPS (reverse proxy) or an SSH tunnel before it works at all | Included, no setup required |
| Spending controls | Not built in; documented cases of $500–$3,600 in unexpected costs | N/A — predictable, fixed-tier pricing |
| Channel setup | Manual OAuth/webhook/config editing, per channel | Configured through a guided dashboard |
| Configuration resilience | A single malformed config key can crash-loop the gateway indefinitely | Managed configuration pipeline, validated before deployment |
| Resource sizing | Your responsibility; documented cases of undersized VPS instances becoming unresponsive | Sized and monitored as part of the managed service |
| Network isolation & firewall | Your responsibility to design and maintain | Configured and maintained, with intrusion prevention and dual-layer DDoS protection |
| Adversarial security testing | Your responsibility, if done at all | Static analysis, live adversarial testing, and manual exploitation testing — published in full |
| Backups | Your responsibility to design, schedule, and verify | Daily, automated, to dedicated backup storage |
| EU data residency | Depends entirely on where you host it | Included by default |
| Setup time | Hours to days of technical work, plus ongoing maintenance time | Minutes, no ongoing technical maintenance required from you |
When self-hosting is the right call
If your team already runs this kind of infrastructure and security work for other systems — patch management, network hardening, adversarial testing — self-hosting OpenClaw is a legitimate, reasonable extension of existing practice, not new overhead. The calculation is different for a business without that capability already in place: everything above becomes new, ongoing work rather than something already absorbed into how the team operates.
See the platform
Same open-source platform, nothing proprietary or locked in — with the operational and security work already handled.
Explore OpenClaw for Business