On a laptop, OpenClaw goes quiet the moment the lid closes: WhatsApp messages queue up, scheduled jobs wait for you to come back. On a server it keeps answering. The catch is that the gateway is not a chat widget. It holds your channel credentials and, unless you sandbox it, runs tools straight on the host. Moving it to an always-on machine is worth doing only if you move the security model with it.
This guide does that in about 20 minutes on a fresh Ubuntu 24.04 VPS.
Last verified 2026-10-04 against OpenClaw 2026.9.8 (npm), Node 24.21 LTS and Ubuntu 24.04.
What you need
- A Linux VPS. We use our AI-Agent plan: 4 vCPU, 4 GB RAM, 40 GB disk, $10/month. The OpenClaw docs mention 6 GB of RAM, but that is for building their Docker image from source; the npm package needs no build.
- An API key for your model provider, and the chat accounts you want to connect.
- An SSH key on your laptop. If you don't have one yet: SSH key authentication.
A NAT plan is fine here, and arguably a better fit. The gateway never needs an open inbound port: WhatsApp, Discord and Telegram (long polling by default) connect outbound, and you reach the dashboard through SSH. Take a dedicated IPv4 only if a channel you need delivers by webhook or you plan to put a public reverse proxy in front.
1. A user that is not root
OpenClaw runs tools as the user that owns the gateway. If that user is root, so is every command a confused or prompt-injected model decides to run. The OpenClaw docs call running the gateway as root unsafe and unsupported. Create a dedicated user without sudo:
# as root
apt update && apt -y upgrade
adduser --disabled-password --gecos "" claw
install -d -m 700 -o claw -g claw /home/claw/.ssh
install -m 600 -o claw -g claw ~/.ssh/authorized_keys /home/claw/.ssh/authorized_keys # the key you added at order time
loginctl enable-linger claw
The last line matters more than it looks. OpenClaw installs a systemd user service, and without lingering that service stops when you log out. That is the most common "it worked yesterday" on servers.
2. Node 24 and OpenClaw
OpenClaw 2026.9.8 requires Node >=24.16.0 <25 or >=26.1.0. Ubuntu's own nodejs package is older, so take the 24 LTS from NodeSource:
# as root
curl -fsSL https://deb.nodesource.com/setup_24.x | bash -
apt install -y nodejs
node -v # v24.16.0 or newer
npm install -g openclaw@latest
openclaw --version
The official one-liner (curl -fsSL https://openclaw.ai/install.sh | bash) also works and installs Node for you. We prefer the two explicit steps on a server: you see what lands where, and the binary sits in /usr/bin instead of a home directory the agent can write to.
3. Onboard as the agent user
Log in as claw over SSH, not with su. A real login starts the systemd user manager that the service needs:
# from your laptop (NAT plans: add -p <your SSH port>)
ssh claw@<server>
openclaw onboard --install-daemon
openclaw gateway status
The wizard checks model access, writes ~/.openclaw/openclaw.json, generates a gateway token and installs the service. If systemctl --user complains about the bus, set export XDG_RUNTIME_DIR=/run/user/$(id -u) and run it again.
Then lock the files down. OpenClaw's own guidance is 700 on the state directory and 600 on the config:
chmod 700 ~/.openclaw && chmod 600 ~/.openclaw/openclaw.json
openclaw security audit --deep
openclaw security audit --fix applies the safe subset of fixes: tighter file permissions and allowlists instead of open group policies. It won't rebind or firewall anything for you; network exposure is still your job.
4. Keep the gateway on loopback
The gateway serves its WebSocket API and the dashboard on one port, 18789, bound to 127.0.0.1 by default. Leave it there. A minimal config that states it explicitly:
// ~/.openclaw/openclaw.json
{
gateway: {
mode: "local",
bind: "loopback",
port: 18789,
auth: { mode: "token", token: "paste-output-of-openssl-rand-hex-32" },
},
}
Generate the token with openssl rand -hex 32 or openclaw doctor --generate-gateway-token. The gateway refuses blank tokens and the example placeholders, and the audit warns below 24 characters.
What not to do: set bind to "lan" and open the port. The docs are blunt about it: never expose the gateway unauthenticated on 0.0.0.0, and don't port-forward it broadly even with a token. Whoever gets that token is an operator of a process that can run commands on your server.
On the firewall side, allow SSH and nothing else:
# as root
ufw allow OpenSSH
ufw enable
ufw status verbose
On our NAT plans the dashboard shows an external SSH port, but inside the server sshd still listens on 22. Allow OpenSSH (port 22), not the external port number, or ufw enable locks you out. More on that in the UFW guide.
5. Reach the dashboard through SSH
From your laptop, open a tunnel and leave it running:
ssh -N -L 18789:127.0.0.1:18789 claw@<server>
# NAT plan: ssh -N -p <your SSH port> -L 18789:127.0.0.1:18789 claw@<host>
Open http://127.0.0.1:18789/ and paste the gateway token. Ubuntu's default sshd allows local forwarding; if you hardened it, AllowTcpForwarding local is the setting that permits -L while blocking remote forwards. If the tunnel fails with administratively prohibited, that is the line to check.
A tailnet works too: Tailscale Serve keeps the gateway on loopback and handles access. Both are fine. A public port is not.
6. Pairing, sandbox, and who can talk to it
Chat channels are the other way in. By default, DM-capable channels make unknown senders pair first; you approve them from the server:
openclaw pairing approve <channel> <code>
For groups, require a mention so the agent doesn't answer every message in the room. The OpenClaw hardened baseline uses dmPolicy: "pairing" and groups: { "*": { requireMention: true } } per channel.
Two honest caveats. First, pairing controls who can trigger a turn, not what ends up in the model's context: a forwarded message or a fetched web page can still steer an owner-triggered turn. Second, tools run on the host for the main session unless you enable sandboxing (agents.defaults.sandbox.mode: "non-main" sandboxes everything except your own main session). Sandboxing is off by default and its default backend is Docker, so install Docker first if you turn it on: Docker on a VPS. If people you don't trust share a channel with the bot, use a separate gateway, ideally on a separate server.
7. Updates and backups
openclaw update
openclaw gateway status
openclaw backup create --output ~/backups/openclaw --verify
~/.openclaw holds the config, channel credentials (WhatsApp session included), model auth profiles and session transcripts. Losing it means re-pairing everything; leaking it means someone else is you on WhatsApp. Back it up, and keep the backup off the server: copy it down with scp or use restic with encryption.
Checklist
| Check | Command | Expected |
|---|---|---|
| Gateway runs as non-root | ps -eo user,args | grep '[o]penclaw' | claw in the first column |
| Survives logout | loginctl show-user claw -p Linger | Linger=yes |
| Listens on loopback only | ss -ltnp | grep 18789 | 127.0.0.1:18789 |
| No public port | ufw status | only OpenSSH |
| Config not world-readable | stat -c '%a' ~/.openclaw/openclaw.json | 600 |
| Audit clean | openclaw security audit --deep | no critical findings |
Where EQVPS fits
Plenty of hosts can run a Node process. What we add is crypto payment without KYC, a NAT plan that suits a loopback-only gateway, and an MCP server your agent can use to manage its own servers. If you connect OpenClaw to it, read MCP guardrails first: a token that can order servers deserves the same care as the gateway token. For a broader look at running agents on a VPS, see the AI agent guide.
Our take: the 20 minutes above are the difference between an assistant and an open shell with a chat interface. Do steps 1, 4 and 5 even if you skip the rest.
Comments
No comments yet. Be the first.