So far as I discovered, Cloudron has the best backup approach, the best upgrade approach, the best forum, and the best documentation. I just started using Cloudron this week. The speed at which Cloudron staff replies to emails and forum posts is mind blowing. And they iterate their product based on feedback at lightening speed.

Welcome! You sound like me (and lots of us!) when I first discovered Cloudron a few years ago

1. It does not work well with Cloudflare which is an important tool for managing DNS and security.
2. It does not have a good community forum. I tried its slack forum, but the experience is not good.
3. Its documentation is okay but not detailed and comprehensive as Cloudron's documentation.

I also tried Yunohost today, but it doesn't even allow saving backups to S3 storage. You can only save backups on the same server as your app. Putting all eggs in the same busket is simply not a smart idea. Also, it does not specify how to upgrade apps. If you cannot safely upgrade apps, your self-hosting business (or hobby) is not sustainable.

So far as I discovered, Cloudron has the best backup approach, the best upgrade approach, the best forum, and the best documentation. I just started using Cloudron this week. The speed at which Cloudron staff replies to emails and forum posts is mind blowing. And they iterate their product based on feedback at lightening speed.

The approach around "git push" for deploying apps has been around for 12~ish years (pre Docker in many ways), and that's generally what the PaaS label refers to.

Heroku pioneered base resources (without Docker), and it's not been standardized as Buildpacks https://buildpacks.io/

Cloudron has standardized on Docker and then basically has its own standard set of resources like Buildpacks.

Piku is another open source PaaS worth checking out for developers https://github.com/piku/piku

A benefit to those wanting app deploys on ARM devices like the rPi and clones.

Any "one click apps" on CapRover will be similar to custom apps on Cloudron: totally up to the developer who is maintaining it to keep it up to date and compatible with CapRover and underlying software.

While it can be used by non-developers, I wouldn't recommend CapRover unless you're actively writing and maintaining custom apps.

Piku is another open source PaaS worth checking out for developers https://github.com/piku/piku

So we need a deployment guide, perhaps specific to Github, that takes it a few steps further than the mere setup of the automation that makes it feel done.

The guide on tests and automation is another beast I think, needing a separate resource covering deployments and perhaps another for UIs as that's a whole other layer of QA after deployment.

Maintainability is yet another guide which gets specific to the project, yet is easier if the above two are already addressed sufficiently.

So that's at least 3 separate resources to share so far.

Here's what I found so far:

1. Deployment Guide
2. Tests and Automation
3. Deployment maintainability could best be approached from your viewpoint which would reflect the needs of Cloudron, and hence suggest you write a few thoughts there and publish it so you can stop repeating yourself

There is also a lack of understanding of how deployments has to be done in a maintainable way.

Have you come across a good guide that one could share more easily with the project maintainers?

Many are asking for feedback and not getting the right kind, and they also don't know any better to go looking on their own.

Sounds like the parallel need is attracting more "ultra technical" wizards to assist, or somehow incentivising the app authors themselves to adopt the maintenance as part of their release testing. Tell us what you need - you have a community here for a reason, and there are many that want to help in whatever way they can.

There is a general neglect of deployment and upgrades in the market which is far beyond cloudron. It's probably not apparent here (in the forum), but we regularly report bugs upstream where basic things like login doesn't work after a release.

Part of the issue is that in most projects the upstream deployment strategies are "automated" and nobody is really looking into what it built. There are no tests, I am yet to encounter a project which has proper UI and deployment tests. This is mostly why we are having to do this I remember trying to upstream tests in our early days but the issue was that the tests are tied to Cloudron.

There is also a lack of understanding of how deployments has to be done in a maintainable way. Many projects have plugins/extensions and I am yet to understand how people update things properly when they use plugins. The recent n8n/immich etc even start writing in code directories (probably bugs, but we have to investigate each thing and report upstream).

Just for reference, this is the update queue:

looking forward to Mailtrain 2 eventually hitting the app store one day!

Sounds like the parallel need is attracting more "ultra technical" wizards to assist, or somehow incentivising the app authors themselves to adopt the maintenance as part of their release testing. Tell us what you need - you have a community here for a reason, and there are many that want to help in whatever way they can.

Each of the above app updates above breaks in some way (in fact, some of those updates are already weeks/months due). It's because all this is just super time consuming/exhausting and ultra technical. Most importantly, it's not at all fun and thus practically speaking is not solvable by buying someone a beer/coffee In practically all cases, the issues are not Cloudron related but will affect any packaging system (compose, source installations etc).

I found some cool software for Mac recently called Shottr. One-man development, freeware, but with a link to BuyMeACoffee to allow for extra lubrication of the developer each time there's a nice update with new features & fixes.

Perhaps not likely to fund the sort of development needs of enterprise apps, but money does help in scaling teams and contributions, and currently I still don't see a way to help with funding over and above the basic Cloudron subscriptions. Enterprises will pay for apps and features, but no-one can do that gratuitously without having a way to do that, and an invoice to match that says what a payment was for.

Perhaps there's a way to do that with NodeBB: https://github.com/psychobunny/nodebb-plugin-paypal-subscriptions

Or you need to tap into the contribution features of GitHub, which seems to be better understood by developers, communities and contributors alike. Material for MKDocs sees to have created a sustainable and growing system for this. Perhaps some ideas here:

• https://twitter.com/squidfunk/status/1571890749108617217
• https://squidfunk.github.io/mkdocs-material/insiders/
• https://arxiv.org/abs/2202.05751

Maintenance is underrated

Only by those that don't have to do it. e.g. its open source, so somebody else must be doing it

Cloudron's App Store development looks like it's gone stale, and I guess the community isn't big enough in comparison to pick up the slack.

Maintenance is underrated

Support is not great - anyone can package anything, but caprover doesn't support anything. It's not as vibrant a community as Cloudron IMHO.

I like concept of Caprover and use a few apps from there, but I'm likely to shut my instance down.

• https://caprover.com/
• https://captain.server.demo.caprover.com/#/apps/oneclick/

+1 for open-source ultimately attracting more development.

Cloudron's App Store development looks like it's gone stale, and I guess the community isn't big enough in comparison to pick up the slack.

What do we do?