Hermes Setup & Profiles

Hermes Agent installation, profiles, and configuration reference.

Profiles

Profile Purpose Config Path
default Root profile, fallback /root/.hermes/config.yaml
tai Primary (Tai) /root/.hermes/profiles/tai/config.yaml
rei QA/Auditor /root/.hermes/profiles/rei/config.yaml
nei Quartermaster /root/.hermes/profiles/nei/config.yaml
mai Support/Wildcard /root/.hermes/profiles/mai/config.yaml

Profile Isolation

  • Each profile has its own config.yaml, .env, sessions, skills, cron, and memories
  • Gateway runs on a specific profile — switching default only affects new CLI sessions
  • The default profile is at /root/.hermes/ (not under profiles/)
  • Cannot rename default profile

Key Commands

# Profile management
hermes profile list
hermes profile create <name> --clone-from <source>
hermes profile use <name>

# Config
hermes config set --profile <name> <key> <value>
hermes config edit                     # opens in $EDITOR (protected file)

# Status
hermes doctor
hermes status --all
hermes memory status

# Sessions
hermes sessions list
hermes sessions stats

Services

  • Hermes CLI: Interactive chat
  • Hermes Gateway: Platform adapter (Telegram, Discord, etc.)
  • Hermes WebUI: Browser frontend at tai.asslorde.com:8787

Model Provider Notes

  • DeepSeek is a built-in provider. It works from DEEPSEEK_API_KEY in the profile .env; do not add it as a custom_providers entry.
  • The terminal sanitizer can write literal *** if an API key is passed directly through shell commands. Verify env key values by length/prefix, and write keys via split-string/base64-safe scripts when needed.
  • For local OpenAI-compatible endpoints that should appear as a provider/model hierarchy, use the keyed providers: form, e.g. providers.custom/local with a models: dict. Avoid one custom_providers entry per model unless each model is intentionally a separate provider.
  • Current Rei/default local namespace shape: custom/local → ornith-35b, ornith-9b; custom/lab → ornith-35b-lab.

WebUI

  • Location: /root/hermes-webui/
  • Service: hermes-webui (systemd)
  • Auth: password in /root/hermes-webui/.password
  • Caddy reverse proxy: tai.asslorde.com:8787
  • Full Markdown rendering with MEDIA: support for local files

Backup & Updates

  • Backup cron: Daily ~06:45, keeps 7 backups
  • Auto-updater: Every 3 days — checks pip + git updates, reapplies custom patches, restarts WebUI
  • Scripts: ~/.hermes/scripts/hermes-update-check.sh and hermes-update-apply.sh

Tool Symmetry Principle

Every profile needs its own tooling, even if it points to shared infrastructure.

When implementing a system for Hermes that should work fleet-wide, three things must be provisioned per profile:

Artifact Path Example
Plugin symlink profiles/<name>/plugins/<plugin> → shared package mai/plugins/mnemosyne → hermes_memory_provider
Data directory profiles/<name>/home/.hermes/<service>/ mai/home/.hermes/mnemosyne/ → symlinked to root bank
Script resolution profiles/<name>/scripts/ or root scripts/ fallback Cron jobs that reference a script must resolve it

Checklist when rolling out a new system:

  1. Does every profile have the plugin symlink installed? (ls profiles/*/plugins/<name>)
  2. Does every profile have its data path resolved? (not empty, not orphaned)
  3. Can every profile’s cron jobs find their scripts?

This is not duplication — it is the cost of profile isolation working correctly. The infrastructure underneath can (and should) be shared (symlinks, shared DB banks, script dir fallbacks), but the registration point must exist per profile.

“If we are implementing something for Hermes, it should be assumed for all profiles.”

previous HRUN Runner next REI QA Review