Cloudron Forum

@Jorradezk The approach you described leaves a security gap. If IP filtering is only applied on “Server A” in front of the Cloudron Proxy App, an attacker could potentially bypass it by connecting directly to the Cloudron server’s public IP or any other exposed port.

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.

@james I would love to have this enhancement. This would be a game changer for custom (unsupported) Apps

@d19dotca Thanks for sharing your solution — it’s a solid and pragmatic setup! Just two key points to consider:

1. Docker Subnet Might Change in Future

Your script currently hardcodes 172.18.0.0/16 as the Docker subnet. While this is the default for Cloudron, it’s technically subject to change — either through manual config changes or future Cloudron updates. To make your script more robust, you could dynamically retrieve the subnet like this:

CLOUDRON_SUBNET=$(docker network inspect cloudron --format '{{ (index .IPAM.Config 0).Subnet }}')

This ensures your SNAT rule always uses the correct range.

2. Host-Level Traffic Still Uses Default IP

Your setup correctly SNATs all container traffic, but be aware that outbound connections from the Cloudron host itself (e.g. system updates, wget, DNS lookups) will still use the primary server IP unless you apply a similar SNAT rule for host traffic. If consistency across all outbound traffic matters (e.g. for whitelisting or compliance), you might want to extend the approach accordingly.

@timconsidine Sounds very interesting as I am looking for something pretty lightweight - without any maps or so. I did send you a private message.

Thanks for your efforts with PinMe!

Chatmail can already be used on Cloudron — since Cloudron provides a full-featured mail server out of the box, you can easily connect it to a Chatmail-compatible client like Delta Chat using your existing Cloudron e-mail account.

There’s no need for a separate Chatmail-specific app on Cloudron — the infrastructure is already there. Just point Delta Chat (or another compatible client) to your Cloudron mail server credentials, and you’re good to go with end-to-end encrypted messaging.

I also get this error message from time to time on my Cloudron on Hetzner VPS. Usually during night and when I check in the morning the issue does not exist anymore. Maybe it is an issue with DNS Lookup?

@d19dotca Looks great, thanks for sharing!

I totally agree. It is my third year using Cloudron and I still love the stability and reliability.
I would also like to thank in addition to the Cloudron Community which is always open and supportive!

THANKS!

Hi there,

I read about this RCE vulnerability of the Ingress NGINX Controller:
https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities

They mention Kubernetes, and I am not sure, if we are using this Controller on Cloudron?

Anything we have to do here?

Best,
Michael

@nebulon I will build up real experience and report here

I understand your concerns, but in this case it is a Hetzner Volume which is mounted as a local SSD Disk. I guess in this case you agree that it is ok?

@humptydumpty I tried all of them, but I did like Navidrome most, followed by Koel. Ampache was okish and I didn't like Emby.

Regarding the Navidrome crashes. If you have many music files, I suggest to raise the memory limit. The default one is to low.

@crazybrad yes, I did tests. Unfortunately I was never able to restore a Cloudron App Backup because of using encyription. Somehow I was not able to decrypt the backups - even if I noted the encryption key in a password database. In the meantime I disabled the encryption, but didn't test a restore so far.

Restoring Snapshots/Backups from VPS is totally easy. Tests to second VPS always worked flawlessly and I used VPS snapshots two times for migrating between hosting zones (Nürnberg -> Helsinki -> Falkenstein) without problems.

I retried this morning and it did work on my Cloudron instance. It just takes a couple of minutes until all the images are pulled. I am still not sure if the command systemctl start docker is really required, because it never give back control - since CPU, Disk and Network usage was idle for some minutes I decided to perform the reboot of the VPS and everything went fine then.

One question regarding disaster recovery. When I do need to restore my Cloudron from VPS Snapshot, the new location of /var/lib/docker is not in the Snapshot anymore because I am using a Hetzner Volume for it. When the Volume is not destroyed I guess there wont be any problem when writing back the snapshot. But what happens when the Volume has been destroyed? I assume that Cloudron will just need to pull all the docker image stuff again? Is there anything that I should know before the worst case may happen?

@luckow One Cloudron Instance running at Hetzner VPS (8GB RAM, 80GB Disk, 4 Cores), 10 Domains, 15 Apps running. Doing Cloudron Backups twice a day and VPS Backup once a day. Before Updating Cloudron to new versions, and sometimes before NextCloud Updates, I perform a VPS Snapshot in addition.

I didn't see any errors. A second ssh connection and systemctl status docker was looking okay, but Dashboard was timing out. I guess you are right and loading and recreating the images might consuming the time. I was not expecting a long wait because the guide mentions to update the version to trigger re-download and creation of the images. Probably I will try again tomorrow with some more patience.

Hi there,

I tried to organize storage on my VPS better by moving Docker Images to a Hetzner Volume (SSD, Mountpoint) according to this guide https://docs.cloudron.io/storage/#docker-images

Unfortunately it took neverending when executing systemctl start docker

Finally I lost my nerves and reverted all previous changes and at least after rebooting the VPS my Cloudron was working again as before.

I just would like to know if that part of the documentation should still be valid and applicable?

Cheers,
Mike

I can confirm that on my Cloudron I see the same messages when restarting the mail service.

@joseph 1) This approach is seperate to the common Cloudron usage
2) Updates are not automatically, but manually
3) Not everybody is able to build and install custom packages
4) It requires public space on docker.hub or a private instance of docker repo
5) the package is not optimized by the Cloudron maintainers