VPS Server Management

← Back to skills

- Use when the user asks to operate an authorized VPS or agent running on a remote host. - Use when SSH, deployment, restart, status, or log inspection is needed with explicit permission.

Category: Backend & Cloud
Repo: antigravity-awesome-skills
Path: skills/vps-server-management/SKILL.md
Updated: 7/12/2026, 11:41:17 PM
Open on GitHubHow to Install

AI Summary

- Use when the user asks to operate an authorized VPS or agent running on a remote host. - Use when SSH, deployment, restart, status, or log inspection is needed with explicit permission. It is useful for API design, databases, authentication, cloud deployment, and serverless. Source: antigravity-awesome-skills (skills/vps-server-management/SKILL.md).

VPS Server Management

When to Use

  • Use when the user asks to operate an authorized VPS or agent running on a remote host.
  • Use when SSH, deployment, restart, status, or log inspection is needed with explicit permission.

Source of truth: library/infrastructure.md (read it for the latest — IPs/expirations change).

Servers (Hostinger VPS) — 3 total

HostnameIPOSPurposeExpires
openclaw-serverUbuntu 24.04 (Dokploy)OpenClaw — personal instance
n8n-serverUbuntu 24.04 (n8n)All n8n workflow automations (primary)
hermes-serverUbuntu 24.04Hermes Agent — Discord gateway (Vilnius, LT)

SSH as root@<IP>.

Access levels (never share higher than needed)

  1. App login — e.g. app.example.hstgr.cloud. Build/edit workflows, no server access. Safest to share.
  2. VPS SSH — root@<IP>. Docker, files, system config. Trusted technical people only.
  3. Hostinger hPanel — hpanel.hostinger.com. Billing, reboot, OS reinstall. Exposes SSH creds + browser terminal, so it grants server access too. The user only.

Managing a VPS via an agent

For multi-step or exploratory work, SSH into the box first and launch the agent ON the VPS (e.g. codex --yolo), then talk to that local-on-server agent — it has full filesystem/process context and avoids fragile SSH round-trips. For short command sequences (update, config change, restart), driving an existing SSH session directly (e.g. via a cmux pane) is fine.

When checking on a remote/on-box agent, send the user one concise status line each time: what it is doing and whether it is on track.

Claude Code cmux note: after Claude finishes, it may prefill a predicted next user message; that draft is Claude, not the user speaking.

Agents on servers

  • OpenClaw → openclaw-server (managed via Dokploy).
  • Hermes → hermes-server (Discord gateway). Setup/config docs in library/hermes/.
  • n8n → n8n-server.

Hermes ops (on hermes-server)

hermes --version            # shows version + commits behind
hermes update               # auto-snapshots, updates deps, rebuilds web UI, restarts gateway itself
hermes gateway status|restart
journalctl --user -u hermes-gateway --since '5 min ago' --no-pager   # gateway logs (systemd USER service)
  • Default model lives in ~/.hermes/config.yaml under model.provider + model.default — NOT in .env. Change via hermes model (interactive) or edit the yaml directly, then hermes gateway restart to propagate to gateways.
  • npm EBADENGINE warnings during update (deps want Node >=24, box runs v22) are non-blocking — do not "fix" them.
  • Deeper docs (Discord/Slack/WhatsApp setup, file structure, vision config): library/hermes/.

Limitations

  • Adapted from davidondrej/skills; verify local paths, tools, credentials, and agent features before acting.
  • For commands, remote access, scheduling, browser automation, or file-changing workflows, get explicit user approval and confirm the target environment first.

Related skills