OpenClaw VPS Deploy

Deploy a custom OpenClaw repo (official or forked) to a Hostinger VPS and make it accessible via the cloud. Use when setting up a new OpenClaw instance on a...

Security Scan

The skill largely does what it claims (deploy OpenClaw to a VPS), but it omits and mishandles sensitive details (API keys, local vault access), and the provided script performs privileged remote operations — review before use.

Purpose & Capability

The skill's purpose (deploy OpenClaw to Hostinger VPS) matches the shipped code: the script connects via SSH, installs Node, installs/builds OpenClaw, writes config, configures systemd and UFW. However, the registry metadata declares no required environment variables or primary credential while both the SKILL.md and the script clearly rely on ANTHROPIC_API_KEY (and optionally OPENAI_API_KEY). That omission is an incoherence: anyone deploying OpenClaw will legitimately need an API key, so the skill should declare that upfront.

Instruction Scope

Runtime instructions and the script read local secrets (~/.openclaw/secrets.json) and environment variables, generate and place an auth token, and run many privileged remote commands as root (apt installs, curl | bash, writing /etc/systemd/system, enabling services, opening firewall ports). Reading a local vault and writing tokens locally (SKILL.md claims saving token to local vault) is outside a minimal deployer's needs unless clearly documented and consented to; the SKILL.md and code are not fully consistent about what is saved locally vs remotely. The script also executes unverified upstream actions (npm install -g, git clone of arbitrary repos) which will be executed on the remote host.

Install Mechanism

There is no install spec for the skill itself (no code installed locally by the platform) — low platform install risk. The script will pip-install paramiko locally if missing and use apt/curl on the remote host, including running the NodeSource setup script via curl | bash and npm/pnpm operations. These are typical for remote provisioning, but curl | bash and cloning arbitrary git repos are higher-risk operations on the target VPS and should be run only against trusted sources.

Credentials

The skill did not declare required environment variables in registry metadata, yet both documentation and the script require an ANTHROPIC_API_KEY (and optionally OPENAI_API_KEY). The script will read keys from environment or from a local vault (~/.openclaw/secrets.json). Reading the user's local secrets file is a significant sensitive action and is not reflected in the skill's declared requirements — this mismatch increases the risk of accidental exposure or misuse of credentials.

Persistence & Privilege

The skill does not request 'always: true' and does not modify other skills or platform configuration. It creates and enables a systemd service on the remote VPS (expected for a deploy tool) and opens firewall ports — those are privileged remote actions but coherent with the deploy purpose. Autonomous invocation is allowed by default but not by itself a red flag here.

What to consider before installing

Plain-language considerations before installing or running this skill: - This skill will ask you to provide an SSH private key and will run as root on the remote VPS (apt installs, curl|bash, write systemd services, open firewall ports). Only run it against servers you control and trust. - The SKILL.md and deploy.py expect ANTHROPIC_API_KEY (and optionally OPENAI_API_KEY) but the package metadata does not declare these requirements — assume you must supply these keys. Check where the keys are stored: the script reads ~/.openclaw/secrets.json if present. Confirm you are comfortable with that file being read. - The deploy script may write tokens/config files both on the remote machine and (per the docs) to a local vault; locate and inspect any local secrets file the script creates. If you do not want secrets stored locally, inspect/modify the script before running. - The script will clone and build arbitrary git repos you pass; only deploy code from repositories you trust. A malicious fork would execute code on the VPS as root. - The script runs 'curl https://deb.nodesource.com/setup_22.x | bash' on the remote host. This is a convenience but carries the usual security trade-offs of piping remote scripts into shell. Prefer to review the script or use a curated package source. - Because part of deploy.py was truncated in the provided bundle, review the full file before use to ensure there are no extra operations (e.g., transmitting secrets off-host) in the omitted portion. Recommended safe steps: inspect full deploy.py locally, test on an isolated/staging VPS first, back up any keys or configs, and only supply API keys and SSH keys after you confirm exactly where they will be written and stored.

Deploy OpenClaw (official or custom fork) to a Hostinger VPS with full cloud access.

Quick Deploy

# Official package (most common)
python3 scripts/deploy.py \
  --ip 187.124.84.25 \
  --key ~/.ssh/id_ed25519 \
  --name "Koda"

# Custom git fork
python3 scripts/deploy.py \
  --ip 187.124.84.25 \
  --key ~/.ssh/id_ed25519 \
  --repo https://github.com/your-org/openclaw \
  --name "Koda" \
  --gw-port 18789

The script auto-reads ANTHROPIC_API_KEY from the local OpenClaw vault (~/.openclaw/secrets.json) or environment. Pass --anthropic to override.

What the Script Does

1. Connects via SSH (key auth — required, password auth often disabled on Hostinger)
2. Installs Node.js 22 via nodesource apt repo
3. Installs OpenClaw — either npm install -g <package> or git clone + pnpm build
4. Writes openclaw.json with correct schema (see critical notes below)
5. Installs systemd service — auto-starts on reboot, restarts on crash
6. Opens UFW ports — SSH (22) + gateway port
7. Saves auth token to local vault as OPENCLAW_VPS_<IP>_TOKEN

SSH Key on WSL2

The user's Windows SSH key is accessible at /mnt/c/Users/<username>/.ssh/id_ed25519 in WSL2. Copy it with correct permissions before use:

cp /mnt/c/Users/charl/.ssh/id_ed25519 /tmp/vps_key
chmod 600 /tmp/vps_key
python3 scripts/deploy.py --ip 1.2.3.4 --key /tmp/vps_key

Getting the Server IP

From the Hostinger tab in the Control dashboard (VPS Servers section), or via API:

mcporter call hostinger-api.VPS_getVirtualMachinesV1 2>&1 | \
  python3 -c "import json,sys; [print(v['id'], v['ipv4'][0]['address'], v['hostname']) for v in json.load(sys.stdin) if v.get('ipv4')]"

Critical Notes (Read Before Manually Deploying)

See references/gotchas.md for full details on every failure mode. Key points:

1. Never use openclaw gateway start as ExecStart — use openclaw gateway --bind lan --auth token --allow-unconfigured
2. Config schema: use agents.list[] not agents.default (causes schema error)
3. Set gateway.mode — required, use "remote" for cloud access
4. Set XDG_RUNTIME_DIR=/run/user/0 in systemd + mkdir -p /run/user/0
5. Add public IP to allowedOrigins — otherwise the UI blocks non-localhost connections
6. Performance: always set OPENCLAW_NO_RESPAWN=1 and NODE_COMPILE_CACHE

Correct openclaw.json Schema

{
  "agents": {
    "defaults": {
      "model": { "primary": "anthropic/claude-sonnet-4-6" }
    },
    "list": [
      { "id": "main", "default": true, "name": "Koda" }
    ]
  },
  "env": {
    "ANTHROPIC_API_KEY": "sk-ant-..."
  },
  "gateway": {
    "port": 18789,
    "bind": "lan",
    "mode": "remote",
    "auth": { "mode": "token", "token": "your-token" },
    "controlUi": {
      "allowedOrigins": [
        "http://localhost:18789",
        "http://127.0.0.1:18789",
        "http://YOUR.SERVER.IP:18789"
      ]
    }
  }
}

Correct systemd Unit

[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/root
ExecStart=/usr/bin/openclaw gateway --bind lan --port 18789 --auth token --allow-unconfigured
Restart=always
RestartSec=5
Environment=HOME=/root
Environment=OPENCLAW_NO_RESPAWN=1
Environment=NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache
Environment=XDG_RUNTIME_DIR=/run/user/0

[Install]
WantedBy=multi-user.target

Managing a Live Instance

# Status
ssh root@SERVER_IP "systemctl status openclaw"

# Logs (live)
ssh root@SERVER_IP "journalctl -u openclaw -f"

# Restart
ssh root@SERVER_IP "systemctl restart openclaw"

# Update OpenClaw (npm)
ssh root@SERVER_IP "npm install -g openclaw && systemctl restart openclaw"

# Update custom fork (git)
ssh root@SERVER_IP "cd /opt/openclaw && git pull && pnpm install && pnpm build && systemctl restart openclaw"

Accessing the UI

Navigate to http://SERVER_IP:18789. When prompted for an auth token, use the value stored in:

• Local vault: OPENCLAW_VPS_<IP_WITH_UNDERSCORES>_TOKEN
• Or retrieve: python3 -c "import json; v=json.load(open('/home/charl/.openclaw/secrets.json')); [print(k,v[k]) for k in v if 'VPS' in k and 'TOKEN' in k]"

Multi-Agent VPS Setup

One VPS can run multiple isolated agents on separate ports, each with its own Cloudflare URL. No core OpenClaw changes needed — use --config-dir per agent.

See references/multi-agent.md for: port allocation, per-agent systemd services, provisioning script, resource planning, and Cloudflare tunnel integration.

# Each agent = separate gateway on a separate port
openclaw gateway --config-dir /root/agents/koda   --port 18789
openclaw gateway --config-dir /root/agents/alex   --port 18790

Dependencies

• paramiko Python package (auto-installed by deploy.py if missing)
• SSH private key with access to the target VPS
• ANTHROPIC_API_KEY in vault or environment