Hermes Agent Operator self-hosts Hermes agents on Kubernetes by managing each agent as a HermesAgent custom resource. Hermes is built for personal use, so running it across a team tends to drift: configurations diverge, skills go out of sync, and there is no shared record of what each agent does or can access. The operator gives each agent one manifest that declares its config, workspace files, skills, crons, and bundles, and it keeps the running agent in sync with that declaration.
The operator reconciles only what the manifest declares. Packages and plugins that Hermes installs on its own at runtime fall outside its control, and only the agent's data volume persists across pod restarts. Init containers install declared pip and npm packages onto that volume, and removing a package from the list reinstalls the remaining set so the installed state matches the declaration.
Beyond the agent container, the resource covers optional sidecars (a SearXNG instance for web search without an external API key and a Camofox Browser instance for browser automation), a ServiceAccount and Role, a default-deny NetworkPolicy, a Service and Ingress, and pod scheduling settings. A companion Hermes skill lets a running agent scaffold and apply HermesAgent manifests itself. Hermeum, a separate team platform with a dashboard, templates, and shared credentials, is built on this operator.
The operator sends an anonymous heartbeat through PostHog carrying only a random per-start deployment ID and the operator version, and the heartbeat can be turned off. Reconciliation metrics stay in the cluster.
Features
- Declarative agents: one custom resource holds an agent's config, workspace files, skills, crons, and slash-command bundles
- Config sources: Hermes config inline as free-form YAML or read from a ConfigMap, with changes triggering a reconcile and restart
- Gateway API and webhooks: optional built-in API server and HMAC-signed webhook ingress, with keys generated and stored in a Secret
- Persistent storage: a volume for agent data, optionally restored from a VolumeSnapshot
- Packages and plugins: declared pip and npm packages, Hermes plugins pinned to a commit, and skills reinstalled on every pod start
- Scheduled prompts: crons with interval or cron syntax, delivery targets such as Slack, Telegram, or Discord, per-job model pins, and monitor mode
- Profiles: named Hermes profiles with their own config, skills, and crons sharing one multiplexed gateway
- Sidecars: optional SearXNG for web search and Camofox Browser for browser automation
- Security: generated ServiceAccount and Role with extra rules, cloud identity annotations, and a default-deny NetworkPolicy
- Status reporting: init container failures surface as a condition naming the failing step and its log tail
