@qwinter said in Nodebb reported to be buggy. Not having control over cloudron's release pace could be a problem!:
This brings me to the topic: do we get the latest version of everything (within reason)?
If a Software provider releases a public stable release, it is expected to be stable!
But if that is not the case you really can't blame the one deploying it (In this case Cloudron).
If a release is still buggy it should be a release candidate and not be published.
(Not counting in plugins!)
@qwinter said in Nodebb reported to be buggy. Not having control over cloudron's release pace could be a problem!:
Is anyone tracking whether that version is reportedly buggy?
Given the scope of all the apps cloudron has and the limited amount of resources we have, there are lifecycle tests for each app.
https://git.cloudron.io/cloudron/nodebb-app/-/blob/master/test/test.js
These tests can always be improved since the scope of testing can be quite huge.
For example, we can't test each existing plugin for NodeBB, Discourse, Nextcloud yada yada since the room for errors will increase exponentially with each extra plugin.
@qwinter said in Nodebb reported to be buggy. Not having control over cloudron's release pace could be a problem!:
We self-hosters probably cannot afford a devops person (let alone team). If a new version of an app gets published to cloudron, and borks a public production site, there's absolutely nothing we can do other than revert to a backup. This situation makes me uneasy. I want to have peace of mind more than I want to be independent and self-hosting!
If the lifecycle tests is successful we would consider it ready to go.
However, what you are describing could be solved.
Disable automatic updates for apps which you deem production necessary, which are not allowed to break. ever! aka. never change a running system.
You can always clone an app and test the update yourself on the cloned version before upgrading the production one.
But this is one of the points which I don't want to do with cloudron and I am happy not to have to do.
@qwinter said in Nodebb reported to be buggy. Not having control over cloudron's release pace could be a problem!:
Anyone thinking the same? What's your take? How much of your week goes to babysitting things that break with updates when you self host (even with cloudron)? I'm starting to feel this could be an uncomfortably high number.
Little to none when it comes to cloudron.
My latest 30 minutes of 'babysitting' was my private cloudron which I thought crashed. But no, the mainboard of the server simply died and the tech crew in the datacenter switched it out in less in 10 Minutes after my support call and mail.
Here is a screenshot of one my main cloudrons availability report for my company with all internal tools for this year so far.

1 = Up and Running and 0 = Down
And all the downtimes you can see there are from scheduled security reboots.
I could click together a graph for that with the linked trigger which reports a needed reboot, I am lazy now.
I also have graphs of each docker container in cloudron, like cpu/ram/disk i/o, exit codes, network i/o yada YADA.
I am monitoring everything from hardware level components to software level services.
For me, if a Cloudron Server sends out notifications to me that something is not right, then something is really not right.