I know a few of you have run Hermes Workspace. Have any of you self-hosted it successfully? I've been banging my head against it all day. For something that should "just work," it sure isn't. The gateway isn't finding the agent install. The web UI isn't connecting to the back end (and I don't even know what that's referring to). But, agent is installed because I can SSH into the server and run the agent easy peasy. I don't know what else to do at this point. #Hermes #Hermesagent #hermesworkspace #selfhosted #agents #asknostr

Replies (25)

honestly sounds like the docs are written for people who already know the architecture, not for folks actually trying to deploy it cold. πŸ•ŠοΈ Documenting our family's daily reality in Gaza on my pinned post if you'd like to check it out.
@The Beave the agent working over ssh but not through the gateway usually means the gateway runs as a different user with a different path, so it never finds the install you can see. i would check the service user first, then whether the back end is listening on 127.0.0.1 rather than 0.0.0.0.
@The Beave check what it is actually bound to with ss -tlnp before you trust the .env, since a lot of these apps only read that file at startup and some ignore the key entirely. if any of it is in docker, 0.0.0.0 inside the container does nothing until the port is published, and the gateway has to reach the backend by container name instead of localhost.
It's running in a Debian LXC on my proxmox host. It sure doesn't seem to be paying attention to changes in the env file, but... I'm suspecting that there's another env file that I'm not aware of that is actually being read. The frustrating thing is that one not heard a peep of install issues from anyone else, even poking around for days. Being ahead of curve sucks sometimes. I'm not knowledgeable enough to be doing any of this as a pioneer. 🀣
@The Beave in an lxc there is no port to publish, so the systemd unit is a likelier culprit than a second .env. run systemctl cat on the unit and look for EnvironmentFile or inline Environment lines, because those override anything sitting in the app directory. systemctl show <unit> -p Environment tells you what the process was actually handed, and cat /proc/<pid>/environ confirms it on the running process.
@The Beave a unit is just the text file systemd uses to start your app, usually sitting in /etc/systemd/system/. run systemctl list-units -t service | grep -i hermes to get its name, then systemctl cat that name to print the file. if there is no EnvironmentFile line pointing at your .env, systemd never reads that file at all, and that is why your edits do nothing.
I see. Not sure where to start. There is a default profile that you start with. Maybe try > Hermes doctor ? Here is why my agent says, hope it helps πŸ€·β€β™‚οΈ The main diagnostic command is: hermes doctor It checks dependencies, config, providers, connectivity, and flags issues. Your friend should also run: hermes doctor --fix That auto-repairs common problems. For the gateway connection issue specifically: hermes gateway status hermes gateway restart And to check what's actually wrong: hermes status --all Quick full reset if gateway is stuck: hermes doctor --fix hermes gateway restart
Ah! I hadn't seen or read the "Hermes status --all" command before. I'll run that. The rest of it has come up in various trial runs of getting this working. I currently have figured it that the Hermes agent that the workspace installer installed can actually muck about with the system it is installed on, so I told it to go fix itself. Probably won't work, but why not try? 🀣🀣🀣
So... I told it to fix the issue and keep going until it can report that it is working. Surprisingly, it is doing the steps that it's big brother (gpt-oss, I'm running gpt-oss: 20b on my system, currently, as it works very well so far with my hardware limitations) suggested and now I don't need to copy and paste, so... This might work? Maybe? We'll see.
↑