mcpField
V
vps-server-management

vps-server-management

github.com/davidondrejCloud & DevOps4.2k60 installsUpdated today
Repository

About vps-server-management

An operational skill for managing a specified set of Hostinger VPS instances and agents running on them. It documents access boundaries, SSH-based workflows, and Hermes maintenance commands.

Key features

  1. 01VPS inventory and roles
  2. 02Access-level guidance
  3. 03On-server agent workflow
  4. 04Hermes update and gateway commands
  5. 05Hermes model configuration

Use cases

  1. 01Check which VPS hosts an agent
  2. 02Choose an appropriate access level
  3. 03Run multi-step work through an on-server agent
  4. 04Update or inspect the Hermes gateway

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/davidondrej/skills --skill vps-server-management

After installing, type/vps-server-managementin Claude Code to confirm it loaded.

Details

From the project README

VPS Server Management

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

Servers (Hostinger VPS) — 3 total

HostnameIPOSPurposeExpires
personal.openclawUbuntu 24.04 (Dokploy)OpenClaw — personal instance
n8n.automationsUbuntu 24.04 (n8n)All n8n workflow automations (primary)
private.hermesUbuntu 24.04Hermes Agent — Discord gateway

SSH as root@<IP>.

Access levels (never share higher than needed)

  1. App login — e.g. <app-login-url>. 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 → personal.openclaw (managed via Dokploy).
  • Hermes → private.hermes (Discord gateway). Setup/config docs in library/hermes/.
  • n8n → n8n.automations.

Hermes ops (on private.hermes)

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/.

Comments

Markdown supported