Deutsch
VPS plan
Starter VPS Includes 3 CPU cores, 6 GB RAM, 50 GB NVMe storage, Unlimited bandwidth (policy applies), 1 free snapshot, 1 backup included, IPv4 + IPv6.
How to Self-Host OpenClaw on a VPS
This guide explains how to self-host OpenClaw on a VPS so the gateway, agent workspace, logs, and provider configuration live in a persistent remote environment instead of depending on a local machine. Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it. The VPS gives you NVMe storage, full root access, selectable VPS locations, IPv4/IPv6, and an always-on server environment. You bring your own OpenClaw setup, provider access, API keys, repositories, tools, configuration, updates, and monitoring.
20% welcome offer
$4.40/mo for first 3 months (then $5.50)
OpenClaw Control Panel
Agent Online
root@openclaw-vps:~$ openclaw gateway --persistent --monitor
> ✓ OpenClaw gateway online. Monitoring enabled.
OpenClaw Ready
OpenClaw Runtime Agent gateway
Persistent Ops Workspace files
Provider Config Model access
Secure Key Path Private secrets
Gateway Status Connection checks
Live Metrics Runtime health
Logs + Backups Ops evidence
SSH Root Control Server access
Recommended Quick Setup
Use this path when you want the shortest practical route from VPS order to a usable OpenClaw server workspace, with OpenClaw's official documentation as the source of truth for exact versions, flags, and service behaviour. The full checklist below expands each step.
Who This Guide Is For
This page is for users who want OpenClaw to run from a persistent VPS environment instead of depending on a local desktop session.
Developers moving assistant workflows to a VPS
Use a VPS when assistant runtime, gateway configuration, logs, and dependencies need a stable remote home.
Teams testing channel-connected AI assistants
Keep messaging channels, provider access, and integration experiments in a controlled server environment.
Operators who need persistent logs and configuration
Store runtime output, configuration files, credentials, and troubleshooting context where they can be inspected later.
Builders comfortable maintaining a self-managed Linux server
Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it.
What You Need Before You Start
Before selecting a plan or installing OpenClaw, confirm the server access, runtime path, credentials, firewall exposure, remote-access method, and recovery routine needed for the deployment.
Use a Linux VPS suitable for the selected OpenClaw runtime path, with SSH access and root or sudo access ready before installation.
Have basic terminal knowledge, Git, and the required package managers available for the installer, gateway, or source setup path.
Install Docker only when the chosen OpenClaw path requires containers, and Node.js only for manual Node-based setup.
Prepare your own API keys, provider accounts, model access, repositories, and configuration before connecting the runtime.
Set domain and firewall rules for public interfaces or webhooks, avoid exposing the default gateway/control port directly to the public internet, and take your own backups or a VPS snapshot before production changes.
Choose the OpenClaw Runtime Path
Before running commands, decide how OpenClaw should be installed, updated, restarted, accessed remotely, and recovered on the VPS. Use current upstream documentation as the authority for exact versions, ports, bindings, and flags.
Recommended VPS Requirements
Use these as planning baselines for a small gateway-style deployment. Requirements change with channel count, tools, repository size, logs, background jobs, and any local model inference.
Recommended Architecture
The VPS is the runtime layer. You connect over SSH, configure OpenClaw, and control logs, state, and access. Keep the gateway behind SSH, Tailscale, or another private path unless a webhook requires exposure.
You (Operator)
You connect over SSH and control the full workflow, configuration, security, and updates.
Virtarix VPS
Provides the persistent server with storage, networking, root access, snapshots, and backups.
OpenClaw Runtime
OpenClaw runtime, agents, tools, and gateway processes running on the VPS.
External Services
API and model providers, repositories, tools, and integrations that you connect and manage.
Step-by-Step Setup Flow
Follow this sequence as a practical deployment checklist, but confirm OpenClaw-specific versions, installer flags, ports, bindings, and service commands against current official documentation before production use.
Prepare the VPS, connect over SSH, and create a clean server-side workspace before installing OpenClaw-specific dependencies.
Choose Ubuntu or another Linux distribution supported by the current OpenClaw release. Select the location closest to the user, app, API provider, or team where practical, and start with enough CPU, RAM, and storage for persistent gateway work, logs, source checkouts, and background tasks.
ssh root@YOUR_SERVER_IPsudo apt update && sudo apt upgrade -yCreate a dedicated non-root deployment user for day-to-day project work, then verify that user can connect by SSH and run sudo before disabling root or password login. Reconnect as the deployment user before installing or configuring the agent when your selected runtime path stores user-scoped configuration.
# Create a dedicated non-root user for day-to-day project work
adduser deploy
usermod -aG sudo deployCreate a private operator directory for notes, checks, logs, and backup exports. OpenClaw's own config, credentials, sessions, and default agent workspace are managed through the documented OpenClaw paths unless you deliberately override them.
OPS_HOME="$HOME/openclaw-ops"
mkdir -p "$OPS_HOME/checks" "$OPS_HOME/logs" "$OPS_HOME/backups"
chmod 700 "$OPS_HOME"Install base packages, follow the current upstream install path, and configure gateway, provider, and workspace settings through the documented OpenClaw flow.
sudo apt install -y git curl wget unzip ca-certificates gnupgOpenClaw's current installer handles Node for the recommended Linux-style path. Manual Node or pnpm setup is only needed when you choose a package-manager or source-build path, and container tooling is only relevant when you deliberately choose a documented Docker, VM, or headless deployment path.
OpenClaw upstream docs recommend the installer script for Linux-style environments, with Node handled by the installer. Use onboarding to configure provider and gateway settings, then verify the gateway. If you prefer a package-manager, source, Docker, or VM path, use the current upstream docs and avoid mixing install paths in the same first deployment.
# Recommended OpenClaw installer path for Linux-style environments
curl -fsSL https://openclaw.ai/install.sh | bash
# Run onboarding if the installer did not already launch it, or if you used --no-onboard
openclaw onboard --install-daemon
openclaw gateway statusFor OpenClaw, let onboarding collect provider and gateway settings first, then review the generated configuration using the current documentation. Do not assume a generic environment-template workflow unless the selected source or container path documents it.
openclaw doctor
openclaw gateway status
# Review generated OpenClaw config files according to the current docs before adding more channels.After onboarding, verify that the gateway daemon is running and test the setup through the Control UI, a configured channel, or a CLI command with an explicit agent/session selector. Treat the daemon as the always-on component; use agent commands as functional tests, not as the long-running service itself.
openclaw gateway status
openclaw doctor
openclaw status
# Optional CLI test after an agent exists:
# openclaw agent --agent <AGENT_ID> --message "test runtime" --thinking mediumKeep the selected OpenClaw gateway path observable, lock down access, test the setup, and plan ongoing maintenance.
Use the gateway daemon path created by onboarding when that is the selected deployment model. On Linux user services, enable lingering for the deployment user if the gateway must survive logout. If you deliberately choose a Docker or source path instead, use that path’s documented lifecycle commands rather than generic Compose examples.
openclaw gateway status
openclaw status
openclaw logs --followUse SSH keys where possible, restrict password login if appropriate, enable a firewall, expose only the ports OpenClaw actually needs, keep the default gateway/control port private unless a documented remote-access or webhook path requires exposure, protect generated OpenClaw configuration, provider credentials, gateway/channel secrets, and documented secret references or environment variables, keep packages updated, and use backups or snapshots before major changes.
Why OpenClaw Benefits from a VPS
OpenClaw benefits from a VPS because the assistant runtime, gateway configuration, messaging channels, logs, and tool permissions can stay in one remotely accessible environment.
Always-on assistant runtime
Keep the OpenClaw process and supporting services available without depending on a desktop being open or online.
Messaging and gateway context
Keep channel configuration, provider credentials, webhooks, and gateway logs together on the same server.
Cleaner tool-permission boundary
Use the VPS to separate assistant workspace permissions from local workstation files and unrelated production systems.
Measured integration growth
Pay attention to channel configuration, approval boundaries, workspace permissions, and where logs are written. Keep the assistant workspace narrow at first and expand integrations only after the base runtime is stable.
Security Basics for OpenClaw on a VPS
Use SSH keys where possible and keep key access limited to operators who need server control.
Keep root login limited, and use a non-root deployment user for routine work where practical.
Keep the OpenClaw gateway/control UI on loopback or private access unless public exposure is explicitly documented and protected.
Restrict ports to SSH and intentionally exposed, authenticated services.
Store provider credentials, gateway/channel secrets, and generated OpenClaw config only through the path documented for your selected deployment mode.
Avoid committing real OpenClaw config, provider keys, token/password secrets, or channel credentials.
Review SSH logs, OpenClaw gateway logs, channel access, provider-key usage, source checkout changes, configured agents, and assistant workspace permissions.
Keep OS packages, OpenClaw, and selected runtime dependencies updated through documented update paths.
Snapshot before major OpenClaw, dependency, or channel-configuration changes.
Monitor failed SSH, gateway, and channel-auth attempts.
Rotate exposed provider keys, gateway tokens, and repository credentials quickly.
Keep experiments, broad tool permissions, and untrusted repositories separate from production systems.
Privileged runtime
The server can contain channel configuration, gateway logs, source checkouts, provider credentials, assistant state, and runtime permissions. Keep the default gateway surface private, apply channel allowlists where available, and harden the VPS before production use.
Troubleshooting
Common setup problems to check before blaming the VPS or framework. Start with openclaw status, openclaw gateway status, openclaw logs --follow, openclaw doctor, and openclaw channels status --probe where the selected setup supports them.
Server firewall, wrong IP, or SSH service unavailable
Confirm the VPS is running, check the IP, and verify port 22 or your configured SSH port.
Wrong key, wrong user, or disabled login method
Check ~/.ssh/authorized_keys, user permissions, and your SSH config.
Base packages or runtime packages were not installed Re-run the dependency step and compare runtime versions with current official OpenClaw docs.
The selected OpenClaw install or source path expects a different Node.js or pnpm version Use the installer, version manager, or package-manager path recommended by current upstream docs.
Docker daemon stopped or not installed
This only applies if you deliberately selected a Docker-based OpenClaw path; otherwise inspect openclaw gateway status and the daemon installed during onboarding.
The gateway daemon was not installed, stopped, or the command was started manually from an SSH shell
Re-run or inspect onboarding, confirm openclaw gateway status, and only add a separate service wrapper if the official daemon path is not being used.
A selected OpenClaw gateway, channel webhook, Control UI, or supporting tool is bound to a port already used by another process
Run ss -tulpn and move one service to a different port.
A required OpenClaw gateway, channel webhook, Control UI, or supporting tool port is not open Open only the required authenticated port and keep all other ports restricted.
Configuration is absent or incomplete Compare the generated configuration with the selected deployment path and add only the secrets, providers, bindings, and paths required.
Key is wrong, expired, or lacks access Rotate the key through the provider and update the server configuration through the documented OpenClaw path.
Logs, caches, or repositories grew over time
Check df -h, rotate logs, clean caches, and scale storage if needed.
Too many channel sessions, adapters, source checkouts, or background jobs Reduce concurrency, inspect process memory, and scale the VPS if the workload is valid.
When This Setup Is Not Necessary
Local testing is enough
You may not need a VPS if you are only testing OpenClaw locally, working from one private machine, reviewing a small repository, or experimenting without persistent SSH access.
Server management may be unnecessary
This setup is not ideal if you do not want to manage Linux updates, SSH access, firewall rules, disk usage, credentials, or repository permissions yourself.
Use a VPS for persistent remote state
Use a VPS when the workspace, workflow state, logs, tools, and assistant workflow should stay available in a controlled remote environment.
Ready to run OpenClaw on an always-on VPS?
Deploy an OpenClaw VPS and use this guide as your review checklist while you prepare the setup.
FAQ
Can I run OpenClaw on a VPS?
Yes, if the current OpenClaw release supports the Linux distribution and runtime path you choose. Use this guide together with the official documentation for exact installer, onboarding, gateway, and update commands.
Do I need a GPU VPS for OpenClaw?
Not for the VPS runtime pattern described here. This OpenClaw guide focuses on the gateway, messaging channels, provider access, logs, workspace permissions, and controlled agent tests; verify separate hardware needs if you plan local model inference.
Does Virtarix provide API keys or model access?
No. Bring your own provider accounts, credentials, API keys, model access, repositories, and framework configuration.
What VPS size should I use for OpenClaw?
Start with the Virtarix Starter VPS for a practical first deployment, then scale after measuring CPU, RAM, storage, process count, channel configuration, gateway logs, source checkouts, and assistant runtime boundaries.
Can OpenClaw keep running without my local machine?
Yes, if OpenClaw is run as a server-side gateway or service using a documented daemon, systemd, container, or process-management method. The VPS keeps channel configuration, gateway logs, source checkouts, and assistant runtime boundaries separate from your local desktop session.
Can I use Docker for this setup?
Use Docker only when the official OpenClaw documentation supports it or your deployment design calls for it. Otherwise use the recommended installer/onboarding path and the documented gateway daemon.
Should I expose the OpenClaw gateway port publicly?
No by default. Keep the gateway/control port private on loopback and use SSH tunneling, Tailscale/VPN, or another documented authenticated access path unless a public webhook or channel requires carefully restricted exposure.
Is Virtarix operating OpenClaw for me?
No. Virtarix provides the VPS infrastructure. You install, configure, secure, update, and operate the software you run on it.