--- 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" --- # 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 One-click, browser setup One-click, browser setup Simple paid VPS Always Free ARM tier Fly Machines Docker on Hetzner VPS Compute Engine Linux VM VM with HTTPS proxy ARM self-hosted **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`, require `gateway.auth.token` or `gateway.auth.password`. Related pages: [Gateway remote access](/gateway/remote), [Platforms hub](/platforms). ## 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/canvas and `system.run` capabilities while the Gateway stays in the cloud. 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. - `OPENCLAW_NO_RESPAWN=1` avoids extra startup overhead from a self-respawn path. - First command run warms the cache; subsequent runs are faster. - For Raspberry Pi specifics, see [Raspberry Pi](/install/raspberry-pi). ### systemd tuning checklist (optional) For VM hosts using `systemd`, consider: - Add service env for a stable startup path: - `OPENCLAW_NO_RESPAWN=1` - `NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache` - Keep restart behavior explicit: - `Restart=always` - `RestartSec=2` - `TimeoutStartSec=90` - Prefer SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties. Example: ```bash sudo systemctl edit openclaw ``` ```ini [Service] Environment=OPENCLAW_NO_RESPAWN=1 Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache Restart=always RestartSec=2 TimeoutStartSec=90 ``` How `Restart=` policies help automated recovery: [systemd can automate service recovery](https://www.redhat.com/en/blog/systemd-automate-recovery).