Cloudron Forum

@andreasdueren Thank you.
Now it's marked as: Not responding.

Here are the error logs, hope they are useful:

Jul 19 22:11:45 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 22:11:45 Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen.
Jul 19 22:11:48 ◇  Doctor warnings ────────────────────────────────────────────────────╮
Jul 19 22:11:48 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:11:48 20:11:48 [state-migrations] Legacy state migration warnings:
Jul 19 22:11:48 │
Jul 19 22:11:48 │                                                                      │
Jul 19 22:11:48 │                                                                      │
Jul 19 22:11:48 │    /app/data/.openclaw/workspace because SQLite rows already exist;  │
Jul 19 22:11:48 │    left legacy source in place                                       │
Jul 19 22:11:48 │  - Skipped Memory Core short-term recall import for                  │
Jul 19 22:11:48 ├──────────────────────────────────────────────────────────────────────╯
Jul 19 22:11:48 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:11:48 Run "openclaw doctor --fix" against the mounted state/config, then restart the container.
Jul 19 22:11:48 [openclaw] Could not start the CLI.
Jul 19 22:11:48 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 22:11:48 [openclaw] Help: openclaw --help
Jul 19 22:11:48 [openclaw] Reason: OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready.
Jul 19 22:11:48 [openclaw] Try: openclaw doctor
Jul 19 22:11:57 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:12:07 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:12:17 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:12:24 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:12:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:12:40 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 22:12:40 ==> Loading environment from /app/data/.env
Jul 19 22:12:42 ==> Starting OpenClaw gateway on port 8000
Jul 19 22:12:44 2026-07-19T20:12:44Z 
Jul 19 22:12:44 2026-07-19T20:12:44Z 
Jul 19 22:12:44 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 22:12:44 WhatsApp automation without the "please accept our new privacy policy".
Jul 19 22:12:48 ◇  Doctor warnings ────────────────────────────────────────────────────╮
Jul 19 22:12:48 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:12:48 20:12:48 [state-migrations] Legacy state migration warnings:
Jul 19 22:12:48 │
Jul 19 22:12:48 │                                                                      │
Jul 19 22:12:48 │                                                                      │
Jul 19 22:12:48 │    /app/data/.openclaw/workspace because SQLite rows already exist;  │
Jul 19 22:12:48 │    left legacy source in place                                       │
Jul 19 22:12:48 │  - Skipped Memory Core short-term recall import for                  │
Jul 19 22:12:48 ├──────────────────────────────────────────────────────────────────────╯
Jul 19 22:12:48 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:12:48 Run "openclaw doctor --fix" against the mounted state/config, then restart the container.
Jul 19 22:12:48 [openclaw] Could not start the CLI.
Jul 19 22:12:48 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 22:12:48 [openclaw] Help: openclaw --help
Jul 19 22:12:48 [openclaw] Reason: OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready.
Jul 19 22:12:48 [openclaw] Try: openclaw doctor
Jul 19 22:12:57 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:13:07 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:13:17 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:13:24 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:13:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:13:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:13:48 ==> Loading environment from /app/data/.env
Jul 19 22:13:50 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 22:13:51 ==> Starting OpenClaw gateway on port 8000
Jul 19 22:13:52 2026-07-19T20:13:52Z 
Jul 19 22:13:52 2026-07-19T20:13:52Z 
Jul 19 22:13:52 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 22:13:52 I'm the assistant your terminal demanded, not the one your sleep schedule requested.
Jul 19 22:13:56 20:13:56 [state-migrations] Legacy state migration warnings:
Jul 19 22:13:56 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:13:56 │
Jul 19 22:13:56 ◇  Doctor warnings ────────────────────────────────────────────────────╮
Jul 19 22:13:56 │                                                                      │
Jul 19 22:13:56 │  - Skipped Memory Core short-term recall import for                  │
Jul 19 22:13:56 │    /app/data/.openclaw/workspace because SQLite rows already exist;  │
Jul 19 22:13:56 │    left legacy source in place                                       │
Jul 19 22:13:56 │                                                                      │
Jul 19 22:13:56 ├──────────────────────────────────────────────────────────────────────╯
Jul 19 22:13:56 [openclaw] Could not start the CLI.
Jul 19 22:13:56 [openclaw] Reason: OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready.
Jul 19 22:13:56 - Skipped Memory Core short-term recall import for /app/data/.openclaw/workspace because SQLite rows already exist; left legacy source in place
Jul 19 22:13:56 Run "openclaw doctor --fix" against the mounted state/config, then restart the container.
Jul 19 22:13:56 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 22:13:56 [openclaw] Try: openclaw doctor
Jul 19 22:13:56 [openclaw] Help: openclaw --help
Jul 19 22:14:07 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:14:17 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:14:27 => Healthcheck error: AbortError: The operation was aborted
Jul 19 22:14:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:14:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:14:53 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 22:14:56 ==> Loading environment from /app/data/.env
Jul 19 22:14:59 ==> Starting OpenClaw gateway on port 8000
Jul 19 22:15:00 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 22:15:00 2026-07-19T20:15:00Z 

@andreasdueren Thank you for the fast response and fix.
We performed the update.
And now OpenClaw is stuck in process: Starting

Here are the error logs, if they are useful:

Jul 19 17:37:59 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 17:37:59 I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.
Jul 19 17:37:59 2026-07-19T15:37:59Z 
Jul 19 17:38:00 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 17:38:00 [openclaw] Could not start the CLI.
Jul 19 17:38:00 [openclaw] Reason: Cannot find module '@openclaw/ai/internal/runtime'
Jul 19 17:38:00 Require stack:
Jul 19 17:38:00 - /app/code/dist/errors-XbAR6hS3.js
Jul 19 17:38:00 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 17:38:00 [openclaw] Try: openclaw doctor
Jul 19 17:38:00 [openclaw] Help: openclaw --help
Jul 19 17:38:13 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:38:23 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:38:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:38:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:38:53 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:39:01 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 17:39:01 ==> Loading environment from /app/data/.env
Jul 19 17:39:03 ==> Starting OpenClaw gateway on port 8000
Jul 19 17:39:05 2026-07-19T15:39:05Z 
Jul 19 17:39:05 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 17:39:05 Your config is valid, your assumptions are not.
Jul 19 17:39:05 2026-07-19T15:39:05Z 
Jul 19 17:39:06 [openclaw] Could not start the CLI.
Jul 19 17:39:06 [openclaw] Reason: Cannot find module '@openclaw/ai/internal/runtime'
Jul 19 17:39:06 Require stack:
Jul 19 17:39:06 - /app/code/dist/errors-XbAR6hS3.js
Jul 19 17:39:06 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 17:39:06 [openclaw] Try: openclaw doctor
Jul 19 17:39:06 [openclaw] Help: openclaw --help
Jul 19 17:39:13 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:39:23 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:39:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:39:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:39:53 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:40:01 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:40:06 ==> Loading environment from /app/data/.env
Jul 19 17:40:08 ==> Starting OpenClaw gateway on port 8000
Jul 19 17:40:10 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 17:40:10 2026-07-19T15:40:10Z 
Jul 19 17:40:10 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 17:40:10 I'm not AI-powered, I'm AI-possessed. Big difference.
Jul 19 17:40:10 2026-07-19T15:40:10Z 
Jul 19 17:40:11 [openclaw] Could not start the CLI.
Jul 19 17:40:11 [openclaw] Reason: Cannot find module '@openclaw/ai/internal/runtime'
Jul 19 17:40:11 Require stack:
Jul 19 17:40:11 - /app/code/dist/errors-XbAR6hS3.js
Jul 19 17:40:11 [openclaw] Debug: set OPENCLAW_DEBUG=1 to include the stack trace.
Jul 19 17:40:11 [openclaw] Try: openclaw doctor
Jul 19 17:40:11 [openclaw] Help: openclaw --help
Jul 19 17:40:23 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:40:33 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:40:43 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:40:53 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:41:03 => Healthcheck error: Error: connect EHOSTUNREACH 172.18.17.9:8000
Jul 19 17:41:11 => Healthcheck error: Error: connect ECONNREFUSED 172.18.17.9:8000
Jul 19 17:41:11 ==> Loading environment from /app/data/.env
Jul 19 17:41:14 ==> Starting OpenClaw gateway on port 8000
Jul 19 17:41:15 2026-07-19T15:41:15Z 
Jul 19 17:41:15 OpenClaw 2026.7.1 (2d2ddc4)
Jul 19 17:41:15 Open source means you can see exactly how I judge your config.

Hi @andreasdueren
One of the latest OpenClaw updates broke it.

When we try to run any command, it gives this error:
Error: Missing workspace template: HEARTBEAT.md (/app/code/src/agents/templates/HEARTBEAT.md). Ensure workspace templates are packaged.

We checked with another AI and it says the temporary solution is to create the file manually inside the container. BUT as we know the Cloudron system is read-only. So this needs to be fixed by the package maintainer.

In order so that it's easier for you to apply the fix, here is some info that might be useful:

Based on deep research into the OpenClaw ecosystem and Cloudron's architecture, this is a known bug caused by a recent upstream update to OpenClaw interacting with how Cloudron packages are built. 

Here is the exact root cause and the solutions to fix it.

### 🔍 The Root Cause
In OpenClaw version **2026.5.26**, the developers introduced a strict startup/interaction check that requires the default workspace template files (specifically `HEARTBEAT.md`) to be present in the runtime image. 

Upstream OpenClaw fixed this by updating their official `Dockerfile` to explicitly copy the `src/agents/templates` directory into the final image (GitHub Issue #87302). However, because you are using a **Cloudron community app**, the package maintainer (Andreas) uses a custom `Dockerfile` specific to Cloudron. That custom `Dockerfile` has not yet been updated to include this new `templates` directory. 

Because Cloudron strictly mounts the application directory (`/app/code/`) as **read-only**, you cannot simply SSH into the container and use `touch` or `mkdir` to create the missing file.

---

#### Option 2: Notify the Package Maintainer (The Permanent Fix)
The package maintainer needs to update the repository at `https://git.due.ren/andreas/openclaw-cloudron`. 

You can open an issue on their Git platform or reply to their release thread on the Cloudron Forum with this exact message:

> **Bug Report:** The OpenClaw >=2026.5.26 update requires workspace templates to be packaged, resulting in crashes looking for `/app/code/src/agents/templates/HEARTBEAT.md` (Upstream Issue #87302). Please update the Cloudron `Dockerfile` to include: 
> `COPY src/agents/templates /app/code/src/agents/templates/` 

@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

For those that need to solve this fast. Here is the PROMPT that can be used (with Claude Opus 4.8)

My Hermes Cloudron container is stuck in a restart loop. The Cloudron
    healthcheck keeps failing with "connect ECONNREFUSED <ip>:8000" and/or
    nginx returns "502 Bad Gateway" on /health, and the container terminates
    and restarts repeatedly. In the boot logs I can see:
    
      => Installing local Chrome runtime for Hermes browser tools...
      ...then it hangs, and earlier logs showed "Ok to proceed? (y)"
    
    Diagnose and permanently fix this. Here is the known root cause and the
    fix that worked before — verify it applies, then execute it:
    
    ROOT CAUSE: start.sh (the container entrypoint, at /app/code/start.sh)
    runs npx agent-browser install to install the local Chrome runtime,
    WITHOUT a non-interactive flag. npx prints an interactive
    "Ok to proceed? (y)" confirmation prompt to install agent-browser. In a
    container there is no TTY to answer it, so npx hangs forever. Because this
    runs in start.sh BEFORE exec supervisord, supervisord never starts, so
    nothing binds port 8000, so the Cloudron healthcheck fails and the
    container restart-loops.
    
    start.sh SKIPS the npx call entirely if a valid chrome binary already
    exists at:  $HERMES_DATA/.agent-browser/browsers/*/chrome
    (HERMES_DATA is /app/data). /app/data is writable and PERSISTS across
    container restarts.
    
    THE FIX (permanent — seed chrome once so start.sh's find succeeds on
    every future boot and never calls the hanging npx again):
    
    1. First check whether you are root or the cloudron user (whoami).
       The install must write to /app/data/.agent-browser as the cloudron
       user so file ownership is correct.
    2. If a hung npx/agent-browser process tree is currently blocking startup,
       identify it (pgrep -af npx / agent-browser) and kill ONLY that subtree.
       Do NOT touch PID 1 or the hermes/supervisor processes.
    3. Run the Chrome install NON-INTERACTIVELY by setting the env var that
       pre-answers the prompt:
         cd /app/code/hermes-agent && \
         HOME=/app/data npm_config_yes=true npx --yes agent-browser install
       (npm_config_yes=true is what bypasses "Ok to proceed? (y)". Run it as
       the cloudron user if you are root: sudo -u cloudron -E env
       HOME=/app/data npm_config_yes=true npx --yes agent-browser install)
    4. Verify a chrome binary now exists:
         find /app/data/.agent-browser/browsers -path '*/chrome' -type f
       and that it is executable.
    5. Ensure the runtime symlink exists:
         ln -sf <that chrome path> /run/agent-browser-chrome
    6. Once chrome is seeded, either restart the container or start supervisord
       so services come up. Watch the /health endpoint until it returns 200
       consistently.
    
    Because /app/data persists, once chrome is seeded there start.sh will skip
    the npx call on every future boot, so the hang cannot recur. Verify the
    gateway binds its port and the healthcheck goes green before you report
    done. Use pgrep/ss to verify processes — do NOT trust `hermes gateway
    status`, which false-reports "not running" in this environment.

And here is the additional info on how we can avoid this if the update is pushed to the package directly (this is the info that I received from Opus, so it needs to be verified):

The seed-chrome approach fixes it durably on that data volume, but if the Cloudron app's data volume is ever wiped/reset, the hang returns on next boot because a fresh /app/data has no chrome.
The truly permanent fix is editing start.sh line 801 to add npm_config_yes=true (and --yes) to the npx agent-browser install call itself — but that file is baked into the container image, not the persistent volume, so it'd need to be changed in the Docker build, not at runtime. The prompt above gives the agent the runtime fix that gets you back online; mention the build-level fix to whoever maintains your Cloudron package if you want it bulletproof against volume resets.

Thank you @andreasdueren
There is currently 1 small bug with the Hermes package which causes it to be market as: Not responding.
While it is working via the Terminal + via the connected Channels.
This basically causes only the Kanban dashboard to not be accessible.

Details in the screenshot attached

The summarized fix from the screenshot - Quote:
"3. Upstream fix - file a bug / submit a PR for gateway/status.py to recognize hermes-agent.real as valud gateway entrypoint basenames. The fix is the one-line change shown above. This is the real root cause of the gateway being invisible to status/management commands in Cloudron deployments.

Hope that was useful

Thank you @robi , much appreciated

Hi @andreasdueren , here is info that could help you to fix the /kanban/ access
screenshot included

Looks like that for the past 4 days Andreas has been busy.

Has anybody been successful with the setup of the Kanban dashboard?

Thank you @andreasdueren Andreas for maintaining Hermes. It's a fascinating software.

We are having some difficulty reaching the /kanban/ dashboard.
If possible please forward the steps that you have made to achieve that outcome.

These are our steps:

1. Open a new web browser (allowed third-party cookies)
2. Go at: https://url.com/kanban/
3. Enter the Cloudron user credentials
4. Redirected at: https://url.com/login?redirect=/kanban/
5. Click again: Log in
6. The web browser window refreshes and nothing happens.

From our research, it looks like the Cloudron login system doesn't allow the redirection successfully.

Thanks @girish
Us, the people that install softwares through Cloudron (Cloudron catalog + Community apps) worry only about 2 things:

• That each app is updated regularly
• Stability & Performance

Who packages and maintains it, doesn't matter much.
If a community maintainer does a good job, great. We would gladly donate to support his/her work.

3 scenarios exist:

1. If the Cloudron team planned on adding couple Apps in the Catalog (which a community maintainer was faster to release on the Community list), and now the App isn't added on the list because somebody was faster.
   Yes, some maintainers do a great job. But not all are up to the gold standard that the Cloudron team has. Most of those people have regular jobs, so they can't dedicate the additional time.

2. If a Community maintainer, stops maintaining an App. And if the Cloudron team picks to add the same App on the Catalog.
   All those hundreds/thousands of people that initially used the Community version, would need an streamlined switch to the Cloudron version. Ideally without a full migration.
   This is where it would be very useful if some day in the future the Cloudron team could create an option in the Community App dashboard, to just click to change the .json URL - so that the App continues to get the next updates from the Cloudron source.

3. A Community maintainer want's to help the community and the Cloudron team by first maintaining an App himself, but with the purpose in the future to delegate the same App to the Cloudron team, so that he can redirect his focus on preparing new Apps.

Hi everybody

It's logical that the following scenario would occur:

1. As more Community apps are added
2. Those that have been marked as very stable
3. Can be processed by the Cloudron team and added in the official Cloudron Catalog

In that scenario, the people that have been using a Community App
(examples: Hermes, Fizzy, Garage S3, Ente, Browserless),
would have 2 choices:

1. Stay on the Community version (if the maintainer decides to keep maintaining it)

2. Switch to get the new updates from the Cloudron source

• This post is about that.
• It would be awesome if the Cloudron team could (some day) release an update which includes the option to switch from the Community source, to the Cloudron source.
• This way, a migration is not needed and the transition goes smooth.

This way, the Cloudron Catalog can grow much faster while with max stability.

Hope that was useful

Bug report for version: 9.2.0

The users permissions is missing when we need to add a new User + then modify existing users permissions

@sebastienserre Thank you. Your input on this error was very useful!

@andreasdueren The only preference is that it's stable and doesn't break on updates.
So in this case, perhaps once per month. This way, if there is a breakage that is dependent on the admin unique setup within OpenClaw, we can solve that for each client.

But if a breakage origin is due to the Cloudron packaging that requires modifications, I don't know what to say...ideally somebody needs to test the updates before pushing them to all instances.

@robi In the GitHub repository the breaking changes are listed
https://github.com/openclaw/openclaw/releases

Example (from our current version 2026.3.23 to the current one 2026.4.11):
openclaw 2026.4.5
openclaw 2026.4.2
openclaw 2026.3.31
openclaw 2026.3.28
openclaw 2026.3.24

Plus regular upgrades to the system functionality, for example how the Videos are being generated.
But this is due to the setup that each client has performed before that.
For example, to be able to generate Videos via Gemini, we had to install custom skills and scripts. So when the update is applied that doesn't have that requirement, either that functionality will break the current process, or we will just need to re-adjust the configuration.

Many people have reported that they are performing the breakage fixes just by connecting Claude Code via SSH and letting it do it's "magic".

@robi that would be nice, but very risky if many use it.

From what I can notice, in every 2-5th update, there are modifications added that are causing breakage.

So perhaps the most stable way is for @andreasdueren to push updates occasionally (example once per 1-3 months), but perform tests on his own OpenClaw and if needed modify the package so that all instances don't break when an update is automatically pushed.

Thank you @andreasdueren

Here are more env variables in case if people wish to use them:
Fast_io_API_Key=
Cloudflare_API_key=

Since version 3.23, there have been a lot of updates to the today's version: 4.9 which includes the Dreaming ability of OpenClaw

@andreasdueren we understand that this is a community package and we are all very grateful for your help. Could we get some info on the intended updates window...example once per 1-3 months or similar. No pressure

@andreasdueren Thank you, much appreciated.
Soon I'll test Zai, Ollama and Mattermost

Here is something possibly useful.
On our OpenClaw installation via DokPloy, we installed SearXNG on the same VPS.
And we were able to configure it to be able to perform the web searches directly via it. So zero API cost towards Brave/Perplexity.

The Docker Compose value that we added was this one:
SEARXNG_URL=

Perhaps somebody else would wish to apply the same configuration. It would be beneficial if it's also added. Thanks again

Thank you @andreasdueren for packaging OpenClaw. Great work!

Due to it's high customizability, it requires more env options to be added.
From my research, here is a list of some of the seem to be currently missing in the first version of the package (hope it's useful)
Note: Some may be redundant, so not all would need to be added.

ZAI_API_KEY=
GROQ_API_KEY=
MISTRAL_API_KEY=
CEREBRAS_API_KEY=
VENICE_API_KEY=
MOONSHOT_API_KEY=
KIMI_API_KEY=
MINIMAX_API_KEY=
AI_GATEWAY_API_KEY=
OPENCODE_API_KEY=
SYNTHETIC_API_KEY=
COPILOT_GITHUB_TOKEN=
XIAOMI_API_KEY=
OPENCLAW_PRIMARY_MODEL=
OLLAMA_API_KEY=
OLLAMA_BASE_URL=
BROWSER_CDP_URL=
BROWSER_DEFAULT_PROFILE=
BROWSER_EVALUATE_ENABLED=
BROWSER_SNAPSHOT_MODE=
BROWSER_REMOTE_TIMEOUT_MS=
BROWSER_REMOTE_HANDSHAKE_TIMEOUT_MS=
HOOKS_ENABLED=
HOOKS_PATH=
WHATSAPP_ENABLED=
MATTERMOST_BOT_TOKEN=
MATTERMOST_URL=
ZALO_BOT_TOKEN=
OPENCLAW_TWITCH_ACCESS_TOKEN=
SLACK_SIGNING_SECRET=
LINE_CHANNEL_SECRET=
LINE_CHANNEL_ACCESS_TOKEN=
DISCORD_CLIENT_ID=
TEAMS_APP_ID=
TEAMS_APP_PASSWORD=

@timconsidine Thank you for your fast response. No worries.

Your documentation is very useful:
https://git.cloudron.io/timconsidine/cloudron-moltbot/-/blob/main/POSTINSTALL.md?ref_type=heads
so perhaps it will help me make OpenClaw work on DokPloy.

I'll test additionally if I can self-host an LLM via Ollama on a Cloudron VPS and connect it to OpenClaw