Self-hosting OpenClaw on Proxmox with an Ubuntu VM

Running OpenClaw directly on your laptop is fine for testing, but it is fragile for daily use. Sleep mode, reboots, and local network churn all break an always-on assistant. A small Ubuntu VM on Proxmox gives you stable uptime, snapshots, and predictable recovery when things fail.

This walkthrough is opinionated for reliability first: one Ubuntu Server VM, one OpenClaw gateway, loopback bind by default, and remote access through SSH tunneling or Tailscale.

What we are building

• Proxmox VM running Ubuntu Server 24.04 LTS
• OpenClaw installed with the official installer
• Gateway running as a managed service
• Basic hardening (SSH keys, firewall, auth token, update policy)
• A troubleshooting checklist for common startup/auth failures

VM sizing and Proxmox settings

OpenClaw can run on small resources, but model providers, channels, and logs create bursty load. Start with this baseline:

Recommended Proxmox VM options:

• Machine: q35
• CPU type: host
• Disk bus: VirtIO SCSI (enable discard/TRIM)
• NIC model: VirtIO (paravirtualized)
• Enable QEMU Guest Agent in VM options

These settings are boring by design, but they reduce performance surprises.

1) Create the Ubuntu VM

Create a new VM in Proxmox using Ubuntu Server 24.04 LTS ISO, then:

1. Assign resources from the table above.
2. Attach VM to the bridge/VLAN you use for server workloads.
3. Install Ubuntu with OpenSSH server selected.
4. Use a non-root sudo user (for example openclaw).
5. Boot and confirm network + SSH access from your admin machine.

On first login:

sudo apt update && sudo apt -y full-upgrade
sudo apt -y install qemu-guest-agent curl ca-certificates ufw
sudo systemctl enable --now qemu-guest-agent
sudo reboot

2) Base OS security and host prep

Before installing OpenClaw, lock down the VM basics.

SSH key auth and sane SSH defaults

Copy your key:

ssh-copy-id openclaw@<vm-ip>

Then edit /etc/ssh/sshd_config:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Apply:

sudo systemctl restart ssh

Firewall (UFW)

Allow SSH, then enable firewall:

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Keep the gateway bound to loopback unless you explicitly need remote ingress.

3) Install OpenClaw on Ubuntu

OpenClaw docs currently require Node 22+ for CLI workflows. Use the official install script:

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

Reload shell, then verify:

openclaw --version
node --version

Run onboarding with daemon install:

openclaw onboard --install-daemon

This configures auth, gateway defaults, and service wiring in one pass.

4) Gateway and service setup

Check service health:

openclaw gateway status
openclaw status
openclaw logs --follow

Healthy baseline is Runtime: running and RPC probe: ok.

If you run OpenClaw as your user service on Linux, enable lingering so the gateway survives logout:

sudo loginctl enable-linger $USER

For an always-on shared server, use a system service instead:

openclaw gateway install
sudo systemctl daemon-reload
sudo systemctl enable --now openclaw-gateway.service

Then open the dashboard locally on the VM or through a tunnel:

openclaw dashboard

5) Remote access patterns that do not expose the gateway

The safest default is still:

• gateway.bind = loopback
• token or password auth enabled
• remote access via tunnel/VPN

SSH tunnel (simple and reliable)

From your laptop:

ssh -N -L 18789:127.0.0.1:18789 openclaw@<vm-ip>

Then connect your client/UI to ws://127.0.0.1:18789 locally.

Tailscale (clean homelab UX)

OpenClaw docs support Tailscale Serve/Funnel modes, but for homelabs:

1. Prefer tailnet-only access.
2. Keep gateway auth on even over tailnet.
3. Avoid public Funnel unless you need it and understand the blast radius.

6) Security basics that matter most

If you only do five things, do these:

1. Keep gateway.bind on loopback unless absolutely necessary.
2. Enforce gateway auth (token is the simplest default).
3. Store provider keys in VM environment files with strict permissions.
4. Keep Ubuntu patched (unattended-upgrades or scheduled maintenance window).
5. Snapshot before major OpenClaw updates and keep off-host backups of config/state.

Useful sanity checks:

openclaw doctor
openclaw health
openclaw models status

7) Troubleshooting by symptom

another gateway instance is already listening or EADDRINUSE

Port conflict. Check listeners and restart the managed service:

ss -lntp | rg 18789
openclaw gateway status
openclaw gateway restart

refusing to bind gateway ... without auth

You tried non-loopback bind without token/password configured. Set auth first, then restart.

unauthorized during client connect

Client token/password does not match gateway auth config. Reissue credentials and retest with openclaw health.

Gateway dies after SSH logout

You are using a user service without lingering. Enable lingering or migrate to system service.

Dashboard works but channels are broken

Gateway is up, channel auth is not. Probe channels and inspect logs:

openclaw channels status --probe
openclaw logs --follow

Operational checklist (copy/paste)

# Daily
openclaw gateway status
openclaw health

# Weekly
sudo apt update && sudo apt -y upgrade
openclaw doctor

# Before upgrades
# 1) Proxmox snapshot VM
# 2) Update OpenClaw
# 3) Verify health and channels

A Proxmox VM will not make OpenClaw magically production-grade, but it gives you a controlled runtime with clear rollback points. That is the biggest improvement most self-hosted setups need.