File size: 6,410 Bytes
63e0fa3 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 | ---
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
|