A real Hermes setup for running agents with less babysitting
Hermes runs on an Mac with a large amount of memory and handles most work for a job-site management web app. The app uses a Next.js front end, a NestJS API, Postgres, Redis, PgBouncer, and Nginx, while Hermes creates tasks, writes code, runs checks, deploys, and keeps documentation current. Human review mostly happens through Telegram. The setup keeps everything under `~/Hermes`, with separate mounted folders for Hermes settings, runtime state, app code, an Obsidian knowledge vault, model auth files, , and patch files.
Hermes runs in Docker alongside SearXNG for web search, Hindsight for searchable memory, Bitwarden Lite for secrets, and hermes-pi for calling several cloud s. Work is split into four profiles: local-admin coordinates Telegram, scheduled jobs, and dispatch; coder does most ; planner researches and files tasks; qa-tester checks the app with Playwright. A custom hook runs every 60 seconds to move ready tasks forward, clean up stalled workers, assign one task to each free profile, and send Telegram updates only when something changes. The coding profile tries several s in order, moving from Z.ai to opencode, Nous, and then local LM Studio if a provider fails or hits a limit.
A skills whitelist keeps each profile from loading every available skill, which makes the instructions shorter and more focused. Several Hermes 0.15.1 Python files are patched to fix practical problems around provider reset timing, skill loading, macOS file locking, SQLite startup crashes, read-only task lists, and false stuck-dispatcher alerts. Memory is split into a short per-profile MEMORY.md for rules that must apply every turn, a larger for long notes, and Hindsight for pulling useful context when needed. Scheduled jobs handle worker cleanup, board maintenance, post-task audits, redeploy checks, model health checks, daily notes, and