How to Run OpenClaw Safely for VPS
OpenClaw fit run shell commands and browse web. Harden am on VPS with unprivileged user, firewall, secrets, and systemd, plus avoid CVE-2026-32922 risk.
Wetin OpenClaw be, and why you need harden am first
OpenClaw na self-hosted AI agent. You dey run am for your own server, connect am to a large language model, and e fit run shell commands, control browser, read and write your files, and act on messages wey you send am from chat apps. Na this reach be the main reason for the tool, and na also the main risk. Agent wey fit run any command only dey as safe as the box wey e dey run on and the limits wey you put around am.
Two facts set the direction for this guide. First, OpenClaw dey designed make you harden am by yourself. E security model put responsibility for strict tool policies, sandboxing, and careful permissions on the operator, instead of safe default. Second, the project don already get serious security event: for March 2026, dem disclose nine security issues within four days, including critical privilege-escalation flaw, CVE-2026-32922, wey get rating 9.9 out of 10. Neither fact mean say you suppose avoid OpenClaw. Dem mean say you no suppose run am the lazy way, and this guide show the careful way. Part of the careful way na to decide from the beginning how much the agent fit do without asking, na choice wey Claude Code dey make clear with e permission modes, where server wey you no dey sit in front of deserve tighter setting pass laptop wey you dey watch.
Good news still dey. OpenClaw already make one safe choice for you: e gateway, wey be the single process wey dey control everything, dey listen on loopback address by default, so internet no fit reach am unless you deliberately expose am. Most of the work below na to keep am that way and limit the blast radius if something go wrong.
Give OpenClaw e own unprivileged user
Never run agent as root. If OpenClaw dey run as root and anything spoil, whether na bug, bad instruction, or CVE like the one wey dey above, the damage no get limit. Create dedicated system user wey no get login shell and no sudo, then run agent with that user:
sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclawEverything wey OpenClaw own dey under /opt/openclaw, and na that account own am. Na this be the most important step, and na the same principle wey dem cover for running services as unprivileged user: the account wey agent dey run as na the limit of wetin e fit spoil.
Install OpenClaw
OpenClaw dey distributed as npm package, so install Node.js first if server no get am. Install the package globally. This one go put the openclaw binary for PATH for every user. After that, run the one-time onboarding step:
sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboardWhen you run onboarding as the openclaw user, the agent configuration go enter the user home directory, /opt/openclaw, instead of root home directory. The project still get curl -fsSL https://openclaw.ai/install.sh | bash installer wey fit do the same installation with one line. No use the --install-daemon flag during onboarding. E go register OpenClaw own service, but the hardened systemd unit wey you go build below get stricter settings.
Gateway na loopback, behind firewall
Gateway dey bind to 127.0.0.1 by default. Leave am there. Almost no reason dey to publish that port to internet, and if you do am, anybody wey find am fit get remote foothold inside process wey dey run commands for work.
Put default-deny firewall in front of the box so nothing go expose by mistake:
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enableTwo traps dey here wey you need avoid. Firewall wey only cover IPv4 fit leave the same service completely open for IPv6. Na exactly this IPv6 firewall gap dey catch plenty people. If you need reach the gateway from your laptop, no open the port. Reach am through VPN or SSH tunnel, so agent no go ever listen to open internet.
Isolate im secrets
OpenClaw need API key for any language model wey you connect am to. That key fit spend your money and, through the agent, act on your behalf, so treat am like password. Keep am out of the unit file and out of any repository. Put am inside file wey na only the OpenClaw user fit read:
sudo install -o openclaw -g openclaw -m 600 /dev/null /opt/openclaw/openclaw.env
sudoedit /opt/openclaw/openclaw.env # add ANTHROPIC_API_KEY=... or your model provider's keyThe systemd unit dey load that file with EnvironmentFile, so the key reach the process without ever dey inside command line, log, or your shell history. That pattern apply to every secret for the machine: a hardening pass for self-hosted Vaultwarden mainly concern its admin token and backup file, not its encryption, because file permissions na wetin actually decide who fit read secret wey dey stored.
Run am as a hardened systemd service
If you run the agent under systemd, e go restart am automatically, keep clean logs through journalctl, and most importantly, give you kernel-level sandboxing options wey reduce wetin the process fit touch even if dem breach am. The options wey matter pass for agent na NoNewPrivileges so e no fit ever gain new powers, ProtectSystem=strict so filesystem go remain read-only except places wey you allow writes, PrivateTmp for e own isolated temporary directory, and ProtectHome so e no fit read home directories.
Generate complete, hardened unit here, then copy am go /etc/systemd/system/openclaw.service:
The unit starts openclaw gateway, the long-running process wey dey control the agent. If which openclaw show different path for your server, adjust ExecStart to match am. The full walkthrough for these directives, and for daemon-reload and enable --now, dey for running a program as a systemd service. The short version after you don paste the unit:
sudo systemctl daemon-reload
sudo systemctl enable --now openclawHarden the front door too
Agent box dey only as safe as the server wey surround am. Two more layers go complete the work. Move SSH go key-only authentication and disable root login, as e dey for SSH hardening on a VPS, so dem no fit brute-force the account wey you use administer the box. Then add Fail2ban to remove scanners wey dey hammer every public port. None of dem touch OpenClaw directly, but both cut off the routes wey attacker fit use reach am.
Keep am updated on purpose
The disclosures for March 2026 na the clearest reason to stay current. A privilege-escalation bug for agent more serious pass the one for normal web app, because the agent already dey run commands. Monitor the project's releases, apply security updates quickly, and treat OpenClaw upgrade as normal maintenance instead of something to postpone.
To understand wetin you dey harden, the architecture of OpenClaw-style agent explain the different parts, while building your own AI agent on a VPS cover the general structure wey any agent get. If you later run another agent alongside am, remember say two Claude Code sessions on one VPS fit pass work to each other, so each one need its own account and its own limits instead of inheriting your own.
FAQ
OpenClaw for public VPS dey safe to run?
E fit safe, if you harden am. OpenClaw powerful by design: e dey run shell commands and control browser, so careless setup truly dangerous, and project don already get critical CVE (CVE-2026-32922 for March 2026). E security model expect you, the operator, to add the limits. Run am as unprivileged user, keep e gateway for loopback behind default-deny firewall, isolate e API keys, and run am as hardened systemd service.
I suppose expose OpenClaw gateway to internet?
No. Gateway dey bind to loopback by default, and you suppose leave am there. Na the single process wey dey control the agent, so exposed gateway na remote path enter something wey dey run commands for work. If you need reach am remotely, use VPN or SSH tunnel instead of opening the port.
Which user OpenClaw suppose run as?
Use dedicated system user wey get no login shell and no sudo; never root. If agent get compromised, na the user account be the limit of the damage, so that account suppose own only e own files under directory like /opt/openclaw and nothing else.
How I go keep OpenClaw API keys secure?
Store dem for file wey only OpenClaw user fit read (mode 600), then load am into the service with systemd EnvironmentFile. Keep the key out of unit file, out of your shell history, and out of any git repository. Rotate am if you ever suspect say e don leak.