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

Railway

One-click, browser setup

Northflank

One-click, browser setup

DigitalOcean

Simple paid VPS

Oracle Cloud

Always Free ARM tier

Fly.io

Fly Machines

Hetzner

Docker on Hetzner VPS

GCP

Compute Engine

Azure

Linux VM

exe.dev

VM with HTTPS proxy

Raspberry Pi

ARM self-hosted

AWS (EC2 / Lightsail / free tier) also works well. A community video walkthrough is available at 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, Platforms hub.

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.

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 CLI.

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:

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.

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:

sudo systemctl edit openclaw

[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.