Best posts made by d19dotca

These apps serve different purposes, so I don't think one can really answer the question without knowing the use-case.

My suggestion is if you only care about webmail, then Rainloop wins. It's quicker, nicer interface (IMO), intuitive, etc. If you however also want to manage a calendar and contacts, then SOGo is likely the better one as Rainloop does mail and contacts only, no calendar or anything like that. And even for contacts, it's differently managed - Rainloop simply stores them, but SOGo "hosts" them so they're also accessible via CardDAV protocols into apps like Contacts on macOS or iOS, Calendar on macOS, etc.

Basically, Rainloop is a webmail client whereas SOGo is what's called "groupware" as it will sync contacts, calendars, tasks, etc. in addition to the mail client role.

If you elaborate on your use-case, then people can probably give you a more accurate answer. Hopefully the above helps in the meantime.

I just realized from comments on a different thread that you now have yearly/annual pricing which is a generous discount per month. I may have missed the announcement of those pricing changes, not sure when that came into effect but I appreciate it.

As a Canadian who ends up paying even more than the listed price due to currency conversion between USD and CAD, I am very thankful for the chance to have that discount by paying for a year in advance. Of course one has to have the means to be able to justify a year up-front, but I can definitely see myself using this for a year or more at least.

As a result, I have changed my plan from monthly to yearly, and I just wanted to say thank you. This brings down my total cost of ownership (TCO) by quite a bit. This takes me down from roughly $40 CDN to $20 CDN, saving me $20 a month, or $240 over the course of the year.

Anyways, ultimately I really just wanted to say thank you, and hopefully let others know about this too in case it helps them. This was a pleasant surprise to see.

Reference: https://cloudron.io/pricing.html

@girish It's also quicker to do from Cloudron at times depending on the VPS host as well. For example I'm hosted currently at OVH and it's not the nicest control panel, not super mobile friendly either and takes me about 6 clicks to get to the reboot option. Cloudron is only about 2 (login > System).

Happy New Year everybody!

Just learned how to deploy a custom app using Bitwarden as the test, but seeing as it should be delivered soon, figured I'd wait for the more official release. So on that note... is there any ETA yet for this app @girish or @nebulon by any chance? If it's going to be a month or two I may start with the custom app, but figured if it'd be just another week or two (or just less than a month), then I'll just wait it out.

Thanks again for all the work you guys do - including everyone else in this thread, as I was able to learn a lot from reviewing everything you all wrote!

As Radicale isn't the most RFC-compliant (they even state that's not their goal), it'd be nice to have a more compliant CardDAV and CalDAV server to use as an alternative to Radicale, SOGo, and Nextcloud.

A good one I have seen recommended often is "sabre/dav". It's also updated more often than Radicale too from what I can tell. I think this would be a great addition for those people who want a more pure CalDAV and CardDAV server.

https://sabre.io/dav/
https://github.com/sabre-io/dav

Hello,

I was just thinking as I have about 30 apps now running on my Cloudron (many are just WordPress, not 30 different apps, lol), that it'd be great to see quickly without having to go into each individual app that those which I want auto backups are enabled and those I want disabled are in fact disabled.

Having a list somewhere would be great. I was thinking it'd be very useful perhaps adding a section on the Backup page that calls out any apps that are currently set to be disabled in auto-backups, so that anyone who's about to go in and do a manual backup for the whole system can see at a glance which apps may not be included or are otherwise disabled for backups.

Would anyone else find this useful? Is it possible something like this can be added to the Backup page in Cloudron?

Just curious how others organize their Cloudron "My Apps" dashboard. Do you use the labels feature much or just descriptive app URLs to keep them organized? Do you bother with tags? And if you use tags, what are some examples you do to solve problems?

I currently have about 20 apps deployed across roughly 12 domains, and am not having too much difficulty yet with organization but I can imagine a year or two down the road (if I'm still using Cloudron which I assume I will be for now) I may run into issues keeping everything straight in the Dashboard, so figured I'd see what problems people have run into and what they've done to solve them when it comes to organizing their apps.

@girish Ah, that's interesting. That isn't documented anywhere that I could find, so that wasn't known. Yes, 3 weeks sounds about right - the "a month" was more figurative as it was close. Unfortunately I can't say for certain now as the backups were failing due to disk space so I had to remove the old backups - this is how I came to learn of this discrepancy between my understanding of how retention time works and what was happening in my system.

Is this something we can customize by any chance? It's a great idea, I like that you're doing it for keeping backups when a package version change happens, because you're right - people usually don't see any smaller issues until a while later. I just wonder if it could be an option to overwrite it all for people who may not have a lot of disk space to spare. May be useful to expose that in the GUI.

On a related side note: One thing I've come to learn through using Cloudron the past 8 months or so is that there is a lot of stuff missing from the documentation that we only find out about later in the forum. I actually am the rare oddball who likes to write up documentation to help others (this is part of my day job), so I'm happy to help contribute these types of updates if you have a list or backlog of items that need to make it into the documentation. If there's anything I can offer on that side of things, I'd love to help so it improves the docs for everyone and hopefully prevents these types of issues from consuming your time.

@nebulon I think the app icons themselves should be left alone. Looking great!

I noticed that when removing a mailbox, it only sets up the mail server to bounce emails to it, but doesn't delete any mail data itself. I'd love to see an option where there's a checkbox on that dialogue pop-up where data can be deleted too. It seems weird to me that no data would be deleted, when generally that's what users I would think want done when they remove a mailbox.

I see the following benefits from implementing this feature:

• Improved efficiency in the workflow for deleting accounts when the admin intends for all the data to be removed too. Saves time.
• Prevents accidental missteps in the CLI by removing the need to SSH to the box in the first place.

Personally I believe that (almost) anytime a user needs to SSH to the server to achieve something on a Cloudron box, this is an opportunity for Cloudron to improve and "sell" a new feature to attract users who aren't interested in doing the system administration. As we've seen from recent posts, Cloudron seems to be attracting a lot of "newbie" sysadmins (which I think is great, that shows how user friendly Cloudron is!), and they may not be as willing to dwelve into the command line to remove data that we'd expect Cloudron to do for us when trashing a mailbox, for example. And heck, even the seasoned sysadmin can easily make mistakes and delete more than they intended (the rm -rf is a powerful command, lol) - we're all human. I think every time a user can achieve something from Cloudron instead of via command line makes it so much safer for the masses of Cloudron users.

Peertube apparently now has an LDAP ability now too. Saw this today: https://framagit.org/framasoft/peertube/official-plugins/-/tree/master/peertube-plugin-auth-ldap

@will This is definitely a discussion and not a support issue. Is something broken in Cloudron? No? Then it’s not a support issue.

I would love to see this project be usable on something like CentOS, but that’s really more because I’m just more experience with CentOS than I am with Ubuntu, not so much for the privacy concerns you raise.

Cloudron simply requires the OS be Ubuntu, it doesn’t require that Ubuntu telemetry be enabled. You’re welcome to disable it all before installing Cloudron and Cloudron will continue to work as its intended to work. You are the admin, you need to maintain your Ubuntu configuration to match your needs. If you require telemetry be disabled, then simply disable it.

If your concern is more the fact that Ubuntu collects telemetry “by default”, well... everyone using Cloudron is likely familiar and technical enough to be comfortable tweaking systems and ensuring that the defaults are actually what they desire and changing anything that isn’t matching their expectations. The same as how one goes through Settings on iOS periodically to make sure everything is as they want it.

If you are THAT concerned about the telemetry data being collected on Ubuntu by default, then simply don’t use the software that requires Ubuntu until it reaches a point where it can support other operating systems too. The team at Cloudron is small, moving to support an entirely different operating system is no small/trivial task, so even if they decided today to move to CentOS it’s probably going to be at least half a year of effort if not much longer than that to be fully matured on CentOS.

Ultimately it’s worthwhile to always consider “risk vs reward” and what data is actually being collected that constitutes a “risk to user privacy”. Personally I don’t care if the company behind Ubuntu knows the resource usage and uptime of my server. That isn’t a “privacy risk” in my opinion because that aren’t actually collecting any user generated data, they’re collecting statistics in that case. However it would be a completely different story if they were also copying over user filesystem data which would contain my emails and website data, client data, passwords, etc.

In summary:

• the suggestion to move to something like CentOS I fully support, I’d love to see that be done.
• in the meantime, you need to make a decision: use Cloudron on an OS you apparently don’t trust, or delay using Cloudron until it supports an OS that you trust.
• if you choose to go with using it still for now on Ubuntu, simply disable the telemetry data collection in Ubuntu to better meet your expectations/use-case.
• this is a discussion not a support case since Cloudron is not broken nor having any issues. Cloudron does not require Ubuntu telemetry be enabled in order to work. Also, it is always up for discussion on how much of an impact the concern you raised impacts people and everyone is going to have a differing opinion on it as to how it will impact them. Just because you may greatly care about one thing doesn’t mean others will care as much as you do nor even care at all.
• gathering telemetry (whether at the OS level or application level) does not automatically equate to “spying”, it all depends on how that data is being used and what benefits may come from it, IMO. And this is my point, others will agree with this and others will disagree. That’s why it’s a discussion.

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years.

And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons:

1. A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things.

2. The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management.

So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha).

I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc.

Hope that helps.

Maybe as an alternative to the "open source" filter idea, it could be filtered on if it needs a paid license to run the program as-is? Of course there are always paid support options and paid add-ons/features, but as long as the base product which ships as-is requires a license or doesn't require a license, it'd be good to know that so people don't deploy Confluence for example assuming they can use it like most of the other apps for free and then realize they need to pay for it.

But assuming we go with the "open source" filter idea, my two cents to address the concern from @luckow is that as long as the base project/app has it's source code available, then it's tagged as open source. Because paid add-ons and paid support plans for the app doesn't diminish the open source nature of the original base project. Right? Maybe I'm missing something but it seems to me it'd be something fairly simple like that where we only look at the base project. Add-ons that aren't open source doesn't necessarily "void" the open source nature of the base project/app.

@murgero You're right, it'd likely be less of a burden if moving just to Debian. My comment however was made explicitly stating CentOS as the target OS rather than Debian (that would be my preference only as I'm more experienced with it, but Debian works too).

As I have a few mailboxes growing quickly for their business, while I have plenty of space left on my main SSD, I'd like to be able to dedicate (and move mail) storage to an external mounted disk. From what I can tell, this isn't possible to do yet in Cloudron (but please correct me if I've missed it).

It seems like a natural extension of the already-existing app storage in custom directories feature, so I naturally assumed I could do this already for mail but it doesn't appear to be the case. I would love to see the ability to move and store mailbox data on an external disk in the near future.

I've been using Cloudron for serving mail for about 15+ domains, and all has worked quite well overall. I'd say go for it if you're comfortable with managing a mail server.

I was going to write a blog post on this one day but here is a quick summary of what I found in moving roughly 12 WordPress sites to the WordPress app in Cloudron...

1. Use the All-In-One WP Migration plugin (https://wordpress.org/plugins/all-in-one-wp-migration/) to export the site, being sure to check the boxes in advanced section that say "Do not export must-use plugins" (if you don't do this it will overwrite the must-used plugins for LDAP authentication in the Cloudron implementation of WordPress)

2. Setup a new base WordPress site in Cloudron, and add in the same All-In-One WP Migration plugin. Now import the site file that was created in step one above.

3. After it's done importing, restart the WordPress site in Cloudron so that it can re-connect it's must-use plugins (initially I find access is lost to the main LDAP admin user until a restart).

4. Once in using your LDAP admin user, remove any old admin user and replace with the new one if you wish, and clean-up any unnecessary plugins and themes that are there by default.

Not only did I find this to be the quickest method but also the safest in terms of not losing anything at all. When I tried the Cloudron blog method it just seemed like a lot of extra work for me. But maybe that's because most of the sites I've designed aren't simple blogs, so maybe their method is still better for simple blog sites.

Enjoy.

+1 for having the ability to schedule reboots straight from Cloudron (in local time zone that's set of course rather than having to factor in UTC). I was just going to file a feature request for this and found this so figure I'd just add my two cents to it. Would love to see this, ideally it can be done from the System page with the Reboot button where it pops-up and allows it to be done right away or to schedule a reboot in local time, and also maybe even straight from the notification where it mentions a reboot is required for security updates. I'll settle for it just on the System page though for the Reboot button action.

Side note: The text on the Reboot button after clicking it states "Use this only when you experience unexpected behavior. All services and apps will be automatically started." but I think this needs to be changed, because the main reason one is rebooting is probably for the security updates, which has nothing to do with it being "unexpected behaviour" only. Perhaps it could be written in this way: "Use this when you experience unexpected behaviour or need to apply security updates. All apps currently running will be automatically started when the reboot is complete." I'll maybe submit this change in your box repository on git, as I like doing the smaller things that I'm capable of as I'm not a big programmer. haha

Any ETA for when 4.2 will be released? Or is it too early to tell yet?