OpenClaw
-
Is there a way to install Tailscale by chance? I'm seeing the documentation, but seems even
/app/datais set to an RO file system if trying to install it.@JLX89 updated to include the Tailscale CLI + daemon installed in the Docker image
To use it, add to /app/data/.env:
TS_AUTHKEY=tskey-auth-... TS_HOSTNAME=openclaw@creative567145 added the
SEARXNG_URL=as well env -
@JLX89 updated to include the Tailscale CLI + daemon installed in the Docker image
To use it, add to /app/data/.env:
TS_AUTHKEY=tskey-auth-... TS_HOSTNAME=openclaw@creative567145 added the
SEARXNG_URL=as well env@andreasdueren Thank you so much!!
-
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
-
@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.
-
@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.
-
@creative567145 said:
From what I can notice, in every 2-5th update, there are modifications added that are causing breakage.Really? Break how?
I haven't been using it, but know millions of others are.
Odd that it hasn't been solved by now.
@robi In the GitHub repository the breaking changes are listed
https://github.com/openclaw/openclaw/releasesExample (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.24Plus 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 In the GitHub repository the breaking changes are listed
https://github.com/openclaw/openclaw/releasesExample (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.24Plus 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".
@creative567145 thanks for the info, yes that would be the easiest way.
Sounds like they need to manage flavors
-
@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.
@creative567145 @robi What's the preference here? My original CI/CD was set up before the community apps existed so that's why there haven't been any proper package updates. I'm happy to set up the proper pipeline, but I need to know how people want me to set this up. Should I build daily? Weekly?
I'm not actually using openclaw. I had switched to nano claw early on and am now using Hermes agent. So I can't test this before pushing updates.
-
@creative567145 @robi What's the preference here? My original CI/CD was set up before the community apps existed so that's why there haven't been any proper package updates. I'm happy to set up the proper pipeline, but I need to know how people want me to set this up. Should I build daily? Weekly?
I'm not actually using openclaw. I had switched to nano claw early on and am now using Hermes agent. So I can't test this before pushing updates.
@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.
-
@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.
ideally somebody needs to test the updates before pushing them to all instances.
I've not started using any Community Apps yet myself, but I'd suggest for anything important a good pattern might be to keep auto-updates turned off and to test them first in a cloned app before applying the updates to production
-
ideally somebody needs to test the updates before pushing them to all instances.
I've not started using any Community Apps yet myself, but I'd suggest for anything important a good pattern might be to keep auto-updates turned off and to test them first in a cloned app before applying the updates to production
@jdaviescoates maybe. But honestly I’ve been running Ente fully automatically updated with CI/CD for a year? now and never had any issues whatsoever.
-
@jdaviescoates maybe. But honestly I’ve been running Ente fully automatically updated with CI/CD for a year? now and never had any issues whatsoever.
@andreasdueren but this thread is about OpenClaw and it sounds like that often has breaking changes.
-
@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.
@creative567145 @andreasdueren I would tend to agree monthly with a quick check that it's not a bad breakage release.
Otherwise might as well run it in LAMP and have it mange itself.
-
@andreasdueren but this thread is about OpenClaw and it sounds like that often has breaking changes.
this thread is about OpenClaw
Obviously, but it sounded your concerns were about community apps not OpenClaw in specific. I'll set up monthly updates then
-
this thread is about OpenClaw
Obviously, but it sounded your concerns were about community apps not OpenClaw in specific. I'll set up monthly updates then
@andreasdueren fair enough.
I guess it was really for any app (community or otherwise) where people are worried that auto updates might break things. e.g. some people have auto-updates for Nextcloud turned off as plugins often break things.
Saying that, it's so easy to roll back to backups on Cloudron it's a relatively low risk for most people I'd suggest.
-
CI/CD fires now on the 1st of each month.
-
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/` -
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/`@creative567145 Thanks for the detailed report. Upstream made the workspace templates (
HEARTBEAT.mdetc.) a hard runtime requirement, and the Cloudron package's Dockerfile wasn't copyingsrc/agents/templatesinto/app/code.This is fixed in package version
2.0.4: the build now copies the fullsrc/agents/templatesdirectory into the image, and I've added a build-time assertion that fails the image build ifHEARTBEAT.mdis ever missing again. So this particular breakage can't silently ship a second time.You should be able to upgrade your installation and it should work as is.
-
@andreasdueren Thank you for the fast response and fix.
We performed the update.
And now OpenClaw is stuck in process: StartingHere 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.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login