@girish That's great to know, thank you! I will wait before migrating then so it's easier to do.

A request for clarification though... when you say "Change the Cloudron DNS backend ... to no-op"... do you mean all domains on the Cloudron or only the main one the Cloudron runs on? I have about 15 domains on my Cloudron, would I need to do that for them all or just the one main one?

Hello,

I am aware of the documentation for migrating Cloudron to a new server, but am unaware of how to test this while still keeping the old one running temporarily. Maybe I'm missing something or this is a total noob question, but wouldn't I run into licensing issues at that point having effectively two Cloudrons running?

The reason I bring this up... I'm considering moving away from a VPS at one provider and moving to another provider, but since I've never done the migration of Cloudron before I want to ensure I know how to do it first, particularly because there are a dozen client sites hosted on it right now and in particular two client domains that I have no control over their DNS as it is managed by another team for them, so I often have to wait for them to update the IP address before I can finally kill off any old server in favour of the new one.

So what I'm hoping to do is test the process, and once I know it's good, do a final restore point for any new emails that may have arrived in the hours or days between and then cut-over to the new server once and for all. But I have a few concerns such as the automatic DNS stuff... so I have many of my domains on DigitalOcean DNS and Cloudron controls it for me automatically. When I migrate to a new server, will it overwrite all the IP addresses for all of those domains right away, or will it wait for me to do something first? That's the part I'm most worried about in running this test. That and licensing of course.

How could I go about restoring/migrating to a new server while being in compliance with my license for Cloudron and not messing things up for my clients?

Any help would be appreciated.

Oh that's fantastic then, thank you @girish Much appreciated. I just saw the milestone flag change and got concerned, thinking I may need to devise my own solution if it would be quite far into the future for that to come out. Glad to hear it won't be too long and could still make it to 4.2.

I was checking up on things at git.cloudron.io and noticed that the email features we had discussed before were moved from milestone 4.2 to 4.3 which is disappointing though I understand you guys have a lot on your plate. Out of curiosity, since this is a pretty major feature that's needed for my freelance business / my clients, I'd like to know if possible a sort of time frame of when 4.2 and 4.3 are expected to land.

Knowing the approximate time frames (like 4.3 in say 2-3 months maybe?) would be helpful so I can make changes to how I currently deliver these features for my clients. Right now I have been holding off making big changes because I knew they were coming in 4.2, but since they've now been moved out to 4.3, I'm a bit more concerned and would like to know some more data so I can make an informed decision on what I should do next.

But please don't get me wrong - you guys are doing an awesome job and I'm definitely in love with this product! Happy it exists! This is just a major feature I had prior to my move to Cloudron which I am really missing and some clients aren't as happy as they were because of it. That's on me of course, but that was not a limitation I expected to run into. Remember, if you could even just possibly tweak the number of addresses allowed in a forward rule in order to execute, that would at least buy me some time. Right now it's an unreliable workaround because anytime the server needs to be rebooted I have to remember to go in and make that change in the appropriate Docker container again. Maybe that tweak could still go into 4.2 even if just temporary? That would at least help remove the need to do it manually every time.

@necrevistonnezr Ah interesting, good to know you figured that out then. Normally when that error is seen (I came across it quite a lot when setting up new environments on Cloudron as I learned the platform), it was always because I had already defined a "www" subdomain in my DNS provider, for example, so it then needed me to remove it before it could create it automatically by itself.

@necrevistonnezr - He means delete the DNS entry from your DNS service provider itself for the domain. So if you already have bitwarden.domain.com in your DNS listing for your domain, then remove the bitwarden entry and then re-create with Cloudron.

@caygri did you try my method? I moved sites upwards of 2 GB in size (mostly due to video media files) and it still went easily. I believe for that one though I had to manipulate the php setting to allow larger uploads, and that is in the product documentation to do so.

@murgero No, I came from hardware/mailserver docker containers, which is located here for reference: https://github.com/hardware/mailserver

It was one of the best mail server suites I had hosted. I moved to Cloudron for saving money as I no longer wanted to have a dedicated mail server when I had to have one for Cloudron too, and while it's been a good experience overall I can't seem to get the spam filtering to work at all off my marked spam messages from the spam folder. It seems to block some at the SMTP level when it receives a message that's on the blacklist, however it seems like it's completely not capable of learning anything from my spam folder. Most messages are very similar in subject, content, format, etc. There are 193 messages in my Spam folder right now since just July 12th, so just over half a month. Almost every single one of those originally ended up in my inbox, several a day, that I have to manually move over to the Spam folder in hopes of it learning it.

It's always possible something is wrong in my install maybe, and I'm happy to troubleshoot that, but in my personal experience SpamAssassin really isn't as effective as Rspamd from the different mail servers I've hosted over the years. Once I moved to Rspamd, it was as if it caught 98% of my spam and they showed up in the Spam folder as desired. Right now I'd say maybe 5% show up in my spam folder under the Cloudron mail server.

Yes I am, and it doesn't seem to do anything at all for me that I've noticed. I see maybe one message get caught by the spam filter and moved to Spam automatically. I move spam messages manually from my Inbox to the default Spam folder created when a new mail account is created, and I haven't seen it make any difference at all.

I receive a lot of spam (roughly 10-20 a day) due to a very old email account that's been scraped off the Internet for many years now, so the Spam folder is typically hundreds of spam messages there after a couple of weeks. It definitely has more than it needs to learn from, but in my experience it hasn't learnt anything at all as I have to still manually move almost every spam message from my Inbox to the spam folder manually as they aren't getting caught. From my look at the Mail logs, it does seem that some are getting caught by the blacklist check, but they seem to be few and far between, most seem to make it anyways as they don't get flagged with the blacklist check (new spambots I guess).

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.