How to Run the OpenClaw Gateway on a Linux Server or VPS

The OpenClaw Gateway is the part that actually holds your state and workspace. Put it on a Linux server or cloud VPS and it keeps running whether or not your laptop is awake — you just connect to it from wherever you happen to be.

This guide follows the official OpenClaw Linux server documentation: choosing a host, hardening the box before you install anything, and the handful of tuning tweaks that stop a cheap VM from feeling sluggish. Everything here comes straight from that page — nothing invented.

• A Linux server or cloud VPS. OpenClaw documents setups for Railway, Northflank, DigitalOcean, Oracle Cloud, Fly.io, Hetzner, Hostinger, GCP, Azure, exe.dev and Raspberry Pi. AWS (EC2, Lightsail, or the free tier) works well too.
• SSH access to that server, and a plan for how you’ll administer it long term.
• Optional: Tailscale, if you want tailnet-only admin access.
• Optional: systemd on the host, if you want the service-level tuning in Step 6.

Heads up: the Linux server page covers hosting, architecture and tuning — it doesn’t repeat the install commands themselves. Those live on the Install overview and the per-provider guides.

There’s no single "right" host. What actually matters is how much setup you want to do by hand, and whether you need an always-free tier or don’t mind paying a few dollars a month. The docs group the documented options like this:

Tip: if this is your first time, the one-click browser setups (Railway, Northflank, Hostinger) get you to a running Gateway fastest. If you want free and don’t mind ARM, Oracle Cloud’s Always Free tier is the one the docs call out — and the same ARM tuning in Step 5 applies there.

The docs also link a community video walkthrough for AWS on X. It’s flagged as a community resource that may become unavailable, so treat it as a bonus rather than the reference.

This is the step people skip, and it’s the one the docs put first for a reason. Before OpenClaw goes anywhere near a public VPS, decide how you are going to administer the box itself. Sorting this out afterwards means doing it while something valuable is already running on the machine.

Two paths, depending on whether you use Tailscale:

• Tailnet-only admin access: install Tailscale first, join the VPS to your tailnet, verify a second SSH session over the Tailscale IP or MagicDNS name, and then restrict public SSH.
• Not using Tailscale: apply the equivalent hardening to your SSH path before you expose any more services.

Why the "second session" matters: that verification step is your safety net. If you lock down public SSH before confirming the new route works, and the new route doesn’t work, you’ve locked yourself out of your own server. Open the second session, confirm it, then tighten.

Note this is separate from Gateway access. You can harden admin access and still keep OpenClaw bound to loopback, reaching the dashboard over an SSH tunnel or Tailscale Serve.

Worth getting the mental model straight early, because it changes what you back up and where you debug.

• The Gateway runs on the VPS and owns the state and the workspace.
• You connect in from your laptop or phone via the Control UI, or over Tailscale/SSH.
• The VPS is the source of truth. Your laptop is a window into it, not a copy of it.

Back up the state and workspace regularly. The docs are explicit about this. Because everything meaningful lives on the server, a VPS you lose is a workspace you lose — there’s no local copy quietly saving you.

The secure default in the docs is straightforward: keep the Gateway bound to loopback and reach it through an SSH tunnel or Tailscale Serve. Nothing listens on a public interface, so there’s no exposed surface to get wrong.

If you do bind wider, the rules change:

Bind to lan or tailnet and the Gateway requires a shared secret — either gateway.auth.token or gateway.auth.password — unless authentication is delegated to a trusted proxy.

Deeper detail lives in Gateway remote access and Tailscale.

If CLI commands feel sluggish on a low-powered VM — or on an ARM host like Oracle’s free tier or a Raspberry Pi — the usual culprit isn’t the network. It’s Node re-compiling modules on every invocation. Turning on Node’s module compile cache fixes it.

Append this to your shell profile:

# Only append if the line isn't already in ~/.bashrc
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   # reload so the vars apply to this session too

What each piece is doing:

• NODE_COMPILE_CACHE — improves repeated command startup times. The first run warms the cache, so don’t judge it by that one; the runs after are the fast ones.
• OPENCLAW_NO_RESPAWN=1 — keeps routine Gateway restarts in-process. That avoids extra process handoffs and keeps PID tracking simple on small hosts.
• The grep -q ... || guard means you can run this more than once without stacking duplicate lines into your ~/.bashrc.

Running a Raspberry Pi? There are Pi-specific notes in the Raspberry Pi guide.

Shell environment variables only apply to your shell. If the Gateway runs as a systemd service, it needs those same variables at the service level — plus an explicit restart policy so it comes back on its own after a crash or a reboot.

The standard openclaw onboard --install-daemon path installs a systemd user unit. Edit it with:

systemctl --user edit openclaw-gateway.service

Then add:

[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always      # bring the service back automatically
RestartSec=2        # wait 2s between restart attempts
TimeoutStartSec=90  # allow a slow cold start on a small VM

If you deliberately installed a system unit instead of the user unit, edit it with sudo systemctl edit openclaw-gateway.service.

One more from the checklist: prefer SSD-backed disks for your state and cache paths. Random-I/O on slow storage is what makes cold starts drag.

Pairing local nodes. A cloud Gateway has no screen, no camera, and no local machine to act on. You can close that gap by keeping the Gateway in the cloud and pairing nodes on your own devices (Mac, iOS, Android, or headless). Nodes provide local screen, camera and canvas plus system.run capabilities, while the Gateway stays where it is.

See Nodes and Nodes CLI.

Running one shared agent for a team? The docs call this valid — but only when every user sits inside the same trust boundary and the agent is business-only. If that holds:

• Keep it on a dedicated runtime: VPS, VM or container, with a dedicated OS user and dedicated accounts.
• Don’t sign that runtime into personal Apple or Google accounts, or personal browser and password-manager profiles.
• If users are adversarial to each other, split by gateway, host, or OS user instead of sharing one.

• Pick a host — one-click (Railway, Northflank, Hostinger), paid VPS (DigitalOcean, Hetzner), free ARM (Oracle Cloud), or AWS.
• Harden admin access before installing, and verify a second session before restricting public SSH.
• The Gateway on the VPS owns state and workspace — back them up regularly.
• Keep the Gateway on loopback; reach it via SSH tunnel or Tailscale Serve.
• Binding to lan or tailnet requires gateway.auth.token or gateway.auth.password, unless a trusted proxy handles auth.
• On small or ARM VMs, enable NODE_COMPILE_CACHE and OPENCLAW_NO_RESPAWN=1.
• For systemd, set the same env vars plus Restart=always, RestartSec=2, TimeoutStartSec=90, and prefer SSD-backed disks.
• Pair local nodes for screen, camera, canvas and system.run while the Gateway stays in the cloud.