Cloudron uses SRS for mail forwarding. Does SES support SRS? I think off late gmail has also changed behavior wrt SRS. I think @girish is aware of this already, there is no fix currently.

Back from vacation. I had to write a script to search the backups for gitlab backups that had postgresqldump files with actual data. Apparently the last "good" backup that had a good postgresqldump file was back in April (2025-04-24-090000-501/app_gitlab_v1.103.0.tar.gz.enc). I was finally able to get it working by reapeating the restore steps: Install the matching version of Gitlab to the backup version Then restore by importing the backup Not sure how exactly it got to this state, but it's finally back up and running!

Disk space. Ram. Probably the two* main components of a server that will make running Cloudron (or any software, really) a pleasure or a pain. But I think the easy answer isn't necessarily the best - buy a server with lots of disk space and lots of RAM - because use-case factors in alot. Perhaps some sort of pop-up questionnaire at some point in the purchase stream or set up process asking which apps are likely to be used would be one way to give a user a heads-up that their 4GB RAM, 60GB SSD server isn't going to cut it (or in this case an 8GB running Gitlab! Plus, it seems they are running additional software on that server, this "Mesa de Ayuda" which seems to be some kind of helpdesk software... Cloudron clearly advises running only Cloudron on a server and nothing else, so that was utilizing the same minimal 8GB of RAM). That said, I moved my Mastodon app off of my main server which has 64GB RAM and successfully run it on another server with just 4GB RAM plus 4GB swap, plus a Wordpress app, with stable results. I've also run a Presearch node on a 3.5GB RAM server along with Cloudron, and it all worked. *A third would be using Cloudflare. I know why ppl use it, I just don't know why ppl use it.

@ruben.villarreal I got your mail on support@ and I have reset the app installations on our side. Can you please confirm?

I was able to resolve this. I created a subaccount API key that I used for authentication before generating a secret key for the primary API key (by default Mailjet creates a key but not a secret for that key, which is a manual action). Now I just generated a secret key for the primary API key and used this instead of the subaccount key and it worked.

Here my 2cents; I personally host my Cloudron at Hetzner I enabled in front of Cloudron Cloudflare and Enable proxying for new DNS records (that is inside Cloudron at the domain level) Enable Firewall at Hetzner for my Server HTTPS only between my Cloudron and CloudFlare [image: 1756114585161-brave_9vbg9hsube.png] you can find the IP here Why ? So even if someone retrieve the IP (example via mail service) it cannot try to hack any webapps. Of course; I have others Rules at Hetzner Firewall Level; that basically replicate Cloudron's Firewall: SSH, Mails, STUN, TURN, ... After that; you mostly need to choose wisely the apps you deploy; trust the due diligence of these developers. Having a WAF; bring more complexity that would probably slow down the integration of new apps...

Thanks! Can't wait to see the light

@girish Is this use case covered in Cloudron 9?

@nostrdev So glad you listened when we chatted about that too! Welcome.

Maybe your system/network from where you were trying to access your server had some long DNS cache pointing to the wrong IP. Glad it worked out in the end though.

Sweet, thanks. I added it to my start script.

@robi I only added the recommended commands: 0 13,23 * * * rm -rf /app/data/public/wp-content/cache/* > /dev/null 2>&1 0 13,23 * * * rm -rf /tmp/magick-* /tmp/imagick* > /dev/null 2>&1

Fixed in https://git.cloudron.io/platform/box/-/commit/e390a56f055a3e71ed324485d7a9ce7e441e1e66

@girish It's a LAMP app with apache configured to point to another directory.

Thank you all! the issue was the unbound service not working and also my email delivery issue too.

@james I could not get it working at all, so I switched to use Sendgrid instead since we have an account and that is working fine. The issue is that I am using Cloudron as a VM inside of Truenas Community 25.04.1 and it is Truenas causing the issue and I would have to make some major changes and I don't want to affect the File Server side by doing this.

Can you SSH and run cloudron-support --troubleshoot on the server? This should give us an idea of DNS issues etc.

Looks like your server has a wrong ipv6 outbound setup. Cloudron does not configure the network interfaces of the server, so this maybe a misconfiguration from your server provider. This happens with some VPS providers sadly still. First step would be to figure out why a plain curl to a ipv6 cannot connect. Your server provider should be able to help you out there. If this can't get to work, you may disable ipv6 in the Cloudron dashboard and also remove the AAAA record again.

Just a quick update, since I am using this since March. I didn't had any issues with that kind of storage usage for the Docker during normal operations. As I didn't have an situation with restore or bare metal recovery, I still don't have any experience for these use cases. So far, I am pretty happy to offload the Docker Images to the Hetzner Volume.

@vjvanjungg not 100% sure but we got a similar report on Support and I replied there. The mail server is not responding after the initial SMTP EHLO. Can you check the raw mail server logs - https://docs.cloudron.io/email/#event-log ?