| --- |
| summary: "Run OpenClaw on a Linux server or cloud VPS — provider picker, architecture, and tuning" |
| read_when: |
| - You want to run the Gateway on a Linux server or cloud VPS |
| - You need a quick map of hosting guides |
| - You want generic Linux server tuning for OpenClaw |
| title: "Linux server" |
| sidebarTitle: "Linux Server" |
| --- |
| |
| Run the OpenClaw Gateway on any Linux server or cloud VPS. This page helps you |
| pick a provider, explains how cloud deployments work, and covers generic Linux |
| tuning that applies everywhere. |
|
|
| ## Pick a provider |
|
|
| <CardGroup cols={2}> |
| <Card title="Azure" href="/install/azure">Linux VM</Card> |
| <Card title="Daytona" href="/install/daytona">Cloud sandbox with preview URLs</Card> |
| <Card title="DigitalOcean" href="/install/digitalocean">Simple paid VPS</Card> |
| <Card title="exe.dev" href="/install/exe-dev">VM with HTTPS proxy</Card> |
| <Card title="Fly.io" href="/install/fly">Fly Machines</Card> |
| <Card title="GCP" href="/install/gcp">Compute Engine</Card> |
| <Card title="Hetzner" href="/install/hetzner">Docker on Hetzner VPS</Card> |
| <Card title="Hostinger" href="/install/hostinger">VPS with one-click setup</Card> |
| <Card title="Northflank" href="/install/northflank">One-click, browser setup</Card> |
| <Card title="Oracle Cloud" href="/install/oracle">Always Free ARM tier</Card> |
| <Card title="Railway" href="/install/railway">One-click, browser setup</Card> |
| <Card title="Render" href="/install/render">Managed web service</Card> |
| <Card title="Raspberry Pi" href="/install/raspberry-pi">ARM self-hosted</Card> |
| <Card title="Upstash Box" href="/install/upstash">SSH-managed sandbox box</Card> |
| </CardGroup> |
|
|
| **AWS (EC2 / Lightsail / free tier)** also works well. |
| A community video walkthrough is available at |
| [x.com/techfrenAJ/status/2014934471095812547](https://x.com/techfrenAJ/status/2014934471095812547) |
| (community resource -- may become unavailable). |
|
|
| ## How cloud setups work |
|
|
| - The **Gateway runs on the VPS** and owns state + workspace. |
| - You connect from your laptop or phone via the **Control UI** or **Tailscale/SSH**. |
| - Treat the VPS as the source of truth and **back up** the state + workspace regularly. |
| - Secure default: keep the Gateway on loopback and access it via SSH tunnel or Tailscale Serve. |
| If you bind to `lan` or `tailnet`, the Gateway requires a shared secret |
| (`gateway.auth.token` or `gateway.auth.password`) unless auth is delegated to a |
| trusted proxy. |
|
|
| Related pages: [Gateway remote access](/gateway/remote), [Platforms hub](/platforms). |
|
|
| ## Harden admin access first |
|
|
| Before you install OpenClaw on a public VPS, decide how you want to administer |
| the box itself. |
|
|
| - For 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, |
| then restrict public SSH. |
| - Without Tailscale: apply the equivalent hardening for your SSH path before |
| exposing more services. |
| - This is separate from Gateway access. You can still keep OpenClaw bound to |
| loopback and use an SSH tunnel or Tailscale Serve for the dashboard. |
|
|
| Tailscale-specific Gateway options live in [Tailscale](/gateway/tailscale). |
|
|
| ## Shared company agent on a VPS |
|
|
| Running a single agent for a team is a valid setup when every user is in the |
| same trust boundary and the agent is business-only. |
|
|
| - Keep it on a dedicated runtime (VPS/VM/container + dedicated OS user/accounts). |
| - Do not sign that runtime into personal Apple/Google accounts or personal browser/password-manager profiles. |
| - If users are adversarial to each other, split by gateway/host/OS user. |
|
|
| Security model details: [Security](/gateway/security). |
|
|
| ## Using nodes with a VPS |
|
|
| You can keep the Gateway in the cloud and pair **nodes** on your local devices |
| (Mac/iOS/Android/headless). Nodes provide local screen/camera and `system.run` |
| capabilities while the Gateway stays in the cloud. A paired Mac can also present |
| hosted widgets in its native panel. |
|
|
| Docs: [Nodes](/nodes), [Nodes CLI](/cli/nodes). |
|
|
| ## Startup tuning for small VMs and ARM hosts |
|
|
| If CLI commands feel slow on low-power VMs (or ARM hosts), enable Node's module compile cache: |
|
|
| ```bash |
| 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` improves repeated command startup times; the first run warms the cache. |
| - `OPENCLAW_NO_RESPAWN=1` keeps routine Gateway restarts in-process, which avoids extra process handoffs and keeps PID tracking simple on small hosts. |
| - For Raspberry Pi specifics, see [Raspberry Pi](/install/raspberry-pi). |
|
|
| ### systemd tuning checklist (optional) |
|
|
| For VM hosts using `systemd`, consider: |
|
|
| - Service env for a stable startup path: `OPENCLAW_NO_RESPAWN=1` and |
| `NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache` |
| - A longer startup timeout for slow hosts: `TimeoutStartSec=90`. |
| - The managed unit owns the generic restart policy: `Restart=always`, `RestartSec=5`. |
| - SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties. |
|
|
| The standard `openclaw onboard --install-daemon` path installs a systemd user |
| unit; customize only host-specific startup settings with: |
|
|
| ```bash |
| systemctl --user edit openclaw-gateway.service |
| ``` |
|
|
| ```ini |
| [Service] |
| Environment=OPENCLAW_NO_RESPAWN=1 |
| Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache |
| TimeoutStartSec=90 |
| ``` |
|
|
| If you deliberately installed a system unit instead, edit it via |
| `sudo systemctl edit openclaw-gateway.service`. |
|
|
| For the canonical managed unit body and its restart policy, see the [Gateway runbook](/gateway). |
|
|
| For Linux OOM behavior, child process victim selection, and `exit 137` |
| diagnostics, see [Linux memory pressure and OOM kills](/platforms/linux#memory-pressure-and-oom-kills). |
|
|
| ## Related |
|
|
| - [Install overview](/install) |
| - [DigitalOcean](/install/digitalocean) |
| - [Fly.io](/install/fly) |
| - [Hetzner](/install/hetzner) |
| - [Ansible](/install/ansible) — automated deployment to remote Debian/Ubuntu servers with Tailscale VPN and firewall isolation |
| - [Kubernetes](/install/kubernetes) — a minimal Kustomize starting point when you run the Gateway on a cluster instead of a single VPS |
| - [macOS VMs](/install/macos-vm) — a sandboxed macOS VM when you need macOS itself (iMessage) rather than a Linux host |
|
|
