Just stumbled on this one, to see it is already in the suggested list.
It has also third party android app and development is still ongoing regularly.

There's a docker for this: https://firefly-iii.readthedocs.io/en/latest/installation/docker.html

Wiki.js 2 is in beta and brings some important changes (like change of database from MongoDB to RDBMS database of your choice), so anybody thinking of packaging might prefer to hold out for the v2 to come out (or package the beta instead).

There's no timeline for beta, so it might still take a while (or not) before v2 final is out.

I have 18 differents domains with 46 apps at present.

As of now, I don'(t extensively use tagging, because the tag selector is a multiselect, which means I have to unselect my previous selection to switch context, which is too much trouble for me to use.
I don't really use domain switchign because, selection with dropdown is a bit awkward to work with once you have a pretty long amount of items. (and it resets once you quit the page)

So I haven't been really happy with the way it works.

Thinking about it, a structure like the App Store, but configurable would probably be a pretty decent way organizing it.
The default homepage could show Favorite Apps (instead of "Popular"), Tags instead of "Categories" and with a "Search" and "All" filter, we could get all sorted. (pun intended^^)

What would also help would be to have the app meta fields (tags, label and maybe icon) show up before you click install/clone.
Also, when an app in installed/cloned, it is viewable on every user dashboard, regardless of groups. The access settings can only be done afterwards. So there's a, arguably small privacy issue here. Access should ideally be configurable before app is installed.

With those two changes, everything (permissions and meta) could be setup and correctly categorized when the app is installed.

I have no idea how many apps are typically installed on a cloudron, I can totally understand this structure wouldn't be worth it for users with a limited number of apps.
Though the permissions and meta fields setup at app install/clone time is relevant in any case.

Finally, there would be a case for merging groups and tags, so users relating to a group can access all apps tagged in this group. Maybe it's a bit too rigid and this is probably a wider conversation because it also encompasses users, emails etc.

Also looking forward to try it (I've actually installed it, but I get errors sending emails), mainly because I need push notification for a forum, and I can't get that working on iOS with nodebb. (only works on android)

Even then, I'll have to use an external service for iOS: https://meta.discourse.org/t/pushover-notifcations/119258

Hi Cloudronists!

right now, every notification triggers an email, and there's not way to turn it off.
Which is kinda good, but I don't always need to know. For example my wordpress apps are updated regularly and I don't want to receive the same notification for each app.
On top of that if I have one important notification (app crashed for example), and 50 update notifications, it will be easy to miss it.

I think there's two consideration at hand:

• enabling/disabling email notifications
• more granular notification system (to filter out the trivial from the important)

Do anyone has a similar issue? Is there something that can be done to improve this?

@girish Is there a way to check what data is there and can be deleted? I think I have deleted emails, but never thought the data would stay there.

@ebelinski said in What does it take to run and manage Cloudron in the longterm?:

Hi everyone,

I am a bit of a novice when it comes to devops. I am evaluating Cloudron right now, which I installed as a DigitalOcean droplet. I then installed Nextcloud and Collabora using the instructions. So far, everything has been amazingly smooth. I didn't even have to SSH into my droplet and I haven't run into any difficult setup issues. But I know that all VPSes at some point require maintenance. There will always be updates to apply and issues to fix. So my question is, if I keep using Cloudron for the months and years to come, what am I getting myself into? Is this whole system more or less a turnkey solution that updates itself and won't exhibit any problems, or will real devops skills be required? If I had off the management of a Cloudron VPS to someone else without devops experience, will they have difficulties?

Thank you.

Cloudron is incredibly stable. I have minimal devops skills and I've been running it for 1.5 years.
Most issues I had was because of my choice of a dirty cheap VPS and the support is really good.
If you keep external backups, even reinstalling/moving server is straightforward by following instructions.

The most difficult part is the install, so once it's running, as long as you're not out of resources, you can definitely explain how to use/install apps to someone without devops skills.

@mgn841 No, but it means it should be easier to package it to Cloudron.

@murgero said in Cloudron 3.6 - new plans:

@girish Why not have them use LAMP, which is what this was made for? Leave the current Wordpress as is, and not make another one. No one is stopping them from using common sense and installing Wordpress in the COMPLETELY OPEN LAMP Stack app..

The promise of Cloudron is to have one-click install app. It's a better version of Plesk+Softaculous.

In this regard -and with Wordpress is the most popular app on Cloudron- having a Wordpress unmanaged app is good to have. Cloudron could attract a lot of users from these platforms and make life easier to a lot of webdevs/users.

in terms of Cloudron experience, I think it would be good to only have one "Wordpress" in the appstore, and have then the managed/unmanaged choice coming up at install time. (which would create actually 3 choices, managed LDAP / Managed non-LDAP/ Unmanaged)

As for SFTP support, I'm looking forward to it.

"Code-server is VS Code running on a remote server, accessible through the browser."

https://github.com/codercom/code-server

Try it out

docker run -p 127.0.0.1:8443:8443 -v "${PWD}:/root/project" codercom/code-server code-server --allow-http --no-auth