Hermes Agent
The Hermes Agent is an AI agent gateway and browser dashboard from Nous Research, backed by persistent workspace storage. Edka installs it from the agent catalog as a Helm chart and runs it in your own Kubernetes cluster, in your own cloud account.
It is one of three managed agent runtimes in Edka, alongside the Codex Agent and OpenClaw. Hermes is the profile-capable one: a single runtime pod can host several named agent identities, each with its own instructions, memory, and webhook route.
Hermes Agent is available on every plan, including Free.
Requirements
Section titled “Requirements”- A cluster you have write access to. Deploying an agent, editing it, and creating profiles all require it.
- For dashboard and webhook access from outside the cluster, a hostname configured under the cluster’s Domains. The Hermes dashboard can manage sessions and secrets, so expose it behind a private boundary such as Tailscale or Cloudflare Zero Trust rather than on the public internet.
- For state backups, an S3 compatible object storage integration. See Object Storage.
- For tracing, a Langfuse instance installed in the same cluster.
Deploy the Hermes Agent
Section titled “Deploy the Hermes Agent”- Open a cluster, then go to Workloads → Agents.
- Select Deploy Agent and choose Hermes Agent.
- Under General, leave Bootstrap unset for a plain runtime, or set it to Profile distribution to bootstrap from a published profile such as the Conductor.
- Complete the Configuration tab, including webhook and dashboard access if you need them.
- Submit and watch the agent card for progress.
Edka installs any required add-ons, renders the Kubernetes resources from the catalog definition, and streams progress back to the UI. The agent card then shows runtime health, version, namespace, CPU and memory usage, profile count, and the latest state backup.
Chart and image updates are tracked by the catalog, so the agent can be updated in place from its card rather than reinstalled.
Profiles
Section titled “Profiles”Profiles are named agent workspaces inside one runtime pod. They share the parent agent’s Kubernetes resources and persistent volume, and each profile carries its own instructions, memory, and optional webhook route.
Use profiles when you want several agent identities on one runtime. Deploy a second agent instead when you need dedicated resources or stronger isolation.
Open the agent and use Add Profile. Submitting from there creates a blank profile. Expand Advanced options to pick a bootstrap mode instead:
| Mode | Behavior |
|---|---|
| Blank profile | An empty profile that inherits the parent runtime setup. This is the default. |
| From backup | Restores profile state from a state backup. Offered once a backup exists. |
Profile names use lowercase letters, digits, and dashes, up to 30 characters.
The name default is reserved for the runtime’s root profile. Each profile’s
gateway can be started, stopped, and restarted from the Profiles tab.
Profile distributions
Section titled “Profile distributions”A profile distribution packages a profile’s SOUL, skills, and configuration in a Git repository. Distributions are not installed as in-pod profiles, because that content would be untrusted inside the parent agent’s secret-bearing pod. Install one as its own agent deployment instead.
Set Bootstrap to Profile distribution at deploy time, then pick a profile published by Edka, such as the Conductor, or Custom repository with your own source, an optional branch or tag to pin, and an optional subpath for repositories carrying several profiles.
Edka installs the distribution once, on first boot, as a named profile taking its name from the distribution manifest. Chat platforms configured on the agent connect to that bootstrapped profile, while the default profile keeps the API server and dashboard. To update it later, select Update profile distribution on the profile’s row: distribution files are replaced, your config edits and profile data are kept.
The Conductor
Section titled “The Conductor”The Conductor is a profile distribution published by Edka that turns a Hermes agent into an orchestrator for coding environments. You ask it from chat to implement a change or review a pull request, and it drives environments on a separate environment-capable agent, normally the Codex Agent.
So the two are not alternatives. Hermes is the runtime that hosts the conductor profile, Codex provides the environments it works in, and the Conductor tab on a Hermes agent is where you wire them together.
Webhooks
Section titled “Webhooks”With webhooks enabled and a webhook hostname configured, a profile exposes a public route at:
https://<webhook-hostname>/profiles/<profile-name>/webhooks/<route-name>The default profile uses the parent prefix:
https://<webhook-hostname>/webhooks/<route-name>Edka can reveal a profile’s webhook signing secret after step-up verification. The secret is read live from the agent pod and Edka does not store it. You can also send a signed test payload from Edka to check public delivery end to end.
State backups
Section titled “State backups”State backups export profile state for recovery and for cloning a profile. Enable them in the agent’s Backup configuration tab by selecting an S3 compatible object storage integration and a schedule.
Backups cover memories, sessions, skills, SOUL, and config. Credentials and live databases are deliberately excluded. If the cluster backup age key is set under Cluster Settings → Backup, credentials are written separately as an encrypted sidecar in your object storage. During a restore you paste the age private key only if you want those credentials back; it is used once and not stored.
The Backups tab runs scheduled backups from an in-cluster CronJob, takes manual Back Up Now runs, and lists stored backups for the agent. Restores happen through Add Profile → Advanced options → From backup, and the picker can include backups from other agents in the organization, filtered by your access to each backup’s source cluster.
Langfuse tracing
Section titled “Langfuse tracing”Hermes can send traces to a Langfuse instance installed in the same cluster. Enable Langfuse tracing in the Hermes configuration, select the instance, then provide the project public and secret keys generated inside Langfuse.
Edka fills in the in-cluster Langfuse base URL from the selected app, so the Hermes pod reaches Langfuse over the cluster service rather than a public route.
Hermes Workspace
Section titled “Hermes Workspace”Hermes Workspace is a separate catalog app: a web workspace for the Hermes Agent with chat, sessions, memory, skills, files, and terminal access. Deploy it from the app catalog when you want that interface alongside the agent’s own dashboard. It is also available on every plan.
Access and safety
Section titled “Access and safety”- Reading agents requires cluster read access. Deploying, editing, creating profiles, triggering backups, and testing webhooks require write access.
- Agents get no Kubernetes API access by default. Scoped RBAC and network policy are granted per agent from Settings → Security. Granting cluster-wide custom rules requires step-up verification. See Agent Kubernetes Access and Network Policy.
- Revealing a webhook signing secret requires step-up verification.
- Archived clusters block mutating agent actions.
- State backups live in the object storage integration you select, in your own account.
- The dashboard can manage sessions and secrets. Expose it only behind a trusted private boundary.