// the find
nesquena/hermes-webui
Hermes WebUI: The best way to use Hermes Agent from the web or from your phone!
A self-hosted web UI for the Hermes Agent (Nous Research), giving you a browser-based interface to an AI agent with persistent memory, cron scheduling, and multi-provider support. Built with Python stdlib + vanilla JS, no bundler required. Aimed at developers who want to run their own always-on AI agent and access it from any device.
- Zero build step philosophy is genuine and well-executed — vanilla JS with no bundler, Python stdlib HTTP server, ships as something you can actually read and understand without a toolchain.
- Test coverage is serious: ~7,150 tests across ~700 files, sharded CI on Python 3.11/3.12/3.13, isolated state fixtures so tests don't touch production data. That's unusually thorough for a side-project-scale WebUI.
- Docker story is well-thought-out: pre-built multi-arch images (amd64+arm64), three compose configurations (single/two/three container), honest documentation of the known UID/GID footguns and the tools-run-in-wrong-container limitation.
- Documentation depth is exceptional — RFCs, architecture docs, design docs, troubleshooting flows, onboarding checklists for AI assistants doing installs. The AGENTS.md and onboarding-agent-checklist.md acknowledging AI-assisted workflows is a nice practical touch.
- Hard dependency coupling to hermes-agent internals is the biggest adoption risk: the WebUI directly imports agent Python modules, and the README explicitly warns you must upgrade both together. There's an open issue (#2491) to fix this with a stable API boundary, but until it lands, version skew silently breaks things.
- The comparison table lists 'OpenClaw' as the main competitor but that project doesn't exist under that name publicly — it appears to be a renamed/rebranded reference to OpenHands or a similar tool, which makes the competitive claims hard to verify and looks slightly promotional.
- The routes.py using a giant if/elif dispatch instead of any routing abstraction will become a maintenance problem as the endpoint count grows — ARCHITECTURE.md even calls this out, suggesting it's known technical debt with no clear remediation timeline.
- The two-container Docker setup has a fundamental architectural flaw documented in issue #681: tools triggered from the WebUI run in the WebUI container, not the agent container. This means git, node, and other tools the agent expects may silently be absent, and the fix ('extend the WebUI Dockerfile') pushes complexity onto users.