Run OpenClaw safely on a VPS

What OpenClaw is, and why you harden it first

OpenClaw is a self-hosted AI agent. You run it on your own server, connect it to a large language model, and it can run shell commands, control a browser, read and write your files, and act on the messages you send it from chat apps. That reach is the entire point of the tool, and it is also the entire risk. An agent that can run any command is only as safe as the box it runs on and the limits you put around it.

Two facts set the tone for this guide. First, OpenClaw is designed to be hardened by you. Its security model puts the responsibility for tight tool policies, sandboxing, and careful permissions on the operator, not on a safe default. Second, the project has already had a serious security event: in March 2026, nine security issues were disclosed within four days, including a critical privilege-escalation flaw, CVE-2026-32922, rated 9.9 out of 10. Neither fact means you should avoid OpenClaw. They mean you should not run it the lazy way, and this guide is the careful way.

There is good news too. OpenClaw already makes one safe choice for you: its gateway, the single process that controls everything, listens on the loopback address by default, so it is not reachable from the internet unless you go out of your way to expose it. Most of the work below is keeping it that way and limiting the blast radius if something does go wrong.

Give OpenClaw its own unprivileged user

Never run an agent as root. If OpenClaw runs as root and anything goes wrong, whether a bug, a bad instruction, or a CVE like the one above, the damage has no ceiling. Create a dedicated system user with no login shell and no sudo, and run the agent as that user:

sudo useradd --system --home /opt/openclaw --shell /usr/sbin/nologin openclaw

Everything OpenClaw owns lives under /opt/openclaw, owned by that account. This is the single most important step, and it is the same principle covered in running services as an unprivileged user: the account an agent runs as is the ceiling on what it can break.

Install OpenClaw

OpenClaw is distributed as an npm package, so install Node.js first if the server does not have it. Install the package globally, which puts the openclaw binary on the PATH for every user, then run the one-time onboarding step:

sudo npm install -g openclaw@latest
sudo -u openclaw openclaw onboard

Running onboarding as the openclaw user means the agent's configuration lands in its home directory, /opt/openclaw, not in root's. The project also offers a curl -fsSL https://openclaw.ai/install.sh | bash installer that does the same install in one line. Skip the --install-daemon flag during onboarding: it would register OpenClaw's own service, and the hardened systemd unit you build below is stricter.

Keep the gateway on loopback, behind a firewall

The gateway binds to 127.0.0.1 by default. Leave it there. There is almost never a reason to publish that port to the internet, and doing so hands anyone who finds it a remote foothold into a process that runs commands for a living.

Put a default-deny firewall in front of the box so nothing is exposed by accident:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Two traps to avoid here. A firewall that only covers IPv4 can leave the same service wide open on IPv6, which is exactly the IPv6 firewall gap that catches so many people. And if you need to reach the gateway from your laptop, do not open the port. Reach it over a VPN or an SSH tunnel, so the agent is never listening to the open internet.

Isolate its secrets

OpenClaw needs an API key for whatever language model you connect it to. That key can spend your money and, through the agent, act on your behalf, so treat it like a password. Keep it out of the unit file and out of any repository. Put it in a file only the OpenClaw user can 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 key

The systemd unit loads that file with EnvironmentFile, so the key reaches the process without ever sitting in a command line, a log, or your shell history.

Run it as a hardened systemd service

Running the agent under systemd gives you automatic restarts, clean logs through journalctl, and, most importantly, a set of kernel-level sandboxing options that shrink what the process can touch even if it is compromised. The ones that matter most for an agent are NoNewPrivileges so it can never gain new powers, ProtectSystem=strict so the filesystem is read-only except where you allow writes, PrivateTmp for its own isolated temporary directory, and ProtectHome so it cannot read home directories.

Generate a complete, hardened unit here, then copy it to /etc/systemd/system/openclaw.service:

The unit starts openclaw gateway, the long-running process that controls the agent; if which openclaw shows a different path on your server, adjust ExecStart to match. The full walkthrough of these directives, and of daemon-reload and enable --now, is in running a program as a systemd service. The short version once you have pasted the unit:

sudo systemctl daemon-reload
sudo systemctl enable --now openclaw

Harden the front door too

An agent box is only as safe as the server around it. Two more layers finish the job. Move SSH to key-only authentication and drop root login, as in SSH hardening on a VPS, so the account you administer the box from cannot be brute-forced. Then add Fail2ban to evict the scanners that hammer every public port. Neither touches OpenClaw directly, but both cut off the routes an attacker would use to reach it.

Keep it updated, on purpose

The March 2026 disclosures are the clearest possible argument for staying current. A privilege-escalation bug in an agent is far more serious than in an ordinary web app, because the agent already runs commands. Watch the project's releases, apply security updates quickly, and treat an OpenClaw upgrade as routine maintenance rather than something to put off.

To understand what you are actually hardening, the architecture of an OpenClaw-style agent walks through the moving parts, and building your own AI agent on a VPS covers the general shape any agent takes.

FAQ

Is OpenClaw safe to self-host?

It can be, if you harden it. OpenClaw is powerful by design: it runs shell commands and controls a browser, so a careless setup is genuinely dangerous, and the project has already had a critical CVE (CVE-2026-32922 in March 2026). Its security model expects you, the operator, to add the limits. Run it as an unprivileged user, keep its gateway on loopback behind a default-deny firewall, isolate its API keys, and run it as a hardened systemd service.

Should I expose the OpenClaw gateway to the internet?

No. The gateway binds to loopback by default, and you should leave it there. It is the single process that controls the agent, so an exposed gateway is a remote path into something that runs commands for a living. If you need to reach it remotely, use a VPN or an SSH tunnel instead of opening the port.

What user should OpenClaw run as?

A dedicated system user with no login shell and no sudo, never root. If the agent is compromised, its user account is the ceiling on the damage, so that account should own only its own files under a directory like /opt/openclaw and nothing else.

How do I keep OpenClaw's API keys secure?

Store them in a file readable only by the OpenClaw user (mode 600) and load it into the service with systemd's EnvironmentFile. Keep the key out of the unit file, out of your shell history, and out of any git repository. Rotate it if you ever suspect it has leaked.