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

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
  text

  Copy

  lan
  or
  text

  Copy

  tailnet
  , require
  text

  Copy

  gateway.auth.token
  or
  text

  Copy

  gateway.auth.password
  .

Related pages: Gateway remote access, Platforms hub.

Harden admin access first

Before you install OpenClaw on a public VPS, decide how you want to administer the box itself.

• If you want 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.
• If you are not using 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.

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

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:

bash
Copy
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

• text

  Copy

  NODE_COMPILE_CACHE
  improves repeated command startup times.
• text

  Copy

  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

, consider:

• Add service env for a stable startup path:
  • text

    Copy

    OPENCLAW_NO_RESPAWN=1
  • text

    Copy

    NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
• Keep restart behavior explicit:
  • text

    Copy

    Restart=always
  • text

    Copy

    RestartSec=2
  • text

    Copy

    TimeoutStartSec=90
• Prefer SSD-backed disks for state/cache paths to reduce random-I/O cold-start penalties.

For the standard

path, edit the user unit:

bash
Copy
systemctl --user edit openclaw-gateway.service

ini
Copy
[Service]
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Restart=always
RestartSec=2
TimeoutStartSec=90

If you deliberately installed a system unit instead, edit

via .

How

policies help automated recovery: systemd can automate service recovery.

For Linux OOM behavior, child process victim selection, and

diagnostics, see Linux memory pressure and OOM kills.

Related

• Install overview
• DigitalOcean
• Fly.io
• Hetzner