π©π»βπ» A Helm chart to run Hermes Agent on Kubernetes, community-powered, lightweight
English Β· νκ΅μ΄ Β· Chart docs Β· CONTRIBUTING Β· SECURITY Β· AGENTS
Found this useful? Please give it a β β it helps others find it.
Run Hermes Agent on Kubernetes
with one helm install β works with any LLM provider Hermes supports, scales
down to a single small node, and is verified to actually run, not just render.
A community-powered chart, not an official Nous Research release.
Add the Helm repository (published to GitHub Pages) and install:
helm repo add hermes-agent https://jyje.github.io/hermes-agent-helm
helm repo update
helm install hermes-agent hermes-agent/hermes-agent \
--namespace hermes-agent --create-namespace \
--set-string env.OPENAI_API_KEY='sk-...' \
--waitEach release is also published as an OCI artifact, so you can install
directly from the registry without helm repo add:
helm install hermes-agent oci://ghcr.io/jyje/hermes-agent-helm/hermes-agent \
--namespace hermes-agent --create-namespace \
--set-string env.OPENAI_API_KEY='sk-...' \
--waitOptionally pin --version to a specific released chart version instead of latest.
To install from this repo's source instead (e.g. to try an unreleased change), see Quick start below.
- All of Hermes's provider support, via
values.yaml. Hermes itself already supportsopenai-api,anthropic,gemini,openrouter,nvidia,deepseek, and any OpenAI-compatible endpoint (e.g. LiteLLM) through environment variables β this chart just exposes that config throughvalues.yamland ships ready-to-adapt examples per provider, with no provider baked into the templates. - Lightweight β production. Sized for homelab / single-node / edge clusters
out of the box (one replica, modest requests, a small PVC), and ready for
production by scaling up β not out. Hermes is a single-instance personal
agent (one
HERMES_HOME, one gateway, one memory), so you don't replicate a pod; you run several well-managed instances and group them into a team that shares context over a common gateway channel. See Hermes teams. - Verified end-to-end. CI installs the chart on an ephemeral kind
cluster and runs the bundled test Job (
hermes doctor). When theNVIDIA_API_KEYrepository secret is available, it also runs a livehermes chatround-trip against NVIDIA NIM β not a mock. The Discord-thread leader team has also completed a live human β leader β two members β leader round-trip; Telegram team orchestration remains separate.
Deployment evidence: leader august and members
may/march running as independent releases on kind.
This screenshot does not by itself prove the multi-turn mention loop; see
Hermes teams for the current status.
For the full resource breakdown, configuration model, and provider-by-provider install examples (including messenger integrations), see charts/hermes-agent/README.md.
charts/hermes-agent/ # the Helm chart (see its README for the full values table)
charts/hermes-agent/values-*.yaml # ready-to-adapt examples: providers, Discord/Telegram, LiteLLM (see chart README "More examples")
examples/helm/ # install from Git and from OCI (ghcr.io) + publish guide
examples/argocd/ # ArgoCD Application examples (one per values-*.yaml) + GitOps/SealedSecret pattern
charts/hermes-operator/ # βΈοΈ long-term, not started: possible install chart for an Agent/AgentTeam-CRD operator β placeholder, TBA (see Roadmap)
docs/ # deeper guides: teams.md (group instances into a team), collaboration.md (make them hand off by @mention), roadmap.md
.github/workflows/ # ci (lint + docs-drift + real round-trip on kind) and release (version bump -> tag -> ghcr OCI)
CONTRIBUTING.md # branch model (dev/main + tags) + release-on-version-bump
AGENTS.md # design principles & workflow for contributors
Makefile # docs / lint / template / install / test / package / push
# render & lint
make template
make lint
# install with the generic defaults (set your provider key)
# release name == chart name keeps resources clean (hermes-agent-0, not hermes-agent-hermes-agent-0)
helm upgrade --install hermes-agent ./charts/hermes-agent \
--namespace hermes-agent --create-namespace \
--set-string env.OPENAI_API_KEY='sk-...' --wait
# run the install test (doctor-style Job)
helm test hermes-agent -n hermes-agent
kubectl logs -n hermes-agent -l app.kubernetes.io/component=test --tail=-1
# or start from a ready-made example (provider, Discord/Telegram, LiteLLM, ...)
helm upgrade --install hermes-agent ./charts/hermes-agent \
--namespace hermes-agent --create-namespace \
-f charts/hermes-agent/values-anthropic-and-discord.yaml \
--set-string env.ANTHROPIC_API_KEY='sk-ant-...' \
--set-string env.DISCORD_BOT_TOKEN='...' --waitSee charts/hermes-agent/README.md for the full
values table, the "More examples" table (values-*.yaml for every supported
provider plus Discord/Telegram and LiteLLM), and an
ArgoCD example.
Branch model, release process, and local checks (make lint / make docs /
make test) are covered in CONTRIBUTING.md; chart design
principles are in AGENTS.md.
- Every PR and every push to
dev/mainruns validate-chart.yaml:helm lint,helm template, a chart-docs drift check, and a full install + test on an ephemeral kind cluster (realhermes chatround-trip when anNVIDIA_API_KEYsecret is available). - Releases are Changesets-driven, not tag-push-driven. A user-visible chart
change adds a
patch,minor, ormajorentry under.changeset/. When you are ready to release, manually run propose-release.yaml to combine pending entries into one reviewable release PR, write itsCHANGELOG.mdnotes, and synchronizes the private release manifest withChart.yaml, Artifact Hub metadata, chart docs, and versioned examples. Review and merge that PR; then release-chart.yaml tagsvX.Y.Z, writes the GitHub Release, and publishes the chart tooci://ghcr.io/<owner>/hermes-agent-helm/hermes-agent.
So: lint + test gate every change; the release itself is just a normal reviewed PR (the version bump) β the pending Changesets decide its SemVer, merging is what ships. See CONTRIBUTING.md for the full release playbook.
This chart deploys and manages one agent well; teams via an ArgoCD ApplicationSet are how you scale today, and a CRD-based operator is a long-term, not-started candidate. See docs/reference/roadmap.md.
Issues, PRs, and ideas are all welcome β start with CONTRIBUTING.md (branch model, local checks, release flow). Every merged contribution is credited in the changelog and release notes.
Thanks to everyone who has contributed to and starred this project β
Banner Β© Nous Research (MIT).