@jdaviescoates Great idea! I'd definitely love to be a part of something like that.

What I do:
I do freelance web & tech services as a side business, and that includes hosting a bunch of things for customers which I do on Cloudron. Specifically WordPress websites for roughly 15 clients, and recently even some SFTP servers for one client too. Also a nodeBB forum for a client, Bitwarden password manager, email hosting of course, webmail apps, all that jazz. WordPress and email is the vast majority of what I host for my clients, but I get to dabble in other areas too which I like. Oh and web analytics too of course as that's bundled with my web hosting plan I sell to them, and to my surprise many of them actually really like seeing the emailed report from Matomo where they see all the results from each city, country, dates and times of busy traffic, etc. When I started offering it I honestly didn't think too many people would care, but most of them really like that part. I guess it sort of helps justify to them why they have a website in the first place so they can see how many people they're effectively reaching and such too in one area.

I don't necessarily market my services as a Saas-Cloudron or anything like that, just to be clear in case that's kind of what you were asking earlier, but I am very open in spreading the word of Cloudron (sounds like I'm in a cult, lol) to any of my clients that want to learn more about how I manage things, and even link to Cloudron from my website, so generally the customers that actually care to know that stuff all know I'm using Cloudron as the platform for everything.

Quick side story about the SFTP server I recently setup, just because I think it's really cool, haha:
Using Surfer, I setup an SFTP server to bridge a medical clinic (client of mine) administering COVID-19 tests and the lab they hired to actually process the tests. Before, they were emailing constantly between clinic and lab and it was a hassle for them to keep track of everything... and we later found out that the lab they contracted actually had a script which they use for their larger clients I guess - it polls the SFTP server every 5 minutes for a CSV file which the clinic fills it out and saves to the SFTP server for each patient, each patient being it's own row on the CSV. It's streamlined their entire process now - just that one thing alone - to the point where they get their results much faster now from the lab and can then forward that to the patients much quicker than before as it's way less overhead in communications between the lab and clinic. Once I heard about this and set it up for them and learned how much better it made things for them, honestly I was humbled in a way, I consider myself fortunate to have been a very very very tiny part of that process to ensure people can get their COVID-19 test results sooner. It really wasn't much work on my part at all, Cloudron made it easy to implement! It was still cool to be a part of an improvement to this essential service in my region none-the-less.

Sorry I'm rambling on now, lol, the answer to your original question is "Yes, I offer services to my clients that I host using Cloudron". haha.

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've been spending a long time lately on spam improvements on the Cloudron mail server. I've made a ton of improvements and while still not perfect (it never will be) it's a giant leap over how it was a few weeks ago.

I already made some updates in the other post on DNSBLs, for anyone who hasn't seen that already.

I've also improved the spam classifications for anything that gets past the DNSBLs. It was already pretty decent at classifying spam that was spam with no false-positives, however there was still a good amount getting to the inbox for some users in particular. I've trained them to use the spam folder and archive folder accordingly to train the filter for their account, but I also made a whole bunch of tweaks in the custom rules to overwrite scoring server-wide.

Tip: You can easily override the default SpamAssassin scores or even create your own rules using the Custom Spam Filtering Rules feature in Cloudron.

I thought I'd share what I have currently which adds in a few new providers as well as increasing the scores from their defaults. Here is what I've got currently and it seems to be working very well for me and my users with no false-positives that I can find and much more in the spam box where they should be. Feel free to adapt of course for your own servers.

The main highlights of the changes I made was the following:

• Increasing the scores for various DNSBLs where appropriate from their defaults
• Increasing the scores for SPF failures but keeping them still reasonable as not ever mail server has setup SPF correctly even if legitimate
• Modifying the scores for the BAYES_ learning ones, scoring them according to their confidence levels (and a bit above the default in most cases)
• Added three new DNSBLs for SpamAssassin (seen at the bottom of the list) which when combined with the overall scoring changes for DNSBLs built-in has provided a noticeable improvement in spam recognition

# scoring DNSBLs (blocklists & allowlists)
score RCVD_IN_BL_SPAMCOP_NET 2.0
score RCVD_IN_DNSWL_NONE 0.5
score RCVD_IN_DNSWL_LOW -0.5
score RCVD_IN_DNSWL_MED -2.5
score RCVD_IN_DNSWL_HI -5.0
score RCVD_IN_GBUDB 4.0
score RCVD_IN_JMF_BL 3.0
score RCVD_IN_MSPIKE_H3 -2.0
score RCVD_IN_MSPIKE_H4 -3.0
score RCVD_IN_MSPIKE_H5 -3.5
score RCVD_IN_MSPIKE_L3 2.0
score RCVD_IN_MSPIKE_L4 3.0
score RCVD_IN_MSPIKE_L5 3.5
score RCVD_IN_MSPIKE_WL 0
score RCVD_IN_MSPIKE_ZBI 4.0
score RCVD_IN_SBL 3.0
score RCVD_IN_SORBS_BLOCK 2.0
score RCVD_IN_SORBS_DUL 2.0
score RCVD_IN_SORBS_HTTP 2.0
score RCVD_IN_SORBS_MISC 2.0
score RCVD_IN_SORBS_SMTP 2.0
score RCVD_IN_SORBS_SOCKS 2.0
score RCVD_IN_SORBS_SPAM 2.0
score RCVD_IN_SORBS_WEB 2.0
score RCVD_IN_SORBS_ZOMBIE 2.0
score RCVD_IN_SPAMRATS 4.0
score RCVD_IN_XBL 3.5
score RCVD_IN_PBL 3.5
score RCVD_IN_SBL_CSS 3.5
score RCVD_IN_ZEN_BLOCKED_OPENDNS 0.5
score RCVD_IN_ZEN_BLOCKED 0.5

# scoring URIBLs
score URIBL_ABUSE_SURBL 3.0
score URIBL_BLACK 3.0
score URIBL_CR_SURBL 3.0
score URIBL_CSS 2.0
score URIBL_CSS_A 2.0
score URIBL_DBL_ABUSE_BOTCC 2.0
score URIBL_DBL_ABUSE_MALW  2.0
score URIBL_DBL_ABUSE_PHISH 2.0
score URIBL_DBL_ABUSE_REDIR 2.0
score URIBL_DBL_ABUSE_SPAM 2.0
score URIBL_DBL_BLOCKED 2.0
score URIBL_DBL_BLOCKED_OPENDNS 2.0
score URIBL_DBL_BOTNETCC 2.0
score URIBL_DBL_ERROR 2.0
score URIBL_DBL_MALWARE 2.0
score URIBL_DBL_PHISH 2.0
score URIBL_DBL_SPAM 2.0
score URIBL_GREY 1.5
score URIBL_MW_SURBL 2.0
score URIBL_PH_SURBL 2.0
score URIBL_RED 2.5
score URIBL_RHS_DOB 2.0
score URIBL_SBL 2.0
score URIBL_SBL_A 2.0
score URIBL_WS_SURBL 2.0
score URIBL_ZEN_BLOCKED 2.0
score URIBL_ZEN_BLOCKED_OPENDNS 2.0

# scoring SPF & DKIM
score DKIM_INVALID 1.0
score DKIM_SIGNED -0.5
score DKIM_VALID -0.5
score DKIM_VALID_AU -0.5
score DKIM_VALID_EF -0.5
score DKIM_VERIFIED -1.0
score SPF_FAIL 2.0
score SPF_HELO_FAIL 2.0
score SPF_HELO_NEUTRAL 0.5
score SPF_HELO_NONE 0.5
score SPF_HELO_PASS -0.5
score SPF_HELO_SOFTFAIL 1.0
score SPF_NEUTRAL 0.5
score SPF_NONE 0.5
score SPF_PASS -0.5
score SPF_SOFTFAIL 1.5

# scoring BAYES
score BAYES_00 -1.5
score BAYES_05  -1.0
score BAYES_20  -0.5
score BAYES_40  0.5
score BAYES_50  1.0
score BAYES_60  1.5
score BAYES_80  2.0
score BAYES_95  3.0
score BAYES_99  4.5
score BAYES_999 5.0

# additional scoring tweaks
score BILLION_DOLLARS 2.0
score FREEMAIL_FROM 0.5
score HEADER_FROM_DIFFERENT_DOMAINS 3.5
score HTML_FONT_LOW_CONTRAST 2.0
score HTML_MESSAE 0.5
score LOTS_OF_MONEY 1.5
score MISSING_HEADERS 1.0

# add GDUB TRUNCATE DNSBL
header RCVD_IN_GBUDB eval:check_rbl('gbudb', 'truncate.gbudb.net.')
describe RCVD_IN_GBUDB Listed in truncate.gbudb.net
tflags RCVD_IN_GBUDB net

# add JMF-Black DNSBL
header RCVD_IN_JMF_BL eval:check_rbl('jmfbl', 'black.junkemailfilter.com.')
describe RCVD_IN_JMF_BL Listed in black.junkemailfilter.com
tflags RCVD_IN_JMF_BL net

# add Spamrats DNSBL
header RCVD_IN_SPAMRATS eval:check_rbl('spamrats', 'all.spamrats.com.')
describe RCVD_IN_SPAMRATS Sender listed in all.spamrats.com
tflags RCVD_IN_SPAMRATS net

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

@imc67 I definitely agree, lots of areas for improvements.

I do have one item of your post I wanted to share my two cents on though...

Wordfence imho needs to be installed by default in Wordpress

This is just my personal view so take it with a grain of salt of course, I don't think there's really any right or wrong way to it. My two cents...

I have the belief that we should aim to keep all apps (WordPress included) about as close to default as the developer intended for the app, leaving Cloudron to just handle the default user and mail config for the app, etc. I think it's a bit of a slippery slope to add in all these extras regardless of how important they may be for certain use-cases, because the line needs to be drawn somewhere of course and deciding where that line is isn't particularly clear. In such a case, I'd ere on the side of "keep it as close to default as possible as intended by the developer" to stay free of any tightrope walking so-to-speak. haha.

For WordPress in particular, there's practically hundreds of thousands of plugins available, some of which are "default installs" in my environments where I have a template setup with the ones I use all the time for example, but I would never want to force my defaults on others because what works for me or the plugins I prefer to use may not work or be preferred by other users. Security plugins are one area where there's a ton of them, and there was a similar discussion not too long ago I had regarding a suggestion for including a caching plugin by default too.

And that's kind of the slippery slope I am referring too... what is the criteria for when a "default plugin suggestion" gets approved, and when would one get denied?

I just really want to see apps be as close to default as possible. But of course that's just my two cents. I'm sure many might disagree with me. haha.

I totally agree with the rest of your suggestions though, I would love to see the improvements for additional security in the Cloudron server itself. I completely forgot about the GEO-blocking request for countries, that'd be pretty great to have!

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

It'd be great to have the ability to add comments to backups, particularly app backups.

My example use-case: I have a WordPress app running, which I am working on some performance-projects. I'm making backups after each different plugin change for example to be able to easily restore back to baseline and after certain plugin changes. After making so many app backups, it can be difficult to later remember which one was the baseline, which one was for any particular plugin change, etc.

Having the ability to add notes to app backups would be a great way to handle that type of use-case.

I picture the UI with a small icon next to each backup to easily add notes. Then to view them, it'd be great to have it either pop-up when hovering over a backup or to perhaps have a short accordion effect to expand the notes applied to the backup. The latter would be more mobile-friendly as mobile devices don't really have the ability to "hover" over items.

@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).

Just wanted to check in and see how 6.3 is coming along.

Any ETA by chance? I'm super excited for these email improvements many of us have been requesting, particularly the DNSBL checks; greylisting; blocklist & whitelist auto-updating/DNSWL; email autoexpunge; and not forwarding spam to mailing lists. I know that's a lot, lol.

I know many of them came from me, haha, so if you want to discuss any of them or want clarification on the requests, I'd be happy to help offer guidance or clarification.

@girish said in How about a Cloudron meet-up in Berlin in 2021?:

Yes! We did it when Kopano meet was getting packaged

Perfect! I'd join if it was online then. Would love to visit Germany someday, but being "at risk" (cystic fibrosis) I ain't travelling out of Canada during this pandemic, especially when insurance won't cover anything like that anymore haha

I just realized Vultr DNS is not included in the Cloudron list of API integrations, and given that DigitalOcean is included and Vultr is basically a DigitalOcean equivalent, it may be worthwhile to add Vultr too.

Like the others, they also have an API to use for it: https://www.vultr.com/docs/introduction-to-vultr-dns#Manage_DNS_via_API

@girish I was looking through the list of certs on my server, and found many certs that haven't been used for at least a 4 - 9 months. This is likely more applicable when using individual certs per app hostname as opposed to wildcard certs, but I would suggest it makes sense to automatically cleanup certs from the file system at least after 3 months when they expire. What good is a Let's Encrypt cert that's 6 months old (expired 3 months ago), for example?

I just wanted to say I noticed an excessive use of logs again on my server. I guess this wasn't fixed yet, eh?

ubuntu@cloudron:~$ sudo du -ch -d 1 /home/yellowtent/platformdata/logs | sort -hr
12G	total
12G	/home/yellowtent/platformdata/logs
1.6G	/home/yellowtent/platformdata/logs/tasks
919M	/home/yellowtent/platformdata/logs/6b3ebc4f-9708-4243-bc21-4c9a01bc3499
916M	/home/yellowtent/platformdata/logs/76aa4cfd-a1c7-451a-a11e-a4fabe5ff95b
804M	/home/yellowtent/platformdata/logs/9f9aba4a-f7b1-44d8-859c-c6953027c39e
803M	/home/yellowtent/platformdata/logs/00895422-a1ff-4196-8bb8-cb4ff8d6eeaa
801M	/home/yellowtent/platformdata/logs/6e21d87b-ea85-420b-8eed-8b14d601438d
755M	/home/yellowtent/platformdata/logs/f6b21e27-6d25-4c69-a547-0466e622d719
754M	/home/yellowtent/platformdata/logs/493c4f88-5d4d-40e5-8361-fd7d4541441d
735M	/home/yellowtent/platformdata/logs/633f2c77-9b33-457a-bc3c-919c87d25ca2
726M	/home/yellowtent/platformdata/logs/29354a9c-7e1d-4986-b78e-3510fe73b370
699M	/home/yellowtent/platformdata/logs/6120f84a-0953-4982-9167-ef872c0ee49a
685M	/home/yellowtent/platformdata/logs/05db518f-2c45-411b-865f-813dbf85c244
561M	/home/yellowtent/platformdata/logs/8dba8d47-7890-49d3-8dfa-970e1ec52991
294M	/home/yellowtent/platformdata/logs/e18fa18b-b176-4b25-bf78-4d82c022b0f5
271M	/home/yellowtent/platformdata/logs/d3121e48-4196-48fe-907d-ee831e11ce5c
85M	/home/yellowtent/platformdata/logs/200d36ca-8109-409a-9b56-07f46c2f09bd
83M	/home/yellowtent/platformdata/logs/4d2fc2b7-2475-4c6b-97b4-4f896fbe8e9e
76M	/home/yellowtent/platformdata/logs/21aecd6a-398a-433a-a954-5bcd5f861e20
67M	/home/yellowtent/platformdata/logs/4929b73d-cfa4-4246-82a7-4bc8127982f6
57M	/home/yellowtent/platformdata/logs/93c19968-5b36-4412-adfe-3a8f338143ec
46M	/home/yellowtent/platformdata/logs/95c45c33-bd8a-4fae-9718-509c69456abe
43M	/home/yellowtent/platformdata/logs/134ef7f1-46f8-403e-8ac5-a3297b37893f
43M	/home/yellowtent/platformdata/logs/1247a348-c8da-4f30-8a4c-3fa014f092a1
36M	/home/yellowtent/platformdata/logs/c40f9f5f-037c-4a1d-8538-f1f4d4b82f5d
33M	/home/yellowtent/platformdata/logs/8315f008-87e9-4f62-9ae8-1938d7b3f9b2
26M	/home/yellowtent/platformdata/logs/graphite
25M	/home/yellowtent/platformdata/logs/mail
23M	/home/yellowtent/platformdata/logs/turn
20M	/home/yellowtent/platformdata/logs/e50f78c7-da6e-4036-a1a3-0cc934448cf1
19M	/home/yellowtent/platformdata/logs/3167ef7d-e4c2-4072-8e11-8de49c5db970
16M	/home/yellowtent/platformdata/logs/sftp
14M	/home/yellowtent/platformdata/logs/ea2ee30a-8d3b-4a3b-8817-19b0f1e17bd7
13M	/home/yellowtent/platformdata/logs/38f883dc-4047-4237-a6a1-3ecd77efcde9
9.3M	/home/yellowtent/platformdata/logs/collectd
8.9M	/home/yellowtent/platformdata/logs/redis-e18fa18b-b176-4b25-bf78-4d82c022b0f5
4.5M	/home/yellowtent/platformdata/logs/9fdedb7f-1bd4-42f6-a7e8-9831df9da8dd
3.9M	/home/yellowtent/platformdata/logs/0db23e8d-9515-45ad-8739-6cf2a2b1078f
3.7M	/home/yellowtent/platformdata/logs/mysql
3.4M	/home/yellowtent/platformdata/logs/8732aed0-273e-49f5-837f-cd9c600bf7b9
2.9M	/home/yellowtent/platformdata/logs/redis-1247a348-c8da-4f30-8a4c-3fa014f092a1
2.8M	/home/yellowtent/platformdata/logs/mongodb
2.7M	/home/yellowtent/platformdata/logs/redis-f6b21e27-6d25-4c69-a547-0466e622d719
2.7M	/home/yellowtent/platformdata/logs/redis-9f9aba4a-f7b1-44d8-859c-c6953027c39e
2.7M	/home/yellowtent/platformdata/logs/redis-95c45c33-bd8a-4fae-9718-509c69456abe
2.7M	/home/yellowtent/platformdata/logs/redis-8dba8d47-7890-49d3-8dfa-970e1ec52991
2.7M	/home/yellowtent/platformdata/logs/redis-76aa4cfd-a1c7-451a-a11e-a4fabe5ff95b
2.7M	/home/yellowtent/platformdata/logs/redis-6e21d87b-ea85-420b-8eed-8b14d601438d
2.7M	/home/yellowtent/platformdata/logs/redis-6b3ebc4f-9708-4243-bc21-4c9a01bc3499
2.7M	/home/yellowtent/platformdata/logs/redis-6120f84a-0953-4982-9167-ef872c0ee49a
2.7M	/home/yellowtent/platformdata/logs/redis-493c4f88-5d4d-40e5-8361-fd7d4541441d
2.7M	/home/yellowtent/platformdata/logs/redis-29354a9c-7e1d-4986-b78e-3510fe73b370
2.7M	/home/yellowtent/platformdata/logs/redis-200d36ca-8109-409a-9b56-07f46c2f09bd
2.7M	/home/yellowtent/platformdata/logs/redis-05db518f-2c45-411b-865f-813dbf85c244
2.7M	/home/yellowtent/platformdata/logs/redis-00895422-a1ff-4196-8bb8-cb4ff8d6eeaa
2.6M	/home/yellowtent/platformdata/logs/redis-134ef7f1-46f8-403e-8ac5-a3297b37893f
2.6M	/home/yellowtent/platformdata/logs/40ae3d28-d67f-453e-895d-0f22b539372c
2.0M	/home/yellowtent/platformdata/logs/redis-4d2fc2b7-2475-4c6b-97b4-4f896fbe8e9e
1.5M	/home/yellowtent/platformdata/logs/redis-4929b73d-cfa4-4246-82a7-4bc8127982f6
1.1M	/home/yellowtent/platformdata/logs/redis-21aecd6a-398a-433a-a954-5bcd5f861e20
924K	/home/yellowtent/platformdata/logs/redis-93c19968-5b36-4412-adfe-3a8f338143ec
416K	/home/yellowtent/platformdata/logs/492b4264-fea8-4d52-bbe6-1f15ce72c53a
288K	/home/yellowtent/platformdata/logs/updater
168K	/home/yellowtent/platformdata/logs/redis-633f2c77-9b33-457a-bc3c-919c87d25ca2
152K	/home/yellowtent/platformdata/logs/postgresql
112K	/home/yellowtent/platformdata/logs/redis-0db23e8d-9515-45ad-8739-6cf2a2b1078f
4.0K	/home/yellowtent/platformdata/logs/crash
4.0K	/home/yellowtent/platformdata/logs/backup

@girish I'm not sure if that makes complete sense to me yet, but as always I appreciate the detailed explanation.

I can understand that Cloudron is checking to make sure an app hostname can be resolved, but I'd think it just needs to do a DNS lookup to make sure it can resolve the hostname of the app, then proceed forward. I don't quite understand why it care about the name server side of things. As long as the app hostnames are resolvable, shouldn't that be sufficient?

In my case, the IP isn't changing, nothing is changing other than I want to use DigitalOcean DNS whereas I currently use a Wildcard DNS backend. Everything is already working as-is and has been for quite some time. I should be able to link Cloudron up to DigitalOcean's DNS API to generate all the required DNS entries in the new service provider before needing to change name servers.

If Cloudron's main focus is to make sure the app "can be accessed via the browser immediately", then it should just need to care if the hostname is currently resolvable, right?

The best practice would be to switch name servers last when switching DNS providers for a domain, and the way Cloudron seems to currently work I cannot have Cloudron setup the new DNS service ahead of time before switching the name servers since it requires the name servers set first, which seems a bit backwards to me. Part of the beauty of that function is that Cloudron sets the DNS entries is automation, but this current behaviour is now requiring manual steps which seem unnecessary.

I guess the process just seems "off" to me, or rather backwards from how I'd think it should operate to achieve best practices and convenience to users.

@robi Oh yeah I get that, that's how rsync works, but I mean at OVH I never got the "rsync benefit" of differential backups when using it, and my server isn't busy enough to have thousands of files changed in a few hours, lol, but yet it seems to be working where I can see the benefit of rsync when using Vultr's Object Storage. I know that OVH uses OpenStack in the backend which also used something it auto-created called "+segments" folders, so it could have been some weird compatibility thing between rsync and OVH's Object Storage / OpenStack.

@robi I've always been using the tgz format because it always seemed more performant. I get the same behaviour though pretty much no matter what format I use, I noticed, as I just tried with rsync and basically the same thing in the logs showing the transfer speed really slow during the boxdata backup portion, but like 3 times faster on the other portions of the backup.

Funny enough, in my experience rsync was always really bad for Object Storage doing extensive testing with OVH Object Storage. I tried rsync just a bit ago today, the first full one and then a copy. The first full one took a long time (about 1.25 hours), but the subsequent one took only about 17 minutes which I was super impressed with. I never once got that behaviour in OVH where the second rsync time, it was always well over an hour no matter what. Perhaps Vultr's Object Storage is better though with the copy commands or something than OVH was.

I'm looking to change back from my wildcard DNS endpoint to DigitalOcean for some testing, and I noticed that Cloudron won't make the change until the name servers point there.

I get the following message: Domain nameservers are not set to DigitalOcean

Just curious... why is that prerequisite necessary for Cloudron to add in DNS entries?

I'd assume when changing DNS providers, that the safest course of action is to setup the DNS entries in the target service first for continuity / uptime. In my case, I was wanting to have Cloudron switch to DigitalOcean from Wildcard in order to setup the records it needs, then I'd make the switch in name servers. But it seems Cloudron wants the name servers switched first.

I didn't get much sleep last night so I may be forgetting something fundamental here, lol, but it just seems like an odd requirement to me at the moment to require the name servers changed first as that tends to go against "best practice" for switching DNS providers in my previous experiences.

@girish Fair enough. I’m trying with Vultr Object Storage at the moment (just started some tests today) and it’s performance is a smidge better than OVH so far with the same general settings, getting around 8-15 Mbps for most of the app updates, but one thing I noticed behaviour for both OVH and Vultr (so I assume others too)… when it gets to the box data (emails) it slows to a crawl and ranges from just 1-3 Mbps, which when uploading about 25 GB of box data makes this an incredibly lengthy process. Any ideas why that might be consistently dropping when Cloudron gets to the box data?

@robi Ah okay, makes sense. That kind of jives with my experience too where tgz was much better than rsync, but even tgz was still slow.

@rmdes Funny enough I had one client testing it have that experience where the file they uploaded basically never completed, but I could never reproduce the issue. Been using it occasionally without issues here so far myself, but my client did have one bad experience with it.