Take no offense, I'm not assuming anything lol just want to hear more about your own experience. Thanks.
It works for me. Their support a couple of years ago wasn't as good, but has improved a bunch since then.
Hey thanks for the review folk 🙂
That's what I thought, since the complaints I'd found were relatively old, and I also thought a folk in the Cloudron community wouldn't mislead us, wouldn't it?
Truly, prices are hard to beat.
As for the license itself, the platform code is not opensource or free software if that is what you are wondering. We contribute to opensource in other ways both financially and with development - https://www.cloudron.io/opensource.html . The license text is an adaptation of various other licenses like GitLab EE, Sourcegraph EE license etc.
Gemini aims for and achieves elegance. It is like a more modern version of gopher.
It is great for people fed up with the tracking and bloat on many modern websites. Many users rely on somebody else to deploy and run a gemini server in order to have some place to host their content. It would be wonderful if Cloudron could help people self-host by offering a server to deploy.
I am going to create a request for Molly Brown here:
@mastadamus I don't know much about this plugin/addon for nginx, but it kinda seems to be only part of Nginx Plus, which we are not using in Cloudron. Also if that matters here, the main nginx is only used as a reverse proxy.
As for the motivation, we use unbound because the mail server needs to do DNSBL queries. Most of the DNSBL servers like Zen SpamHaus will not respond if the queries originate from Google/Cloudflare DNS. This forces us to run our own DNS server.
The other motivation was also to log DNS lookups by apps to identify any malicious use but we never got around to this (this was initially designed for a setup where we expected all app packages to be done by 3rd party).
Finally, the unbound server should not be used much at all because most of the apps should not be querying anything external.
@rossmaclean yes, once we publish the app in our app library we will move that repo. Usually the original packager will retain push rights if wanted though.
I guess if you want us to review a change, you could start an issue in that repo and tag us (@girish / @nebulon / ...) there. There is no formal process in place yet, so whatever works for you and notifies us 🙂
The takeaway for the moment is, that groups are not exposed via LDAP, however some bits on Cloudron side have changed, regarding groups and roles, so maybe we can revisit this if we understand the use-case better.
"Cockpit is included in Ubuntu 17.04 and later, and available as an official backport for 16.04 LTS and later. Backports are enabled by default, but if you customized apt sources you might need to enable them manually."
Otherwise I feel we still have to discuss the notification system then to also work for your use-case. Maybe you can start a separate thread describing what your ideal solution would look like a bit and we can see how this makes sense for us to implement this way or not.
@d19dotca I'm looking forward to that too, but mail is not so critical for me.
I spent ~10 hours earlier this week getting Papercups up and running on a separate VPS. If it were on Cloudron, it would have been 5 mins plus config. So - for me at least - mail is a bonus, with core case for Cloudron proved day in day out.
@cyberfreakde no, the server and apps won't stop and will continue to run forever. Additionally, no features are disabled as such. The main change is that you cannot install more apps and existing apps won't get updates. I put these notes in https://docs.cloudron.io/billing/#canceling-subscription . Also, support is limited if you let the subscription lapse too much (hard to support if software is outdated by many releases).