Hermes Agent

[andreasdueren]

@creative567145

Thanks for the detailed investigation. This was a real package-level status detection issue.

I pushed a fix in package version 0.4.30:

• recognize python -m gateway.run
• recognize hermes.real
• recognize hermes-agent.real
• add regression coverage for those launcher forms

The new app is published and you can update to the newest version. If Cloudron still marks the app as “Not responding” after 0.4.30, please share the Cloudron startup logs and the /health response, because that would likely be a separate health-check/dashboard issue rather than this gateway status bug.

[creative567145]

@andreasdueren thank you for the fast response.

We run the test on a fresh new Hermes installation and we get the same problem again: Not responding.

Here are the logs if it helps:

Jul 07 23:42:00 => Healthcheck error: Error: connect ECONNREFUSED 172.18.20.151:8000
Jul 07 23:42:10 => Healthcheck error: Error: connect ECONNREFUSED 172.18.20.151:8000
Jul 07 23:42:16 taskworker: Starting task 14154. Logs are at /home/yellowtent/platformdata/logs/41934ee7-1f4b-4258-a829-b9fa53564d9c/apptask.log
Jul 07 23:42:16 taskworker: Running task of type app
Jul 07 23:42:16 apptask: run: startTask installationState: pending_restart runState: running
Jul 07 23:42:16 tasks: updating task 14154 with: {"percent":10,"message":"Starting app services"}
Jul 07 23:42:16 tasks: updating task 14154 with: {"percent":30,"message":"Restarting container"}
Jul 07 23:42:26 tasks: updating task 14154 with: {"percent":70,"message":"Configuring reverse proxy"}
Jul 07 23:42:26 shell: openssl: openssl x509 -noout -subject -issuer
Jul 07 23:42:26 reverseproxy: providerMatches: subject=CN = ai.clienturl.com domain=ai.clienturl.com issuer=C = US, O = Let's Encrypt, CN = YE2 wildcard=false/false prod=true/true issuerMismatch=false wildcardMismatch=false match=true
Jul 07 23:42:26 shell: openssl: openssl x509 -startdate -enddate -subject -noout
Jul 07 23:42:26 openssl: expiryDate: subject=CN = ai.clienturl.com notBefore=Jul  7 18:49:31 2026 GMT notAfter=Oct  5 18:49:30 2026 GMT daysLeft=89.87989753472222
Jul 07 23:42:26 reverseproxy: ensureCertificate: ai.clienturl.com acme cert exists and is up to date
Jul 07 23:42:26 reverseproxy: needsRenewal: false. ARI {"start":"Fri, 04 Sep 2026 21:33:35 GMT","end":"Sun, 06 Sep 2026 16:44:25 GMT","rt":"Sun, 06 Sep 2026 06:22:03 GMT","valid":"Wed, 08 Jul 2026 02:26:18 GMT","url":"https://acme-v02.api.letsencrypt.org/acme/renewal-info","ts":"Tue, 07 Jul 2026 19:48:03 GMT"}
Jul 07 23:42:26 reverseproxy: writeAppLocationNginxConfig: writing config for "ai.clienturl.com" to /home/yellowtent/platformdata/nginx/applications/41934ee7-1f4b-4258-a829-b9fa53564d9c/ai.clienturl.com.conf with options {"sourceDir":"/home/yellowtent/box","vhost":"ai.clienturl.com","hasIPv6":true,"ip":"172.18.20.151","port":8000,"endpoint":"app","redirectTo":null,"certFilePath":"/home/yellowtent/platformdata/nginx/cert/ai.clienturl.com.cert","keyFilePath":"/home/yellowtent/platformdata/nginx/cert/ai.clienturl.com.key","robotsTxtQuoted":null,"cspQuoted":null,"hideHeaders":[],"proxyAuth":{"enabled":false,"id":"41934ee7-1f4b-4258-a829-b9fa53564d9c","location":"/"},"upstreamUri":"","hstsPreload":false}
Jul 07 23:42:26 shell: reverseproxy: /usr/bin/sudo --non-interactive /home/yellowtent/box/src/scripts/restartservice.sh nginx
Jul 07 23:42:26 => Hermes Agent for Cloudron starting...
Jul 07 23:42:26 Ok to proceed? (y) 
Jul 07 23:42:27 tasks: updating task 14154 with: {"percent":100,"message":"Done"}
Jul 07 23:42:27 tasks: setCompleted - 14154: {"result":null,"error":null,"percent":100}
Jul 07 23:42:27 tasks: updating task 14154 with: {"completed":true,"result":null,"error":null,"percent":100}
Jul 07 23:42:27 Exiting with code 0
Jul 07 23:42:27 taskworker: Task took 11.005 seconds
Jul 07 23:42:27 => .env updated
Jul 07 23:42:27 => Generated API_SERVER_KEY for Hermes API authentication
Jul 07 23:42:27 => No Nextcloud/WebDAV sync targets configured
Jul 07 23:42:28 => Installing local Chrome runtime for Hermes browser tools...
Jul 07 23:42:29 ⠙⠹⠸⠼⠴⠦⠧⠇⠏⠋⠙Need to install the following packages:
Jul 07 23:42:29 agent-browser@0.27.0
Jul 07 23:42:30 => Healthcheck error: Error: connect ECONNREFUSED 172.18.20.151:8000
Jul 07 23:42:40 => Healthcheck error: Error: connect ECONNREFUSED 172.18.20.151:8000
Jul 07 23:42:50 => Healthcheck error: Error: connect ECONNREFUSED 172.18.20.151:8000

[andreasdueren]

@creative567145 Thanks, that log was enough to identify it. This is a different issue from the earlier gateway status detection bug.

The fresh install was hanging before supervisor started because start.sh ran:

npx agent-browser install

without forcing non-interactive mode. On a new /app/data volume, npx prompts with “Ok to proceed? (y)”, but Cloudron has no TTY there, so startup never reaches supervisor and port 8000 never binds.

I pushed package version 0.4.32 with the fix:

npm_config_yes=true npx --yes agent-browser install

So fresh installs should no longer block at that prompt. Existing installs where the browser runtime is already seeded were likely unaffected, which is why this showed up on a clean installation.

[enerch]

This post is deleted!

[chrisbol]

great that hermes agent is now available on Cloudron. But I have some issues with dashboard.
With help of my local AI i have drafter this message...

OPEN QUESTION TO THE MAINTAINER (setting the scene)
Is the browser-side dashboard (including the Chat and System pages) an intended
surface for this Cloudron package? Or is the dashboard primarily meant for Kanban

• the /v1 API, with chat/sessions hosted on the local desktop/CLI and via the
  gateway's platform channels? This determines whether the report below is a bug you
  want to fix or an intentional scope decision.

If web pages ARE in scope: the Hermes codebase ships full hosted-web-chat support
and first-class subpath-reverse-proxy support (X-Forwarded-Prefix handling and
/assets rewriting in _serve_index), so the failure below looks like a small,
easy-to-ship nginx routing gap in the package rather than deliberate design. The
proposed one-block fix resolves every affected page at once.

The bug:
I run the Hermes Agent package on Cloudron. The dashboard shell loads fine;
/kanban, the left nav, and the Files page all work. But every dynamically-loaded
page is blank: clicking "Chat" and clicking "System" both give a completely empty
screen, with the browser console showing 403 (Forbidden, net::ERR_ABORTED) on
their lazy-loaded asset chunks:

/assets/ChatPage-*.js
/assets/SystemPage-*.js
/assets/xterm-BrP-ENHg.css  and  /assets/xterm-*.js
/assets/themes-*.js
/assets/useProfileScope-*.js
/assets/chat-activation-*.js
/assets/ModelReloadConfirm-*.js

ROOT CAUSE (confirmed, not speculation)
The package's nginx only routes /kanban/* to the dashboard backend
(127.0.0.1:9119), rewriting the prefix and setting X-Forwarded-Prefix: /kanban.
Hermes's _serve_index then rewrites the statically-referenced asset URLs in the
HTML to /kanban/assets/... -- which is exactly why the shell, the Files page, and
the Kanban page all work.

But pages like Chat and System are loaded at runtime via dynamic import() with
build-time absolute paths (/assets/...). The browser therefore requests their
chunks WITHOUT the /kanban prefix. Those requests land on 'location /' -> the
front landing page's try_files -> fall through to the headless API server (port
8642), which has no SPA assets and returns 403/404. The dashboard backend itself
serves every chunk fine (returns 200), so this is purely a reverse-proxy routing
gap in the package, not a Hermes bug.

Quick repro that isolates it (from a Cloudron terminal):

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/kanban/assets/ChatPage-*.js   # 200
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8000/assets/ChatPage-*.js          # 403/403

PROPOSED FIX (in the package's nginx.conf)
Add a location /assets/ block that proxies to the same dashboard backend with the
same headers as /kanban/, including X-Forwarded-Prefix: /kanban so the CSS route
keeps rewriting url(/fonts/...) references correctly:

location /assets/ {
    proxy_pass http://127.0.0.1:9119;
    proxy_http_version 1.1;
    proxy_set_header Host 127.0.0.1:9119;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Prefix /kanban;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
}

This single block fixes every lazy-loaded page at once (Chat, System, and any
future dynamically-imported route).

Environment: Hermes Agent v0.20.0 (2026.8.3), Cloudron deployment, dashboard bound
to 127.0.0.1:9119, SPA mounted under /kanban.

[andreasdueren]

@chrisbol Thanks for the detailed report, the root asset routing issue was confirmed and fixed in package version 0.4.65. The package now proxies the lazy loaded dashboard assets to the Hermes dashboard backend while keeping them protected by the same authentication as the Kanban dashboard. Chat, System, terminal, theme, and related asset chunks now return successfully. The update is published and available.

[msbt]

@andreasdueren do you have plans or even already tried adding something like https://hermes-workspace.com/ to the package?

[andreasdueren]

@msbt I’ll look into it

[andreasdueren]

@msbt this looks like a community package and probably should not be included on the Hermes package. Adds extra complexity, package churn and attack surface.

[msbt]

@andreasdueren aye, thanks for checking it out!

[alpheus]

@andreasdueren hello Andreas!
I have an issue with setting the HERMES_REDACT_SECRETS for scheduled cron jobs. Scheduled cron does phone number extraction and reports it to telegram, but the phone numbers arrive redacted (+49*****1234). If I create a one-off cron and then execute it via hermes cron ... then the redaction doesn't happen (phone numbers are visible).

I think the issue is that the main gateway process doesn't pick up the value that I wrote in the .env file (false), which results in phone numbers being redacted when they are outputted to telegram.
If you want to go into the issue with much more depth, below is the detailed summary from my agent of all the things we tried and all the findings that might be useful.

This happened on HermesAgent app version 0.4.61, but I would guess that the issue still persists.
Thank you for your time and dedication to the project maintenance!

Agent summary

Short version
python -m gateway.run imports agent.redact before gateway.run loads ~/.hermes/.env, so HERMES_REDACT_SECRETS=false arrives too late for its import-time snapshot.
Fixing that alone won't solve it though: the gateway's final outbound delivery call forces redaction regardless, and scheduled cron output passes through both scheduler and gateway redaction layers.

Root causes identified

• agent/redact.py snapshots HERMES_REDACT_SECRETS at import time (_REDACT_ENABLED = os.getenv(...)), so it must be set before agent.redact is imported.
• The Cloudron supervisor's environment= list for hermes-gateway includes HERMES_HOME etc., but not HERMES_REDACT_SECRETS/HERMES_REDACT_PHONES.
• gateway/run.py imports agent modules (which import agent.redact) near the top, but only calls load_hermes_dotenv() much later (~line 1829) — so the .env loads after the snapshot is taken.
• gateway/run.py::_redact_gateway_user_facing_secrets() calls redact_sensitive_text(text, force=True) — this bypasses _REDACT_ENABLED entirely, so security.redact_secrets: false in config.yaml has no effect on this path.
• The phone regex also misses Serbian local format and international numbers with a space after the country code.
• cron/scheduler.py redacts no_agent stdout/stderr independently, then the gateway applies its own forced pass — so scheduled jobs go through two redaction layers.

What we tried

• We tested: security.redact_secrets: false in config.yaml
• HERMES_REDACT_SECRETS=false in .env
• editing supervisord's environment directly (not durable — file is app-owned and replaced on updates)
• a sitecustomize.py early-patch (confirmed _REDACT_ENABLED=False standalone, but scheduled Telegram delivery still redacted due to force=True)
• disabling phone matching + HERMES_REDACT_PHONES=false (still redacted in the real delivery path)

[andreasdueren]

@alpheus I pushed 0.4.87 which should resolve this

[WiseMetalhead]

Am I right in thinking that Incoming Email in the Cloudron app settings currently doesn't work? Whenever I try to configure the mailbox, I always get these errors in the logs:

Sep 02 17:03:52 2026-09-02 14:03:52,991 ERROR hermes_plugins.email_platform.adapter: [Email] SMTP connection failed: STARTTLS extension not supported by server.

Sep 02 17:03:53 2026-09-02 14:03:53,013 WARNING gateway.run: ✗ email failed to connect

And if I send an email to that address, the agent doesn't respond at all.

Outgoing email works fine, but only if I leave the default settings unchanged after installing the app.

[alpheus]

@andreasdueren thank you for the fix! I will update hermes in the next few days to the latest version and let you know if it fixed it! Thanks for the fast effort and update!

[andreasdueren]

@WiseMetalhead Please update to 0.4.88. It should work now.

[nostrdev]

@andreasdueren we were initially tempted to use cloudron for packaging agents but given the many documented cases of AI breaking out of containers, compounded by the amount of unencrypted internal cloudron comms and ports being available, we backed away

We are now evaluating firecracker on a dedicated machine for agent hosting

Curious what your (and others) position is with regard to the risks of running agents on cloudron containers

[timconsidine]

@nostrdev E2B ? Kata ? Something else ?
(Probably a slippery slope needing its own discuss or off-topic thread, based on your thought-provoking question touching many surfaces).

[nostrdev]

slippery and off-topic indeed - put some iterations into it and made a new topic here. it's a subject that many, if not most, of us are interested in, has probably been well discussed before.

https://forum.cloudron.io/topic/15921/running-ai-agents-on-cloudron-infiltrating-other-containers-and-admin-services