@andreasdueren Hi Andreas I hope you're doing well mate, it seems like since the last Cloudron update (well, apparently) we have a new connection problem to the web ui via /kanban but also cannot connect from my desktop pointing that
"Nov 03 12:54:39 2026/11/03 17:54:39 [error] 311#311: *343 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: , request: "POST /kanban/api/auth/ws-ticket HTTP/1.1", upstream: "127.0.0.1/api/auth/ws-ticket", host: "hermes-agent.xxxx.xxx"
Here's the quote from my desktop Hermes which is the best to explain what it seems to go on
:
"Your Hermes dashboard backend is unreachable from nginx. The request fails before Hermes can authenticate itโnot because your login or API key was rejected.
I checked your public instance:
Endpoint Result
/health 200 OK โ reports Hermes API health
/kanban/ 502 Bad Gateway
/kanban/api/auth/ws-ticket 502 Bad Gateway on a GET probe
This narrows the problem to the dashboard/proxy path rather than the whole app being offline.
One suspicious detail: your log shows the upstream as 127.0.0.1/api/auth/ws-ticket, without a port. The packageโs current configuration targets 127.0.0.1:9119 for dashboard requests. We need to check your installed configuration before deciding whether the dashboard crashed or nginx is pointing to the wrong destination."
After some recommended verification the following is what it confirms, now I thought I'd report this here before going any further with what Hermes would suggest:
"Nothing is listening on port 9119, despite Supervisor reporting hermes-dashboard as RUNNING. That confirms the dashboard isnโt serving requests; your nginx configuration does specify the expected port.
I checked the packageโs service wrapper and found why this can happen: it deliberately stays alive without launching the dashboard when either:
-
No complete OAuth/OIDC login provider is configured, or
-
The app is running in public/restricted mode.
So RUNNING can mean only the wrapper is runningโnot the dashboard itself. We need to distinguish those cases from a stuck startup.
That said, Hermes container is still reachable and work correctly or so, because when I connect to the terminal it detects the problem and suggest I run hermes pm repair however it cannot work because of Cloudron read only files configuration so here the output:
Ran hermes pm repair; it failed with exit code 1.
Blocked by permissions on:
/app/code/hermes-agent/hermes_cli/tui_dist
That directory is root-owned with mode 700; Hermes runs as cloudron and cannot read it. hermes pm status confirms the dependency sync failed.
The Cloudron app package needs to make this directory and its contents readable/traversable by cloudron, then rerun hermes pm repair. No permissions were changed.
Et voilร ! Hope that helps to look where it seems to fail.