@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...
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)
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.
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).
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.
For what it's worth, I have used Rspamd as part of a server I hosted using the Hardware/Mailserver docker containers, and out of the box it was a huge improvement to spam filtering for me. Unfortunately since moving to Cloudron's mail server, I'm getting way more spam going straight to my inbox with no real way of configuring it further either. Would love to see this improved, and Rspamd may be a big piece of the puzzle if my previous experience is anything to go by.
@nebulon Oh interesting, I didn't realize it wasn't supported yet, just assumed it was. Thanks for pointing it out, that changes some of my future plans then. 
I noticed there's a request in the Git for Cloudron to better expose the Spam settings as it's basically a blackbox right now, but in the meantime I was wondering how to change the default of "5" for marking spam in SpamAssassin, if I wanted to make it 4 for example, how would I do that? And would that change stay throughout reboots or be overwritten on reboot? And if it doesn't make sense for making this change yet, is there an ETA for 4.2?
Isn't this met by using the Sogo app? Personally I don't like the Sogo app especially with the mail interface so I chose not to use it, but if I really wanted Activesync for keeping emails, contacts, and calendars in sync... wouldn't I just accomplish that using Sogo? I think that's the answer, unless I've misunderstood the initial reason for wanting activesync.
Hello. I noticed in the GUI if I went to disable the SMTP server on my primary domain ("A") then I receive a warning about how it won't be able to send out password resets, user invites, etc. However no such warning exists if I go to disable SMTP on my secondary domain ("B").
I would like to suggest that this be improved because it could probably use a fail-safe where it warns users against disabling the SMTP server for that domain if there is also an active application on that domain. It should be obvious in most cases, but no harm in adding an extra sanity check for those who may need it.
Additionally, are we able to lower the minimum requirements for some apps? For example, I have nodebb deployed which requires 1 GB however it's using less than 200 MB and I can't see it using much more as the use of it is very early stages and will be low overall for the foreseeable future. Seems like a waste of about 750 MB to me, which is a fair bit of memory when on a smaller VPS.
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.
@d19dotca said in How does the memory management work with regards to "low on resources" message when deploying a new app?:
be improved though to be clarified or with a link to the documentation where a new section would be written about memory management and how it works.
Ah okay, thank you for the clarification. I had just added an edit to my post at the same time as you confirmed it too.
Might I suggest this be improved though to be clarified or with a link to the documentation where a new section would be written about memory management and how it works. I'm in support for my day job so I always go "How can I keep users from needing to contact me", haha, and basically write out as much documentation as needed to prevent calls and stuff. This may make it easier for users going forward too as you have more onboard to Cloudron.
Hi there,
Somewhat new user of Cloudron and for the first time I ran into a message when I tried to deploy the new BookStack app, which states "This Cloudron is running low on resources". However when I look at the Graphs page, I see plenty of memory available (most cached though) and the charts show low usage.
It's unclear to me why I'd be told it's low on resources. Is it because it checks based on if every app deployed ran up to their max allotment, for example? Looking to understand the logic behind that message, how it determines that it's low on resources when the graphs would seem to indicate otherwise.
Trying to determine if I should be concerned and upgrade my VPS or if realistically I'm perfectly fine still for a bit of growth yet.
By the way, the BookStack app only requires 256 MB of memory, so based on the graphs it should have been fine as I have a few GBs left to go on the system.
EDIT: I should add that I recently installed nodebb which has a minimum requirement of 1GB even though it's currently only using about 200 MB, so I am suspecting that it is since it's max allocation for that app would run 1/4 of my whole system currently. Guessing the warning is based on max allotment of all apps combined and then seeing what's left over. If so, this should perhaps be improved though to be clarified or with a link to the documentation where a new section would be written about memory management and how it works.
Are we able to workaround this not being a Cloudron-approved app by deploying Cachet in a LAMP app instead? Has anyone tried that yet? I think I may try that this weekend if time permits.