I tried this on an Ubuntu 22.04 virtual machine and it worked properly as expected. I am not sure what the issue is but Windows 11 pro with Windows Subsystem for Linux 2 and Docker version 24.0.6 results in the no such file or directory. I did test other non cloudron related containers with Docker for windows using WSL2 and they worked fine. I also reconfigured docker for windows to use it's own VM hosted on Hyper V, no longer using Windows Subsystem for Linux 2, and it also had the same problem with no such file or directory. I will stick to running the build process from a Ubuntu VM for now and at present it doesn't look like Docker for Windows, however it is configured, is usable for building containers to be run on cloudron.

@timconsidine right, much of the CLI finesse needed to get something running can be snapshotted via the app backup, which when restored just runs without fiddling. So yes, more App happiness on Cloudron.

I have now created a repo for my custom package : https://git.cloudron.io/timconsidine/smsvoip-cloudron/ This packages a "desktop SMS" app which allows you to send/receive SMS on a virtual number (not your phone's number). It is also useful for "fake" registrations for things like WhatsApp etc.

@jadudm I'm looking for a mosquitto Cloudron package and found this topic. Do you have any plans to open-source the package you created?

I cannot believe I'd missed this thread! The last 2 years have been much hectic for me, and me who was finally about to start learning the process of building apps for Cloudron. I'm of course willing to participate and contribute in this in any way. @marcusquinn good suggestion.

@robi I went ahead and created the App request thread: https://forum.cloudron.io/topic/9764/forgejo

So the memory leak indeed seemed to be coming from the frequent health check. I customized the health check path and returned a simple response object, and it seems to do the trick. [image: 1690991598001-131f8985-2dcb-4006-ad8a-887963dea05f-image.png] I still think I have something incorrectly handled somewhere and if the website would have a lot of traffic, the issue would probably resurface. But it's not very likely, so I'll stick to YAGNI. (I'll keep an eye on the stats in any case.) Thanks for the help.

You can check if listen({ host: '0.0.0.0', port: 3000 }) makes it better.

@nebulon Great, thanks for the information. I think having support for headless apps would be a nice feature in the future.

@Kubernetes yes. You can also add the optionalSso flag to indicate that the app can installed without it as well (so an option is provided at install time)

The dockerfile is here . It's nothing special, just lots of packages on base ubuntu. To add to what's been said: our approach is the batteries included approach and it's optimized for developer/sysadmin productivity (as opposed to saving disk space). When we open a web terminal, we want all the common tools across all apps (ping, nc, telnet, tar, node, php, python what have you). The Web terminal and File manager have a bunch of tooling prerequisites - tar, zip, rar, jq, database clients (mysql/postgres/redis/mongo), etc for it work well. Any image will work including multi-stage builds. You have to pay attention to our deployment paradim though - https://docs.cloudron.io/packaging/cheat-sheet/#filesystem . Containers are run on a readonly fs, there is no way around this.

You can look into bookstack-app , pixelfed-app , nextcloud-app for some apps that use redis

I left a note in that issue.

For a while there was a WIP tag but people forgot to use it

@girish Oh, I see. Right, unless you install your own torrent tracker, and use the install base swarm to seed images from your own infrastructure at minimal bandwidth usage. No need for docker hub then!

Problem solved after compiling the source