OpenClaw can run on a Linux VPS so your assistant remains available when your laptop is asleep. The server runs the Gateway and stores its configuration, workspace, and conversation state. Your laptop connects to that Gateway; it does not need to host another copy of the same assistant.

This walkthrough uses a dedicated Linux account, the official installer, and private dashboard access through SSH. It is intended for a personal deployment. For a shared organization instance, start with the official Linux server guide and its trust-boundary guidance.

Independent guide. Commands and configuration checked against official documentation on October 2, 2026. This is a documentation review, not a claim that every VPS combination has been tested.

Choose a deployment method

Method Best fit Operating responsibility
Native CLI and managed Gateway service A straightforward personal VPS Linux account, service, and backups
Official Docker Compose setup A server already managed with containers Image updates, mounts, and Docker networking
Managed platform Less server administration Platform access, persistent storage, and provider costs

This article follows the native route. Use the Docker installation guide for containers; mixing the two supervisors on one port makes failures harder to diagnose. The Docker setup has different listener and published-port defaults. Before starting Docker on a public host, restrict inbound ports at the provider firewall or security group and verify the actual bindings. An SSH tunnel by itself does not close a public port.

1. Prepare a Linux account and supported runtime

Use an account reserved for OpenClaw, with SSH key access and a home directory. Install and administer the assistant as that account so its config and service belong to the same user. Avoid using your personal cloud credentials or browser profile on the server.

Before changing SSH or firewall rules, verify access in a second terminal. Keep your existing session open until the new path works. The dashboard does not need a publicly accessible port for this setup.

Check the server runtime:

node --version

The current Node installation guide is the authority for supported releases. As of this review, the quickstart requires Node.js 24.16+ or 26.1+. The older Node 18/20 instructions previously on this page should not be used for a current installation.

A cloud model keeps model inference off the VPS. Local inference, browser automation, and concurrent tasks have different resource needs; measure the intended workload before choosing a larger instance. Compare providers in our VPS guide.

2. Install OpenClaw and complete onboarding

From the OpenClaw user's SSH session, run the official Linux installer:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw --version

The installer starts onboarding. Choose your model provider and verify that its connection works. If you need to resume setup later:

openclaw onboard

Your provider credentials and Gateway authentication are separate: one allows model calls; the other controls access to the assistant. Use the onboarding reference for the authentication method supported by your provider. Do not place an actual key in a public configuration example or support ticket.

3. Keep the Gateway private

Inspect the active file and validate it:

openclaw config file
openclaw config get gateway.bind
openclaw config validate

The usual configuration file is ~/.openclaw/openclaw.json, using JSON5. For this native SSH-tunnel deployment, explicitly set the Gateway to loopback; do not assume an existing installation already has that setting:

openclaw config set gateway.bind loopback
openclaw config validate

Preserve the authentication configured by onboarding. A private listener is one part of access control, not a reason to remove credentials. See the configuration guide for safe changes.

4. Install the managed Gateway service

If onboarding left the Gateway running in the foreground, stop that foreground process with Ctrl+C before installing its background service:

openclaw gateway install
openclaw gateway status
openclaw gateway health

On Linux, OpenClaw installs a systemd user service. Use the account and profile that own it when checking or restarting it. The official service reference documents lifecycle options and recovery.

On a VPS, verify the user service survives logout and reboot. Where your Linux setup requires lingering for unattended user services, an administrator can enable it for the actual OpenClaw account:

sudo loginctl enable-linger openclaw

Here openclaw is an example Linux username; replace it with yours. Reconnect after a planned reboot and run openclaw gateway status again. A successful installation message alone does not prove the service survives a reboot.

5. Open the dashboard through SSH

Run this on your laptop, replacing the username and host:

ssh -N -L 18789:127.0.0.1:18789 openclaw@your-server

Keep that terminal connected and open http://127.0.0.1:18789/ locally. Authenticate with the Gateway credentials created during onboarding. If you already run a local Gateway on that port, choose a different local tunnel port:

ssh -N -L 18790:127.0.0.1:18789 openclaw@your-server

Then use http://127.0.0.1:18790/. The server still listens on 18789. See official remote access before replacing this with Tailscale or a reverse proxy; public deployments need deliberate authentication, proxy trust, and origin settings.

6. Verify a useful task before adding channels

Send a short message in the Control UI. Check that it receives a model response, then test one task using a disposable workspace file. Add Telegram or WhatsApp only after the browser session works. This separates Gateway, provider, and channel failures.

If the page opens but replies fail:

openclaw status
openclaw doctor
openclaw logs --follow

A dashboard can load while a provider key is invalid or its quota is exhausted. Match the symptom to the installation troubleshooting guide, rather than reinstalling immediately.

7. Back up before updates

Keep backups of state and the workspace outside the VPS. A snapshot on the same disk will not help if the account or disk is lost. The official backup reference explains archive contents and verification.

Record your installed version and authentication method before a planned update. After updating, validate config, check Gateway health, and repeat the same small task used during setup. A restart can fix a changed service runtime, but it cannot repair a missing provider credential.

Read the upgrade guide and security checklist before changing a working deployment.

FAQ

Does OpenClaw need Nginx or a domain name?

No. The SSH-tunnel route above works without either. A public HTTPS endpoint is a separate deployment decision; follow the official remote-access documentation if you need it.

Which port does the Gateway use?

The default is 18789. Check your own config and service status because an existing deployment may use another port.

Why does it stop when I close SSH?

You may still be running a foreground Gateway, or the Linux user service may not remain active after logout. Check the service installation and the user service manager before changing model settings.

Does moving to a VPS make the assistant free?

No. Server billing and model usage are separate. See our OpenClaw cost guide and set provider-side spending limits before adding scheduled tasks.