OpenClaw

[JLX89]

@andreasdueren Thank you so much!!

[creative567145]

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]

Self updates would be nice in such a fast moving dynamic app.

[creative567145]

@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]

@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.

[creative567145]

@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]

@creative567145 thanks for the info, yes that would be the easiest way.

Sounds like they need to manage flavors

[andreasdueren]

@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]

@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.

[jdaviescoates]

@creative567145 said:

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