How to Self-Host OpenClaw on a VPS (2026 Guide)

The OpenClaw install is one command and takes about ten minutes. The part that matters takes another twenty. OpenClaw’s own documentation is unusually blunt about this: you should decide how you will administer the server before you install anything on it, because the Gateway ends up holding your credentials, your workspace and the ability to run commands on your behalf.

That ordering — harden first, install second — is the single thing that separates this guide from the dozen host-published tutorials that stop at a green checkmark. Hundreds of unauthenticated instances have already been found exposed on the public internet, complete with live API keys and chat history. Those were not sophisticated attacks. They were default configurations.

Here’s the plan:

• Provision a server with at least 4GB of RAM (8GB if you want browser automation).
• Harden admin access first — non-root user, key-only SSH, and ideally Tailscale before OpenClaw exists on the box.
• Install OpenClaw with the official one-line installer.
• Keep the Gateway on loopback and reach it through an SSH tunnel or Tailscale, rather than exposing it.
• Tune and back up, because this thing is meant to run unattended.

Before you start

You need three things.

A server. 4GB of RAM is the working minimum, 8GB if your agent will drive a headless browser — that adds roughly 2GB on its own. Any mainstream provider works; we compared them in detail in our guide to the best VPS for OpenClaw, and the short version is Hostinger if you want a one-click template that skips most of this article, Bluehost if you want a panel, Hetzner for the best price-to-performance, DigitalOcean for the strongest security defaults, or IONOS if you are purely optimising for cost. OpenClaw’s docs also publish provider-specific install notes for DigitalOcean, Hetzner and Fly.io.

An LLM API key, from Anthropic, OpenAI, Google or whoever you prefer. The agent orchestrates; the model does the thinking, and it lives elsewhere unless you are self-hosting a model too.

A recent Node.js, though you almost certainly do not need to install it yourself. OpenClaw requires Node 22.22.3+, 24.15+ or 25.9+, with Node 26 as the recommended default — and the official installer provisions Node automatically if it is missing.

A note on time: budget about 30–40 minutes for a first run. The install itself is fast. Tailscale, SSH hardening and verifying you have not locked yourself out are what take the time, and they are worth it.

Step 1: Provision the server

Create the instance with a current Ubuntu LTS image. Add your SSH public key during creation if the provider offers it — it saves a step and means you never send a password over the wire.

Once it boots, log in and update:

ssh root@your-server-ip
apt update && apt upgrade -y

Step 2: Create a dedicated user

Never run the agent as root. If something goes wrong — a bad prompt injection, a compromised dependency — you want the damage confined to one unprivileged account rather than the whole machine.

adduser openclaw
usermod -aG sudo openclaw
rsync --archive --chown=openclaw:openclaw ~/.ssh /home/openclaw

That last line copies your authorised key across so you can log in as the new user immediately. Open a second terminal and confirm ssh openclaw@your-server-ip works before you continue. Every lockout story starts with someone skipping that check.

Step 3: Harden admin access — before installing anything

This is the step OpenClaw’s documentation explicitly tells you to do first, and the one most tutorials leave until the end or omit entirely.

Install Tailscale first (recommended)

Tailscale puts the server on a private network that only your devices can reach. It is the difference between an agent that is merely configured correctly and one that is genuinely not reachable by strangers.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

Follow the printed URL to authenticate, then verify a second SSH session works over the Tailscale IP or MagicDNS name before you touch the public SSH configuration. The order matters: prove the new path works, then close the old one.

Restrict public SSH

With Tailscale access confirmed, lock down password login:

sudo nano /etc/ssh/sshd_config

Set the following:

PermitRootLogin no
PasswordAuthentication no

Then reload and add a firewall:

sudo systemctl reload ssh
sudo ufw allow OpenSSH
sudo ufw enable

If you are not using Tailscale, apply the equivalent hardening — key-only authentication, no root login, a firewall, and something like fail2ban to blunt brute-force attempts — before you expose anything else on the box.

One caveat worth knowing before you trust that firewall: ufw does not filter ports published by Docker, because Docker’s rules are applied before the chains ufw uses. If you run anything in a container later, check whether your agent is actually exposed from outside the box rather than assuming the firewall covered it. If you’d rather run the whole gateway in a container instead of installing it directly, the Docker route covers what persists across container replacement and which health endpoint to probe.

Step 4: Install OpenClaw

Now the easy part. Log in as your openclaw user and run the official installer, which detects the OS, installs Node if it is missing, installs OpenClaw and launches onboarding:

curl -fsSL https://openclaw.ai/install.sh | bash

If you would rather install now and configure later:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

There is also a local-prefix installer that keeps OpenClaw and its Node runtime under ~/.openclaw without touching a system-wide Node:

curl -fsSL https://openclaw.ai/install-cli.sh | bash

That last option is worth knowing about if the server does other work and you would rather not have OpenClaw’s Node version become everyone’s Node version.

Step 5: Onboard and install the daemon

Onboarding walks you through connecting your model provider and your messaging channels. To have it also install a background service so the agent survives reboots:

openclaw onboard --install-daemon

This installs a systemd user unit, openclaw-gateway.service. Confirm it is running:

systemctl --user status openclaw-gateway.service

One wrinkle with user units: they stop when your login session ends unless lingering is enabled. For an always-on agent, turn it on:

sudo loginctl enable-linger openclaw

Step 6: Reach the Gateway without exposing it

The Gateway is the component that runs on the VPS and owns your state and workspace. Keep it bound to loopback. That is the documented secure default, and it means the dashboard simply is not reachable from the internet.

To use the Control UI from your laptop, forward the port over SSH:

ssh -L 8080:localhost:8080 openclaw@your-server-ip

Then open http://localhost:8080 locally. Tailscale Serve is the other supported route and is more convenient across devices.

If you deliberately bind the Gateway to lan or tailnet instead, OpenClaw requires a shared secret — gateway.auth.token or gateway.auth.password — unless you have delegated authentication to a trusted proxy. Do not work around that requirement. It is the control that stands between your agent and the open internet, and the exposed instances that made the news are precisely the ones that bypassed it.

Step 7: Tune for a small server

On modest VMs, and particularly on ARM hosts, CLI commands can feel sluggish. OpenClaw’s docs recommend enabling Node’s module compile cache:

grep -q 'NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache' ~/.bashrc || cat >> ~/.bashrc <<'EOF'
export NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
mkdir -p /var/tmp/openclaw-compile-cache
export OPENCLAW_NO_RESPAWN=1
EOF
source ~/.bashrc

NODE_COMPILE_CACHE speeds up repeated command startup — the first run warms it. OPENCLAW_NO_RESPAWN=1 keeps routine Gateway restarts in-process, which avoids extra process handoffs and keeps PID tracking simple on small hosts.

For the service itself, the documented tuning is:

systemctl --user edit openclaw-gateway.service

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90

Restart=always is what turns a crash into a two-second blip rather than a dead agent you notice on Thursday.

Step 8: Back up state and workspace

Treat the VPS as the source of truth, because it is — the Gateway owns your state and workspace, and that includes conversation history, configuration and whatever files the agent has been working with. Back both up regularly.

The pragmatic approach is two layers: your provider’s snapshot feature for whole-server rollback, and a scheduled copy of the state and workspace directories somewhere off the box. Snapshots are free on some hosts and cost up to 20% extra on others, which is worth checking before you assume you have them.

Troubleshooting

The agent dies unpredictably, or you see exit 137. That is the Linux out-of-memory killer, and it means the box is too small for what you are running. It is by far the most common failure, and browser automation is usually the cause. Either upgrade to 8GB or add swap as a stopgap.

CLI commands are slow. Apply the compile-cache tuning in Step 7.

The Gateway stops when you log out. You skipped loginctl enable-linger, so the systemd user unit is being torn down with your session.

You cannot reach the Control UI. That is the expected behaviour if the Gateway is on loopback — which is correct. Use the SSH tunnel from Step 6 rather than binding it to a public interface.

FAQ

How long does it take to self-host OpenClaw?

The installer itself runs in a few minutes, and onboarding adds a few more. Realistically, budget 30–40 minutes for a first deployment including a non-root user, SSH hardening and Tailscale. Providers with a one-click OpenClaw template compress the install portion to a couple of clicks, but the hardening decisions are still yours to make.

Do I need Docker to run OpenClaw?

No. The official installer sets up OpenClaw directly with a systemd service, which is the simplest path on a dedicated VPS. Docker is worth using when you want stricter isolation or you are running several agents side by side on the same machine, but it is not a requirement.

Is it safe to run an AI agent on a public server?

It is, provided you do not leave it publicly reachable. The documented failure mode is an exposed Gateway with no authentication, so keep it on loopback, reach it over an SSH tunnel or Tailscale, run it as a dedicated non-root user, and give it API keys scoped to the minimum it needs. The risk comes from configuration, not from the concept.

Related Blog Posts

• The Best VPS for OpenClaw
• The Best VPS for AI Agents
• The Best VPS Hosting Services
• The Best Cloud Hosting Providers