@girish Done: https://forum.cloudron.io/post/89451

Hi Girish, First, thank you for taking the time to provide such a detailed and technical explanation. I genuinely appreciate it, as I find it very insightful. As I mentioned in an earlier post, the TMP directory that fills up the most is indeed Emby's because we move a lot of data there. We add a substantial amount of content regularly. However, it's not just Emby that has this issue. Several other applications also exhibit similar behavior. The list of these applications, which I posted earlier, includes: Emby N8N Cal Uptime Kuma OpenWebUI Penpot And a few other unidentified applications This list is not exhaustive, but these are the primary culprits. To answer your questions: a) Yes, the directory that had around 83GB of data was indeed Emby's TMP directory. This directory fills up quickly as we add more content. However, other applications also contribute to the storage issue, just not at the same scale as Emby. b) I add files to Emby using the File Manager. We do not use Emby's upload feature, even though we have an Emby Premiere instance. We prefer to manage our files directly through Cloudron because we trust its infrastructure and prefer to use it as intended. I understand that the issue is not inherently with Cloudron itself. My reflection was that this docker-volume issue only started appearing after I added a new storage volume to my server. To clarify, I added an OVH NAS-HA as a new volume to the server, and then I mounted it on Cloudron through the admin panel. This docker-volume did not exist, or at least was not noticeable, before this addition. Since moving Emby to the new volume, I see my data on the new volume as expected, but it also appears to be duplicated in the TMP directory on the server's disk. This duplication was not happening before the new volume was added. Hence, my hypothesis is that there might be a configuration that wasn't fully adjusted to accommodate the new volume, causing files to be stored in both locations. I'm not entirely sure how the backend works, so these are just observations and hypotheses based on my use of Cloudron.

Building on this, this would be a great feature and eliminate a lot of manual work. We typically place a security.txt file in each site, but the ability to just deploy this would be great and configure via the .well-known configuration. I could be wrong, but could this be done at the "platform" level or would it have to be in each package? For example, pretty easy in the WordPress Developer Package, where we just create the folder, drop the file, and add a .htaccess redirect for domain.tld/security.txt to domain.tld/.well-known/security.txt.

If you want some CI/CD inspiration with GitLab + static asset hosting, you can look at our docs repo. It builds using mkdocs and then pushes the build to surfer . See https://git.cloudron.io/cloudron/docs/-/blob/master/.gitlab-ci.yml?ref_type=heads . The build server is a separate VM running gitlab runner (but only costs around 5 a month).

It is as @humptydumpty said. Cloudron 8 (not yet released) has IPv6 only support.

@girish got it, thanks

@girish Confirming that the issue was unrelated. It was very helpful to be able to manually refresh certificates and then view the log files. Thanks!

@Ritesh yeah, I would disable it. It's not required for a Cloudron install.

@overholt said in Linode - upgrade Cloudron to Ubuntu 22.04 & NextCloud 28/29: It looks like Akamai/Linode does support 22.04 now We weren't aware that Linode was providing Cloudron via their Marketplace. Great to hear

@girish Thank you very much !

@nebulon @girish and @nebulon I know you two are so busy and so I apologise for not following up on this. I eventually was able to resolve this matter, though how remains a bit of a mystery but I think I just had to wait for the state to reset on its own. Anywho, sorry for not getting back to you on this.

@girish Well, it wasn't exactly a problem. I was just asking an important question, and wanted a confirmation that I guessed the right answer.

@subven I've had issues with Contabo before (slow disk speeds, network issues, etc) but it wasn't this bad and contacting support got me nowhere. I'm definitely not getting what I'm paying for, so I'm spending the day reading up on server resources and comparing that to my actual usage. I'm debating which Hetzner plan(s) to get: one beefy or two small VPS' shared or dedicated vCPU whether to self-host internal-use apps on-premise at work This whole project has been on hold waiting on CR 8 (multiserver support) and how that's going to work out. It doesn't look like I can delay this any longer though if daily backups keep failing. I ran into this blog post which seems to suggest I might be overpaying for actual usage: https://runcloud.io/blog/scaling-ram-cpu BTW, my Contabo disk speeds are pathetic. I'm on their NVME plan and it's slower than a standard 2.5" SSD. This is from Cloudron's system info page: [image: 1716833212322-19afd134-7fa2-4990-9e82-2363186dda57-image.png] I dug up some old posts of mine (this and this) about the slow disk speeds and just noticed it's been a year since then. Time sure flies!

@alwi said in Ubuntu-server 24.04: pardon. https://gnulinux.ch/windows-11-produktschluessel Um, that's irrelevant, the correct link was https://gnulinux.ch/cloudron-1-einfuehrung

@girish Absolutely! No problem, I'll shoot you guys an email at that address. Thank you!

Yes, that’s a build-in docker command that you can run in your ssh terminal

Setup script hanged in the earlier cases.

@girish perfect, thanks - appreciate it! I'm almost certain there could be ways to improve those queries, but it's always better to have a failsafe in place

@uwcrbc said in My App domain filter with unused domains / external domain: At the moment, filtering per domain shows the list of domains configured on the Cloudron server regardless whether there is an app using it or not. Right, this is how it works currently. The same is possible for All States / Groups as well. Just because there are no apps to list, the item does not get hidden. This can be confusing or not depending on user expectations. It also does not allow to filter for proxy app'ed "external" domains. In the common case, the proxy URL is an IP address and not a domain. In fact, the thing is a URL and not a domain (so we cannot put it in the filter).