Deploy OpenClaw on a VPS

OpenClaw is an open source AI assistant gateway: it connects a model to the chat apps you already use, and it can browse, run commands, and work on a schedule. Running it on a server of your own means it stays reachable when your laptop is shut, and the conversation history and configuration sit on a disk you control. The OpenClaw community maintains the installer and its documentation, so this guide covers the half that is ours: the server underneath, keeping it alive and private, and protecting its data. The product page is Self-Hosted OpenClaw Hosting.

Prepare the server first#

An assistant that browses, runs terminal commands, and manages files deserves a machine with nothing else on it. Ten minutes of work before it exists:

1. Harden the fresh install. Work through First Steps on a New Linux Server: updates, a sudo user, SSH keys, password logins off.
2. Close what you are not using. Set the firewall to default deny inbound, SSH only, then open a port only where the documentation says a channel you paired needs one.
3. Keep it dedicated. No site, no database, nothing else you would mind it touching. The separate server is the isolation boundary, and the cheapest control you have.

Install Node and OpenClaw#

OpenClaw wants a current Node.js: 22.22.3 or newer, with 26 recommended. Install Node from your distribution's current packages or a version manager, then the gateway itself:

node --version          # confirm 22.22.3 or newer before going further
npm install -g openclaw

Then run the onboarding wizard and let it install the daemon. It will ask for the API key for your model provider and walk you through pairing a first channel. Exact flags and channel options change with the project, so read the current documentation at docs.openclaw.ai rather than trusting a command copied from anywhere else.

Keep it running across reboots#

The wizard installs a daemon, but confirm it survives a restart rather than assuming:

systemctl list-units --type=service --state=running   # find the unit the wizard created
sudo systemctl is-enabled <unit>                      # should print: enabled
sudo journalctl -u <unit> -f                          # live logs, Ctrl+C to stop
sudo reboot                                           # then reconnect and check again

No unit, or one that did not come back? Run an App as a systemd Service covers unit files, a dedicated unprivileged user, and secrets in an EnvironmentFile.

Decide who may talk to it#

A chat gateway is reachable by anyone who can message the account it is paired to, which makes the allowlist the control that matters most here. Set it during onboarding so the assistant answers only the accounts you name, and revisit it whenever you add a channel. The dashboard is a separate problem: it can change what the assistant may do, so it does not belong on the public internet. Bind it to the server itself and reach it over an SSH tunnel or a tailnet, both covered in Keep a Dashboard Private.

Back up its data#

Configuration, paired channels, and conversation history are the parts you cannot reinstall. Every VPS plan includes one free off-node backup, but that is one point in time rather than a versioned history, so add your own. Find the data directory first, from the running service:

systemctl show -p WorkingDirectory --value <unit>   # where the service runs from
systemctl show -p EnvironmentFiles --value <unit>   # config, which usually names the data path

• Take a snapshot before a Node upgrade or a risky change.
• Copy that directory off the server nightly. The restic pattern in Back Up a Dockerised App works for any directory.
• Backups, RAID, and Data Protection covers what each layer misses.

Next: scope the credentials before you hand it anything real. Security for a Self-Hosted AI Agent applies to OpenClaw exactly as it does to Hermes Agent.