@moktan.bj does this not work ? what message do you get if you try ? [image: 1738538867547-screenshot-2025-02-02-at-23.26.06-resized.png]

For those who hit this 8.2.4 is out . It's marked as unstable just to not have everyone update at the same time but it should be stable and has the fix for this issue.

@jdaviescoates Yes I had done that a while ago

Turns out the certificate seller emailed the wrong private key. @joseph thanks for the heads up.

@humptydumpty said in At home self-hosted Cloudron - migrate to larger main disk. Advice and sanity check my thoughts.: Having a GUI is preferable. I would also have recommended dd Something I havent used in ages, but i think would satisfy the gui criteria is https://clonezilla.org/

It's fine to keep the post around, helps others in the future @igaudette said in Custom app database wiped after migration: Looks like the backup is not backing up the database of the custom apps, is it possible? FWIW, the backup strategy is the same for custom apps and apps from app store. The only difference is that one uses a customer docker image/registry and the ones from the appstore use a appstore provided docker image/docker hub.

The best and easiest way is to use a single larger VPS to handle the different traffic apps. If uptime and stability are more matter in your case then you can run one app per VPS in critical services. Also, you can do a hybrid approach. The hybrid approach contains the separation of resource-heavy apps and low-traffic apps ones together. It can also work well. If you consider the cost then a single VPS is easier to manage and allows flexible resource allocation. But, it creates an issue like one application could impact others. Multiple smaller VPS instances provide better isolation and redundancy to one service that stays online if another fails. I prefer to use a single 4GB vps to a single app mostly. Still, if you want to use one vps for all apps then you have to prefer at least 8GB vps for sure.

Can you check if basic DNS resolution works ? See https://docs.cloudron.io/troubleshooting/#dns-resolution . Also, are you hosting at home or some private network (these have complications with loopback checks).

@osobo the power of the forum, thanks are due to @jdaviescoates and all those who went before on this issue.

@joseph said in Frequent Email is not configured properly notice: Maybe DNS is periodically failing on your servers. Do you know which DNS servers your server is using? You can use resolvectl to figure this. Thanks for the explanation! my DNS servers are : Current DNS Server: 1.1.1.1 DNS Servers: 1.1.1.1 9.9.9.9

@jdaviescoates said in Cloudron services are slow: @nebulon @KhalilZammeli said in Cloudron services are slow: update of the screenshot for our wordpress service, very high CPU usage, how can we investigate these ? Given the above and the fact WordPress uses mysql (and is very often attacked as it's so widely used, and malicious plugins are also quite common) that seem to me to be the obvious first app to investigate. Absolutely! Most of the time a WP plugin is the culprit. A WP plugin that's been acquired through a 'friend' which is not the original developer. Extremely, dangerous these are compromised in 99% of the times.

@senthilkumaran said in Cloudron Subdomain pointing to a different IP for Apps not on Cloudron: https://i.imgur.com/3gtJVw1.png - wildcard means that all the *.thinnal.org will point to the cloudron's ip. If you have *.domain.org and foo.domain.org entries in your DNS provider , then foo.domain.org being more specific wins. One crucial note: this is not a feature of DNS since DNS protocol itself no concept of wildcard. This feature comes from the DNS providers (I think this comes from bind9 configuration files). But interestingly, I have the root domain thinnal.org pointing to a different IP and it works fine. Yes! because *.domain.org does not include domain.org . It only includes subdomains of domain.org but not the bare domain itself. This is another important DNS quirk to know.

@SunDevil I'll keep sharing... I've tried Nextcloud on several different platforms, including JUST Nextcloud. It ALWAYS conks out on me. Always. So, my 2 cents, you'll have the same issue on Dokploy. EDIT: Have you even checked out Dokploy??? I just watched their intro video. They install their software on your VPS from their servers! What?? Sorry, I'm not letting some third party have that access to my data. You create your ssh key on their system!!! You have to create a db separate from your app!!! Good luck keeping track of all those deets. Holy smokes, the number of steps needed to get this thing running is exactly why most of us have come to Cloudron. This Dokploy is so at the opposite spectrum of Cloudron. I can't imagine anyone thinking it will be "better".

If the system runs out of disk space, a lot of side-effects can happen, so this could very well be the root cause then.

Ok, it seemed running the /home/yellowtent/box/setup/start.sh to trigger the migration after restoring the database (because of the ERROR 1046 (3D000) at line 22: No database selected i needed to add these two lines to the dump file: CREATE DATABASE box; USE box; Then it was able to backup the database and run the migration.

Thank you @nebulon ... it's awesome timing , thanks for the share! I guess that should be considered a solved problem for the future then.

Right so we have a bunch of similar topics referencing the same problem. https://forum.cloudron.io/topic/13162/unable-to-send-emails-to-gmail https://forum.cloudron.io/topic/13145/problems-with-sending-mail https://forum.cloudron.io/topic/13122/email-sending-broken-after-updating-to-8-2-x-due-to-ipv6-issues https://forum.cloudron.io/topic/13072/gmail-ipv6-anyone-else-with-this-experience Should they all be merged and/or marked as solved? The solution is provided by @girish (here) and @jdaviescoates (here) which I'll compile and summarise here again: Activate IPv6 on Cloudron via going to Network > IPv6 > Configure > Public IP Check your IPv6 address either via reading the IPv6 address detected by Cloudron when doing 1. or via running curl https://ipv6.api.cloudron.io/api/v1/helper/public_ip on your server (via ssh). Set an IPv6 PTR record on your VPS/server provider (not your domain provider) for the above IPv6 address. The next Cloudron release will implement a check on IPv6 PTR record like it currently does for IPv4. If using Wildcard DNS then create a * AAAA record for the above IPv6 address. If things still don't work, you can go to Cloudron -> Domains -> hit Sync DNS If your VPS provider does not allow you to set IPv6 PTR, then disable IPv6 that way: disable IPv6 in Cloudron (Network -> IPv6 -> Disable) on your server via ssh run sysctl -w net.ipv6.conf.ens18.disable_ipv6=1 (replacing ens18 for your specific network interface, in my case eth0) make it persistent by adding net.ipv6.conf.ens18.disable_ipv6=1 to /etc/sysctl.conf (replacing ens18 for your specific network interface, in my case eth0) Update: I personally still faced issues with Gmail using IPv6 so I ended up disabling it persistently.

I followed the instructions, now the child sites work but the main network site isn't,

You have to install nginx and put those configs on the server where you deployed odoo . That is the correct place for putting those multiple port configs. Then nginx will then answer to a single port 80 which you can then put into cloudron.

Looks like this part does fix it (instructions for root server): [image: 1737492462373-9fbbe904-6e2e-4deb-8d7d-5d2812a54c83-image.png] Thanks to you both for the pointers!