Cloudron Forum

@robi nice idea

PaaS platform provider ?
Cloudron is a PaaS, you just self host it

I haven't looked at the link, but isn't there an "other" section ?

@jadudm good comment although more relevant is that it is a node app than the docker-compose is simple (packaging needs a Dockerfile).

Just so other possible packagers are aware, are you planning to package it yourself ?

Well said.
Cloudron is the most stable platform and resource I have come across, and resolutions of any problems are usually swift, thanks to those on the product side and in the forum.

@jdaviescoates I’m using Windsurf and it is certainly good. Occasionally loses the plot and doesn’t always follow instructions correctly but still pretty darn good.

@robi very helpful feedback, thank you

Multiple instances of apps is a strong feature of Cloudron.
I deploy 2 x PaperlessNGX, about 6 x surfers, 2 x EspoCRM, 2 x Ghost etc etc

@girish another consideration about one app for both server and dashboard is that AFAIK the server app runs a single server instance whereas (in theory at least) parse-dashboard can connect to multiple server instances. I have not added that capability but it might be relatively straightforward.

In that scenario it might be little odd for the dashboard to be in a server instance for one server but connections to server#2 etc are in other instances. Messes with my brain anyway .
Keeping them as separate apps would allow a cloudron deployment of say 3 server instances as individual apps and one dashboard instance as a standalone app connecting to the server apps. Not if sure “scalability” is the right word but it’s something like that.

My opinions are not set. Just following how others seem to do it outside of Cloudron.

Apps on git.cloudron.io :

https://git.cloudron.io/timconsidine/cloudron-parse-server

https://git.cloudron.io/timconsidine/cloudron-parse-dashboard

@girish good news on mongodb

Yes, my first instinct was to have them packaged together.
But thinking it through, I thought maintenance and updates would be easier if the app packages followed the source repos which are separate. Otherwise we are merging source repos, which is unknown territory for me at least.

The other consideration is that Parse Dashboard is fairly limited.
It does provide a basic interface, maybe useful for initial configuration of a Class (in Parse terminology) or viewing all Classes in an instance.
But the typical user of Parse Server will be accessing it programmatically as a non-firebase backend for a web app (or in my case a mobile device app). I could predict that such a user would see minimal benefit of Parse Dashboard and wouldn’t want the overhead in the app of something they’re not using.

I can take a look at packaging both repos as one Cloudron app, if you think that would be better after considering the issue of updates from source repos.

@girish

Ah yes, backups !
Sorry, no, I haven’t checked how backups would work with the packaged app.
But it’s using the mongodb addon so hopefully it is compliant.

Extract from CloudronManifest.json :

"addons": {
    "mongodb": {
        "oplog": true
    },
    "sendmail": {},
    "localstorage": {}
},

About the repo visibility :
Oooops, the gitlab is my own dev one.
Sorry, I should have put in git.cloudron.io !!
I have temporarily made the repo public, but I will fix this by creating a repo for Parse Dashboard and Parse Server on git.cloudron.io later today.

I share the feelings of alarm but we do need to keep it in context - it’s IT - it always goes wrong - we are amazed and pleasantly, nay deliriously, happy when it works smoothly, as mostly Cloudron does.

Apart from root cause stuff and understanding why it is smooth for some and (what feels in the moment) near-disaster for others, the interesting point for me is : when is a backup a backup ? When can it be relied on ?

I couldn’t restore to the pre-update backups, needed to go further back, and then manually add lost stuff. In my case it wasn’t nice, but it wasn’t that hard, but maybe I was lucky, judging by other reports.

But that’s probably an unanswerable question.
I wonder if snapshots offer more than backups in this scenario. But I guess that’s outside Cloudron realm.

Maybe biggest takeaway from all this : don’t make big updates of core services auto-update. Give the user notice, and a chance to make a snapshot or some other cautious approach, and leave them to decide when to run it.

@girish I’m on the road so can’t check easily but think it’s mongodb
Will check asap

Will fix the repo so it’s viewable - sorry

Update : after manually doing retry task and restart on all apps with error (sometimes multiple times), and restarting postgres and the relevant redis, I could resolve all except :

• keycloak : a new installation so uninstalled and will re-install later
• onlyoffice : don’t use much so uninstalled and trying new installation

So going to close this
But worrying it happened.

UPDATE : don’t see how to close - can @staff please do so

Seems that :

• some can fixed with a simple Retry Task
• some with Retry Task then Restart app/container
• some stay as not responding despite those steps

Will have to investigate tomorrow

Not very happy that 8.3 rolled itself out when it doesn’t seem stable
And it had to happen when I am in the middle of projects, which means I don’t have time to research fixes.
So, seeking to leverage the ppower of the community )not being lazy of course) is there a standard fix path for issues like Error : - Error setting up postgresql. Status code: 500 message: the database system is in recovery mode ?
I have 10 apps down, some of which are core productivity apps like paperless and gitlab.

I have uploaded my custom packages for Parse Server and Parse Dashboard.

https://gitlab.fo1.uk/timconsidine/cloudron-parse-server

https://gitlab.fo1.uk/timconsidine/cloudron-parse-dashboard

https://git.cloudron.io/timconsidine/cloudron-parse-server

https://git.cloudron.io/timconsidine/cloudron-parse-dashboard

I would describe these as BETA releases.
They work for me, but I cannot claim they have been fully tested.

Dummy credentials are in each app’s config files under /app/data.
Unsurprisingly they should (a) match in each app, and (b) be changed from their defaults !!
Then restart both apps.

Packaged as separate apps, because (a) that’s how the source repos are structured, and (b) Parse Dashboard is optional, only needed if you want some level of UI to the server instance.

A lot of interest has been expressed in having Supabase packaged for Cloudron, and indeed that was my first choice as an alternative to using Firebase.
I started with hosted Supabase, then moved to a self-hosted Supabase instance running via docker-compose, but gave up on packaging Supabase for Cloudron as it is intricate with multiple components.

Parse is, in my view, a no-less-effective alternative to Firebase, but it is much simpler to deply and use.

@umnz important to upvote so thanks.

Also important to remember that packaging can be complex. So takes time. I’ve looked at packaging Supabase a couple of times and it’s definitely in the “non-trivial” category.

For myself, and maybe for lots of others, Parse is as good as supabase for 80-90% of needs, and is easier to package. Maybe will release my package for Parse Server this weekend

I did click on the links but didn’t really understand the USP, although that doesn’t mean it’s not interesting