Deploy Hermes Agent in a dedicated PVE VM

[kelchm]

Status, 2026-08-27: The pve-sbx cluster exists and its core cluster, network, backup, and isolated-restore paths are working. Hermes remains blocked on the PVE workload-placement gate: storage qualification and the remaining commissioning checks must clear first.

Goal

Run an always-on Hermes Agent instance in a dedicated VM on the Proxmox VE cluster.

Hermes is a stateful singleton with persistent sessions, memories, skills, OAuth credentials, and scheduled jobs. A dedicated VM is a better fit than a horizontally scaled Kubernetes workload and provides a clear security boundary for agent-executed tools.

Dependency

• Clear the PVE workload-placement gate documented in docs/plans/20260814-pve-cluster.md and proxmox/README.md.

The cluster was commissioned on 2026-08-27, but no irreplaceable workload is cleared for placement yet. The three-node SN770 idle/I/O qualification must pass against the post-ASPM firmware baseline, and the remaining recovery/operational gates must be reviewed before Hermes becomes an always-on stateful tenant.

Proposed approach

• Provision a small Debian or Ubuntu VM on PVE.
• Start with roughly 2–4 vCPUs, 6–8 GiB RAM, and 32–64 GiB of disk.
• Install Hermes and run its gateway as a persistent service.
• Join the VM to the tailnet; do not expose the Hermes API publicly.
• Configure the desired model providers and subscription authentication.
• Use the Docker terminal backend so agent-executed commands run in a sandbox inside the VM.
• Persist and back up the Hermes data directory containing configuration, sessions, memory, skills, and OAuth state.
• Restrict network access and avoid giving the agent credentials for the PVE host or other management systems.
• Enable unattended-run guardrails and verify restart behavior.

Acceptance criteria

• The PVE plan explicitly clears ordinary stateful workload placement.
• Hermes runs continuously in a dedicated PVE VM.
• The gateway is reachable from approved tailnet clients.
• No Hermes API or dashboard port is publicly exposed.
• Model-provider authentication works after a VM reboot.
• Agent tool execution is isolated through the Docker backend.
• Sessions, memories, skills, and scheduled jobs survive restart.
• The VM is covered by a tested PVE backup and restore procedure with recorded recovery time.
• Recovery steps and routine upgrade steps are documented.