@necrevistonnezr said in Runcloud.io vs ServerPilot.io vs Cloudron vs Sandstorm: I don't remember this link being there (that you removed) when this topic was opened a few months ago you can see the edit history of a posting. It was only added on the 19th of november at 23:40. Honestly also @KathleenMcArthur feels a bit like a spam bot posting backlinks to earn some referrals.

Hi, I'm very sad to hear that Cloudron core code has become proprietary software. Like @ryangorley, I've always been promoting Cloudron as a great well-supported open source self-hosting option. I too want you guys to succeed but I fail to see a valid reason to turn Cloudron into proprietary software if it is still being developed in the open. My thoughts on the reasons you gave: The technical reason is that the code base has subscription, appstore and sign up logic. It's unclear what the license should be if it requires the cloudron.io service to work. I-am-not-a-lawyer but I'm pretty sure that you can still be under an open source license. I mean, the situation is not "ideal" as an user can't easily self-host without relying on the cloudron.io external service, but anyone is free to create a fork and reimplement these functions. Also, I don't know if it's the case anymore but we used to be able to install cloudron Docker packages built manually without cloudron.io. So in a way, Cloudron was self-hostable, just without the user friendly App Store. The non-technical reason is that we were spending too much time explaining why we call ourselves opensource and charge for it. It should be pretty simple for customers to understand, they are paying for a service of maintenance and support (indirectly funding the development of the core product). That is no different than let's say a WordPress maintenance service to have plugins/themes kept up-to-date by a company. Worse case, if you really want to give proprietary software to some customers, why not dual-license? Contributions would be made under both AGPL and your proprietary license. This way, it's still open source and potential contributors would be a lot more inclined to become involved. Anyway, I wish that a compromise can be found where Cloudron still remain a great open source self-hosting option!

https://git.cloudron.io/cloudron/box/issues/654

Interesting, this was simply missed I guess. I have added it now and it will be part of the next release. It will look like this then: [image: 1572952466019-screenshot_2019-11-05-cloudron.png]

Hi and welcome on board! The warning you are seeing is, because it is never a good idea to store the backups at the very same disk/server. Ideally those should be stored in some other datacenter or such. For Cloudron the backups also are per-app to allow per-app restore if an update failed or something else is broken. This makes the backup service for the whole server not very useful, nevertheless it is still some safety net of course. Ideally you should choose between one of the storage providers we currently support https://cloudron.io/documentation/backups/#storage-providers For your case DigitalOcean Spaces might be a good option.

You guy are are amazing and fast, thank you!

yes, that tag-input component has several other small bugs and we should really replace it. If anyone knows a good angular1 based component to replace it, ideas welcome

This comment was very informative - https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/1833013/comments/6 . I didn't realize you have to pass so many options to make it not ask questions.

Also, note that changing the nameserver sometimes takes a bit of time. So, you might have to wait a bit between step 2 and step 3.

I was unaware of the incremental feature in rsync. That will work for me, thank you!

Looks like it was in fact getting sent to the catchall. Thanks everyone for your input.

@necrevistonnezr Yeah you can click the search icon in the UI, then in the select box, change to "Entire Message" and it searches both the headers, the body, and in some cases attachments as well (in the case of txt attachments I think? I've never had a need for it and no real way to test it) [image: 1566913782769-925fe9c5-e509-4f0a-af70-682114ec4f24-image.png]

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.

Done, added notification for the next release.

@njha The Cloudron version of minio is intended for hosting static file assets and not as a backup destination for Cloudron itself. If you want to backup Cloudron to minio, we recommend setting up a separate non-Cloudron server that just runs minio that proxies to b2.

@lunarshade Can you give some idea on what you are trying to customize? If these are general UI/UX improvement, we are happy to incorporate them into the main product itself. If you are a hosting provider, we are building out customization features in the hosting provider edition - https://cloudron.io/documentation/hosting-provider/ (write to us at support@cloudron.io for a trial license)

Yes, if that is going to be an option soon then we can mark this as resolved Thanks!

@stoccafisso I have put this in our 4.1 roadmap - https://forum.cloudron.io/topic/1789/what-s-coming-in-4-1 . The feature is already supported in our backend (dataDir field when calling the configure route) but the UI is hidden. We will work on making it public.