Me too! I think there is a rather large audience waiting for Discourse availability on Cloudron.

This is no recommendation from cloudron, but from the riot-devs themselves: https://github.com/vector-im/riot-web#important-security-note I didn't have time to look further into the federation issue, maybe I'll find some time this weekend, sorry for the delay.

@realjohny For the my.example.com exposing real IP, you can simply turn on Cloudflare HTTP proxying (i.e click on the cloud icon in cloudflare dashboard to make it become orange). Cloudron will automatically adapt to this change. For the wordpress issue - Delete the www CNAME record in namecheap. Then go to Cloudron dashboard and click on wordpress app's configure button (the wrench icon that appears when you hover over the app). Then in the Location tab, there is a redirections section. Add www there as a redirection. With that done, you will be able to access www.example.com. Please let me know if that helped.

@ipedrolima Good point. In theory, this should be possible. Let us test this and get back. We might need some changes to the reverse proxy configuration to support multi site.

@iamthefij btw, you can set "minBoxVersion": "4.1.4" in the manifest so that people who are below that version don't try to install the app.

I had autoconfig setup for business emails before cloudron. Here is the process I used: Let's say you have the following domains: test.com: The domain for which you want to have email autoconfig my.test.com: The URL of your cloudron server that manages your email and will broadcast the autoconfig configuration. setup DNS entries in the test.com DNS // entry for outlook (never tested since I only use thunderbird) _autodiscover._tcp 600 IN SRV 0 0 443 my.test.com // entry for thunderbird and others autoconfig 600 IN CNAME my.test.com smtp 600 IN CNAME my.test.com imap 600 IN CNAME my.test.com // autoconfig.test.com does not need an SSL certificate // smtp.test.com, imap.test.com must have an active SSL certificate Create the mail directory and autoconfig file in the webroot for autoconfig.test.com create the file mail/config-v1.1.xml Content of mail/config-v1.1.xml // Here is a sample: <?xml version="1.0" encoding="UTF-8"?> <clientConfig version="1.1"> <emailProvider id="my.test.com"> <domain>test.com</domain> <domain>another-domain.com</domain> <displayName>test.com</displayName> <displayShortName>Test</displayShortName> <incomingServer type="imap"> <hostname>imap.test.com</hostname> <port>993</port> <socketType>SSL</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </incomingServer> <outgoingServer type="smtp"> <hostname>smtp.test.com</hostname> <port>587</port> <socketType>STARTTLS</socketType> <authentication>password-cleartext</authentication> <username>%EMAILADDRESS%</username> </outgoingServer> </emailProvider> </clientConfig> Nginx config since autoconfig does not require any SSL certificate you can setup any autoconfig request to match the same config file. For cloudron it might be better to have one config file per domain? server { listen 80; server_name autoconfig.*; root /var/www/autoconfig.test.com; access_log /var/log/nginx/autoconfig.test.com/access.log; error_log /var/log/nginx/autoconfig.test.com/error.log warn; location / { try_files $uri $uri/; } } Aside note in theory you should be able to not use imap.test.com and smtp.test.com, in practice though, I had trouble with thunderbird not recognizing the autoconfig without those 2 domains setup (it was 1 year ago, maybe it changed since) Hope it helps! I'll be happy to assist implementing if interested

A bit of thread necro, but I had the same problem. It appears that NodeBB is correctly configured, BUT in the Cloudron portal, by default, the "custom mailbox name" flag in the advanced app configuration settings is set to off. Thus, the email credentials correctly entered into NodeBB led to an account that, by default, was deactivated in Cloudron's mail server. For others who stumble here: From your Cloudron control panel, click the Configure tool (the pencil overlay over the app icon). In the Advanced tab of the pop-up, ensure that Custom Mailbox Name is checked, and that the name matches the name as configured in NodeBB's email control panel. By default, it's nodebb.app@. Problem solved, although whether it immediately resolved or whether it fixed when I rebooted Cloudron to install security updates about three seconds later, well ....

@ruihildt This is not for deleting emails but for deleting a whole mailbox. If email is deleted, they are gone forever. You can see all the mailboxes under /home/yellowtent/boxdata/mail/vmail.

Until there are better or more fine granular ones, there is always the option to create email filters in your email account to get a better overview, while still being informed.

@scooke This was indeed a bug in our restore UI. I have fixed this for 4.1.5

@d19dotca Thanks for the details! Let us get back by testing it out on a Mac.

@girish Many thanks for that! That did the trick

Changed As it is the default configuration for Roundcube it is working like intended and we could leave it like this? I don't think its a rare use case but maybe it could be added to the documentation (which I always found very helpful).

Okay, that makes sense. Thank you for the quick reply. I wonder if it would make sense to add a feature where we can set the IP address to accommodate floating IP's in providers like DigitalOcean, so that the DNS records automatically setup by Cloudron in DigitalOcean would be using the floating IP instead. Without such a feature, it kind of removes the ability to have a sort-of manual failover method which is one of the main purposes of a floating IP from DigitalOcean (along with a secondary use-case of setting up a new server to replace an old one and moving the floating IP to the new one when ready, eliminating the need to update a whole bunch of DNS records). It would be nice, I think, to have Cloudron use a floating IP that we give it even if it means we have to set it manually in Cloudron first since it can't detect it automatically. The main reason for this is that whenever I switch a server, for example, nothing really needs to be changed at all, leaving downtime to a minimum if it exists at all during a server switch.

@hdavy2002 Pushed an update to fix this now.

Would love to see this as well.

Indeed, missed that. Just making a blog post for 4.1 release which will include it.

We already implemented a mechanism wherein if the userId and the domain name matches, you will get subscribed to any previously subscription. If you have to change the domain, currently the only way is to contact support and give us the new cloudronId. @dustinddotca I guess you changed the domain name? Can you please send the new cloudronId to support@cloudron.io, will be happy to refund and transfer existing subscription.