OpenClaw on a VPS: Locking Down Your Setup on DigitalOcean, Hetzner and AWS

Short answer

A VPS keeps OpenClaw away from your personal files, but it sits on the public internet from day one. Allow only SSH in the cloud firewall, run OpenClaw as a non-root user, keep the Gateway on loopback, and reach the dashboard through an SSH tunnel or Tailscale Serve. Never open port 18789. Then run openclaw security audit --deep.

Firewall: inbound SSH from your own network only. No rule for 18789.
Run OpenClaw as its own non-root user, signed into dedicated accounts, not your personal ones.
Dashboard access: SSH tunnel or Tailscale Serve, with the Gateway bound to loopback.
On Docker, published ports can skip UFW. Filter them in the DOCKER-USER chain and scan from outside.

Is a VPS a good place to run OpenClaw?

It can be. A VPS keeps the agent away from your personal files, browser sessions and password manager. Microsoft's Defender team recommends exactly that: run OpenClaw on a dedicated virtual machine or device, with dedicated credentials, not on a daily workstation.

The catch is that a VPS starts life on the public internet. Hunt.io's February 2026 scan found that 98.6% of exposed OpenClaw instances were on cloud or hosting infrastructure. DigitalOcean was the single biggest host, with 35.2% of the instances it enriched. Those were mostly deliberate server installs with the dashboard left reachable.

So the goal of this setup is simple: nothing but SSH should answer from the internet. OpenClaw's own VPS docs say the same. Harden admin access first, keep the Gateway on loopback, and use an SSH tunnel or Tailscale Serve to reach it.

The steps below follow OpenClaw's DigitalOcean and Hetzner install guides. OpenClaw's VPS page says AWS EC2 and Lightsail also work well, and the same steps apply there: AWS calls its firewall a security group.

Step 1: How should I create the server?

Use a clean base image. OpenClaw's DigitalOcean guide uses Ubuntu 24.04 LTS and says to avoid third-party Marketplace 1-click images unless you've reviewed their startup scripts and firewall defaults.
Add your SSH key when you create the server, rather than using a password.
Size it for your setup. DigitalOcean's 1 GB plan works with swap added, and Hetzner's guide asks for 6 GB RAM if you build the Docker image from source.

Step 2: What firewall rules do I need?

Cloud firewall: allow TCP 22 (SSH) from your own network, and nothing else inbound. Don't add a rule for 18789. In Hetzner that's a Cloud Firewall, in DigitalOcean a Cloud Firewall, and in AWS a security group.

Host firewall: if you also use UFW on the server, allow SSH *before* you enable it, or you'll lock yourself out. From OpenClaw's Hetzner guide:

apt-get update
apt-get install -y ufw
ufw allow OpenSSH
ufw enable
ufw status verbose

Two firewalls is fine. The cloud one protects you if the host one is misconfigured, and the other way round.

Step 3: Should OpenClaw run as root?

No. Use root only to set up the system, then run OpenClaw as its own user so its state lives in that user's home folder and the Gateway runs as that user's service. From OpenClaw's DigitalOcean guide:

adduser openclaw
usermod -aG sudo openclaw
loginctl enable-linger openclaw
su - openclaw
openclaw --version

Then run onboarding as that user, which sets up model auth, channels, a Gateway token and the background service:

openclaw onboard --install-daemon

Keep that user's accounts dedicated to the agent. OpenClaw's docs say not to sign the runtime into personal Apple or Google accounts or personal password-manager or browser profiles. Give the agent its own API keys too, so you can revoke them without breaking anything else.

Step 4: How do I reach the dashboard without opening a port?

The Gateway binds to loopback by default, so it only answers on the server itself. Leave it that way and pick one of these.

Option A: SSH tunnel (simplest). From your laptop, using the command in OpenClaw's Hetzner guide (swap root for the user you log in as):

ssh -N -L 18789:127.0.0.1:18789 root@<vps-ip>

Leave it running and open http://127.0.0.1:18789/ on your laptop. If the tunnel fails with administratively prohibited, the Hetzner guide explains the AllowTcpForwarding local setting for the server's SSH config.

Option B: Tailscale Serve. Install Tailscale on the server and your devices, then switch OpenClaw's Tailscale mode to serve. The Gateway stays on 127.0.0.1, and only devices on your tailnet can reach it over HTTPS. The OpenClaw CLI needs the Gateway stopped while you change config:

openclaw gateway stop
openclaw config set gateway.tailscale.mode serve
openclaw gateway start

Once Tailscale works, you can restrict public SSH in your cloud firewall too, which is the order OpenClaw's VPS docs suggest. Don't use Tailscale Funnel for this. Funnel publishes the Gateway to the public internet.

Step 5: What changes if I use Docker?

Docker is a supported setup, and OpenClaw's Hetzner guide uses it. Watch two things:

The bind. OpenClaw's container images default to an exposed bind, so pair them with token auth and a firewall. Don't publish 18789 on every interface.
Published ports can skip UFW. Ports you publish with -p or Compose ports: go through Docker's own forwarding rules, not just UFW's. OpenClaw's network exposure page has a ready-made rule set for the DOCKER-USER chain in /etc/ufw/after.rules, plus a matching IPv6 file if Docker IPv6 is on. After adding it, the docs check it like this:

ufw reload
iptables -S DOCKER-USER
ip6tables -S DOCKER-USER

The docs also warn against hardcoding interface names like eth0, because they vary between VPS images and a mismatch can silently skip your deny rule.

Step 6: How do I check the result?

Run the audit on the server:

openclaw security audit --deep

You want no criticals in gateway.*, browser.* or security.exposure.*. Our audit guide explains each finding and what to do about it.

Scan from outside. From a different network (not from the server), scan your own server's public IP:

nmap -sT -p 1-65535 <public-ip> --open

Only SSH should show as open. Our exposure guide covers what to do if anything else answers.

Step 7: How do I keep it that way?

Update on a schedule. Preview first, then update:

openclaw update --dry-run
openclaw update

On Docker, pull the new image and recreate the container. Read release notes for breaking changes. Run openclaw --version and compare it against OpenClaw's security advisories. Our checklist lists the current minimum version.

Back up, carefully. openclaw backup create makes an archive of your state. OpenClaw's docs say to assume anything under ~/.openclaw may contain secrets, so store backups like you'd store your keys. Microsoft points out that a backup of ~/.openclaw/workspace/ alone holds the agent's working state without the credentials.

Re-check after every change. Re-run the audit and the outside scan after each new channel, skill, plugin, proxy or firewall change. OpenClaw's exposure runbook says to make one exposure change at a time and understand it before the next.

What about a reverse proxy and a domain?

You don't need one to use OpenClaw on a VPS, and it's the setup most likely to expose you. Hunt.io found many exposed instances on ports 80 and 443, behind proxies like nginx. If you do put the Gateway behind a proxy, follow OpenClaw's exposure runbook: set gateway.trustedProxies to the proxy's address, keep allowRealIpFallback off, make sure the proxy overwrites X-Forwarded-For, and keep token auth on. Then test the domain from a private browser window.

Where next?

The VPS is only the host. What the agent can do once it's running, like its tools, skills, keys and bills, is in our 12-point security checklist. See the OpenClaw hub for all our OpenClaw guides, or paste your audit output into the free check.

Frequently asked questions

Is a VPS safer than my laptop?

For isolation, usually yes. Microsoft's security team advises running OpenClaw on a dedicated VM or device, not a daily workstation. But a VPS is internet-facing by default. Hunt.io found 98.6% of exposed OpenClaw instances on cloud or hosting providers. It's only better if you lock it down.

Should I open port 18789?

No. OpenClaw's Hetzner guide says not to add a public inbound rule for TCP 18789. Your cloud firewall only needs to allow SSH. Reach the dashboard through an SSH tunnel or Tailscale Serve instead.

Tailscale or SSH tunnel?

Both keep the Gateway on loopback. An SSH tunnel needs nothing extra and suits occasional dashboard use. Tailscale Serve gives HTTPS access from all your devices and lets you restrict or close public SSH later. Avoid Tailscale Funnel, which makes the Gateway public.

Should I run it in Docker?

Docker is a supported VPS setup, and it's how OpenClaw's Hetzner guide runs it. Two cautions: container images default to an exposed bind, and published Docker ports can skip your host firewall. Filter them in the DOCKER-USER chain and confirm with an outside scan.

OpenClaw on a VPS: Locking Down Your Setup on DigitalOcean, Hetzner and AWS

Is a VPS a good place to run OpenClaw?

Step 1: How should I create the server?

Step 2: What firewall rules do I need?

Step 3: Should OpenClaw run as root?

Step 4: How do I reach the dashboard without opening a port?

Step 5: What changes if I use Docker?

Step 6: How do I check the result?

Step 7: How do I keep it that way?

What about a reverse proxy and a domain?

Where next?

Frequently asked questions

Sources

Get the weekly plain-English agent security brief