Should OpenClaw run as root on your server?
No, and the official Docker image already refuses to: it runs as node, uid 1000. Why an agent that executes commands deserves its own locked-down user, and the setup that does it properly.
No. An OpenClaw agent executes shell commands as part of its normal work, which makes its Unix user the blast radius for everything from a bad model decision to a prompt-injection attempt, and root’s blast radius is the whole machine. The official Docker image already takes the position for you: it runs as node, uid 1000, not root. On a bare VPS, copy that: create a dedicated user, run the gateway as that user, and keep root for administration only.
Why root is the wrong user for an agent specifically
The usual don’t-run-as-root advice is about software bugs. With an agent it’s sharper than that: the process’s purpose is to run commands it composes itself, steered by conversation and by text it reads from the outside world. Whatever user the gateway runs as is the user those commands get. As a normal user, a catastrophic command can wreck the agent’s own files. As root, it can wreck the operating system, read every secret on the box, alter SSH access, and erase the evidence. Least privilege isn’t bureaucracy here: it’s the difference between “restore the workspace from backup” and “rebuild the server.”
What the official bits already do
The Docker image documents itself plainly: “the image runs as node (uid 1000),” with state bind-mounted into /home/node/.openclaw. That’s the project telling you the intended privilege level of a running gateway. The npm path makes no such decision for you: whatever user runs openclaw onboard --install-daemon is the user the daemon serves, and the docs’ own examples assume a normal login user, with state under /home/<user>/.openclaw. Nothing in OpenClaw needs root at runtime: it binds a high local port, writes inside one home directory, and talks outbound to model and channel APIs. The moments that do need privilege (installing packages, opening firewall rules) are one-time admin actions, done by you, not by the agent’s user.
The setup that does it properly
On a fresh Ubuntu server (uid 1000 matters if you’ll ever bind-mount into the official container, which expects it):
useradd --uid 1000 --user-group --create-home --shell /bin/bash openclaw
passwd -l openclaw # no password, ever: SSH keys or nothing
# then install and onboard AS that user, not as rootThe passwd -l lock means the account can’t be password-guessed even if password SSH login were ever re-enabled by accident. Give the user its own authorized_keys if you’ll SSH in as it directly, or just su - openclaw from your admin session. If the daemon was already installed as root, the right fix is a clean redo: stop and uninstall the service, move /root/.openclaw into the new user’s home, chown -R it, and reinstall the daemon as the user. The state directory is portable, and a backup first makes the move boring.
What a non-root user doesn’t solve
The boundary: a Unix user protects the system from the agent. It does not protect the agent’s own world: its memory, workspace files, and configured secrets all belong to that user, so anything the agent is talked into doing can still touch them. The tools for that layer are OpenClaw’s own sandboxing and exec approvals and the discipline of a dedicated machine with nothing else on it, a box where, even in the worst case, there’s nothing of yours to reach beyond the agent itself. Root vs non-root decides how bad the worst day is; the checklist decides how likely it ever arrives.