Cloudron Forum

Thanks for the explanation.

@nebulon said in Exec/debug - Is it possible to use a shell other than bash?:

Since stock unix tools like du are not working well with the virtualized layered filesystems docker uses, you have to use docker tooling like docker system df to get the real size for those.

Initially I've tried docker system df but this command is so expensive (https://github.com/moby/moby/issues/31719 / https://github.com/moby/moby/pull/31973 / https://github.com/moby/moby/issues/31951) I was just switching to df and du instead to save time.

After 10 minutes of patience, the command finally returns:

~# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          28        27        14.65GB   2.21GB (15%)
Containers      44        29        0B        0B
Local Volumes   58        58        3.253GB   0B (0%)
Build Cache     0         0         0B        0B

As it show different information than df and du, I'm still unsure what information is about to be taken into account for considering disk full. It's all good in the table above, but will the os really be smart enough to read 15GB instead of 80GB?

If I understand you right, having the cloudron base image would reduce the total disk space used by all my docker images running on cloudron?
Because right now I'm observing the opposite with what I have checked using du and docker images, where each docker image takes on average 3GB and the total of docker images is 80GB on disk.
Based on your explanation, sharing the base image (2.2GB in size) would also save around 60GB disk space for my 28/29 images. Or maybe something is not right in my understanding.
Yet having a base image 50MB in size for a small app makes more sense to my taste than having a base image as big as 2+GB?
What do you think @nebulon ?

I'm not 100% sure about that, I mean the total of ubuntu base images on my instance is around 80GB, each image from the app store takes between 2 and 4GB. Next to those, my alpine image is less than 100MB. Yet I find that 100MB is still way too big, I can likely reduce that.

And based on docker images listing and du, each image seems to really take an average 2.9GB.

~# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
tmpfs                                                   1.6G  3.3M  1.6G   1% /run
/dev/sda3                                               588G   77G  482G  14% /
tmpfs                                                   7.9G     0  7.9G   0% /dev/shm
tmpfs                                                   5.0M     0  5.0M   0% /run/lock
/dev/sda2                                               2.0G  170M  1.7G  10% /boot
u426552@u426552.your-storagebox.de:/home/storage/music  1.0T   63G  962G   7% /mnt/volumes/8c4c2f7f0e8a44e090fc857a64b1f316
u426552@u426552.your-storagebox.de:/home                1.0T   63G  962G   7% /mnt/cloudronbackup
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/941561b6b216ede950e95d525f676defe98425be86c02edd6737e95e848d3487/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/a47d7cd82e5ba37dc642d53159323dd0be0e080d0c59f44656ff39e86fd8077f/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/84c4252012d0d027e49529377605b19cdde5385594120b9215ec8f4b601997f1/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/e4fd2d9876ba48aa5b1a3890192af605268b1b06914f074cd51538e5cd8e732e/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/4186641821aa776be6f3453c44e5f6999dfd62ecea985da3b799034ac42c4805/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/e5f5b26adf7f4c491b7e00976b47eafd6e11211d0b9cd87232636495ac0fa69c/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/2128a944d0c3beea65ecf91c51172fd22877df72bda73a0b69019d575472e9b9/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/e8f3a7b55229fe43505b9c71a78887dd80a514e2dfde620d561b7e63295451c3/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/ca7099594dd0c471f3ee269f64c04c57784b6ac97d42a1ccea7e5c23f45adfcf/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/32ba3a826dc24b5096484b1a18f4e0fd4b490f8d0f8ee8dbcbfd0ef024683340/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/06f378a7b62b5c9385871a9cdf43d8cdfe100dc563f398c99a5a4aa0ff923de1/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/65d95b78cba9b8a6dbfa86dc8f87646ede5af06e197ff6b9e1208dfaf7bbc9c5/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/2be16e71c52c9d9028e5ae2ddafa21afe897006148999bc20e1c041cc2afd16c/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/3af0a5bce6cc8b11c29471214209ea182602078d062d05d098a8872eabc40429/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/7a0800829a76a92d356ff710b3882c3f12612d376d3797d7676f044e9ad62214/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/b15f684ada5eb3ef784fcedf484738c56a051c47597ad20da548f46a937fe571/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/3da17d53de6c6daa5898d644eb74c1e2099a1a192ccfb0ed827911a23980bde1/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/a37ad3291da4944e667e16342124417d1ac66370c87ad7e8278979ab42c71c8e/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/792eecae61fcc06c5bf9ed01839c2a6c5b41e097efb3aa1cd529b7ad441a9392/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/68bf9a6faa884822bf107ae36daa4fdec7a090281370cbfbc49bffe4b7a5bd0d/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/c8fb2e965fa85ce289436eb96e56584a06765cade5f2cd7d43f77b930fefb928/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/992c00fe84e55e8aa06eafa32ccac9251ce194af33082a711ea6ef7812818285/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/704413a277d07d199ae7801cd9c812ec9db6f61870582468ad0c34c855924af5/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/13e0b0ac613a3bb2769e75def0d88c476399849faf55b0b54a44c11ffd693040/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/2afe0cb63975cfb247549d41319f40d1b2eab5ece8645fccbb999715da1472d2/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/e159b65ba533df6c3df4d9b6b5c4ebbbb53c337e9cf882e6b104072f535826fa/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/19aa6f3f67da9f897ca14b16f3dd58e776481c8f88a7df6147f6b9d0c3dc5229/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/c1867646b12beaad46d3332f566dd9ef3acccc39f459dd93259679965ab0b2ce/merged
overlay                                                 588G   77G  482G  14% /var/lib/docker/overlay2/1863229ae55deed6b180bcb7086b166041bcf84caf862dc7162eb1f4cb0cdadb/merged
tmpfs                                                   1.6G     0  1.6G   0% /run/user/0

root@vmi1545666:~# docker images
REPOSITORY                                TAG                         IMAGE ID       CREATED         SIZE
cloudron/org.navidrome.cloudronapp        202412221800040000          955f3ed8bda9   29 hours ago    2.26GB
<REDACTED_MY_APP_REF>                     1.0.9                       342c00f06dd1   41 hours ago    95.5MB
cloudron/app.miniflux.cloudronapp         202412202203500000          3ab5b7255d6f   3 days ago      2.23GB
cloudron/com.invoiceninja.cloudronapp2    202412201425110000          114bf2ee41e6   3 days ago      4.32GB
cloudron/com.github.bitwardenrs           202412201132130000          b07e9c5ab7d5   3 days ago      3.55GB
cloudron/calibreweb.janeczku.github       202412200520170000          c4c0b840c65a   3 days ago      3.49GB
cloudron/lamp.cloudronapp.php74           202412180703290000          35ef2ed19d95   5 days ago      2.64GB
cloudron/io.changedetection.cloudronapp   202412170520280000          5d612c3fbb5c   6 days ago      3.99GB
cloudron/io.gitea.cloudronapp             202412131720400000          fec9c8c07eca   10 days ago     2.8GB
cloudron/com.github.shaarli               202412081824370000          f174ed03ee2d   2 weeks ago     2.23GB
cloudron/net.syncthing.cloudronapp2       202412031651540000          c7a0a056a716   2 weeks ago     2.24GB
cloudron/org.wordpress.cloudronapp        202411220220380000          f04002c311c5   4 weeks ago     2.37GB
cloudron/info.privatebin.cloudronapp      202411161255100000          c3b260ef0b6d   5 weeks ago     2.21GB
cloudron/org.getgrav.cloudronapp          202410281158520000          d52bf6ab8b2b   8 weeks ago     2.29GB
cloudron/tech.ittools.cloudron            20241022-105954-145356468   387ecffe94e3   2 months ago    2.22GB
registry.docker.com/cloudron/redis        3.5.4                       edcfcc0608c6   2 months ago    2.22GB
registry.docker.com/cloudron/sftp         3.8.9                       c595fcbbe0a3   4 months ago    2.23GB
registry.docker.com/cloudron/postgresql   5.2.3                       c0270fdfd54f   5 months ago    2.75GB
registry.docker.com/cloudron/mysql        3.4.3                       f1c143716f42   5 months ago    2.53GB
registry.docker.com/cloudron/mail         3.13.1                      ac386518998a   6 months ago    2.89GB
cloudron/sh.ntfy.cloudronapp              20240514-072708-5696fd1ad   2a1124f439c9   7 months ago    2.26GB
registry.docker.com/cloudron/mongodb      6.0.0                       4b95d24318a2   10 months ago   2.69GB
cloudron/com.docker.registry              20240208-085138-349b78ba6   68797f159e9f   10 months ago   2.24GB
cloudron/com.rssbridgeapp.cloudronapp     20240203-090049-661e61c5a   6990eceaa76a   10 months ago   2.21GB
cloudron/org.yourls.cloudronapp           20231024-061626-421eac647   e89d47b182e4   14 months ago   2.22GB
registry.docker.com/cloudron/graphite     3.4.3                       dbd026164ada   14 months ago   2.28GB
registry.docker.com/cloudron/turn         1.7.2                       152b1fb9690e   15 months ago   2.22GB
registry.docker.com/cloudron/base         4.2.0                       6ec7c1ab3983   15 months ago   2.21GB

I'm used to replacing GBs worth of binaries/code and services and thousands-dollars worth SaaS with simple shell scripts and python scripts, it's all fun for me to see how little things can avoid the bloat and costs we are used to with modern software and architecture. We shouldn't need 4GB worth of code to generate a pdf (invoiceninja), I mean it's literally done with 4K worth of python code.
A base image being 2.2GB in size is a red flag for me (at work but not only).
Anyway, I won't start a crusade, this base image solves problems, but I'm not gonna base my minimalist stuff on something 20 times as big as my big Docker image

It would make sense for consistency if starting from base image is a prerequisite to entering the App store but it's just not very obvious in the documentation and so I'm exploring the alternative. I hope this can be made more clear to me here and also in the docs but even so I see that all apps in the app store seem to have those little differences not made very clear in the docs so this thread is also a request for clarification.

@timconsidine good question, it's a matter of avoiding the bloat and extra sugar in general with what I do. Also as I said using the base image could make sense later but at this point I don't need most of what it brings and I follow the YAGNI / KISS ideas. If I can skip something, I take the shortest path to my goal. Depending on a custom cloudron base image makes my app less portable to non-Cloudron worlds and makes my packaging process more fragile. But if the base image would be documented, then I would be able to decide better. It's just a matter of tradeoffs.
I'm developing a minimalist app (no db, no js, no build process...no bloat) and wanted to avoid the base image to be anything more complex than needed. Alpine was the ideal choice and I'd like to stay with it.

Hi,
I've recently succeed packaging my own minimalistic app using alpine as base image.
I didn't had much references to compare to as most of the other packaged apps are using cloudron base image (ubuntu based), however despite the app works well on my own Cloudron instance, I didn't yet made it to the Cloudron "public" app store, so I've only scratched the surface. So I've a few questions

Questions:

1. if targeting Cloudron App store in the future, must app be packaged from the ubuntu base image? As I aim for minimalism in term of dependencies, I'm happy using alpine but the cheatsheet does not make it very clear if alpine is an option or not for App Store.

2. if packaging apps starting from Cloudron base image, what is the most up-to-date base image to start from and where to quickly find this information? it seems most Dockerfile in Cloudron git repos (https://git.cloudron.io/packages) start from a different reference to Cloudron base image, sometimes 5.0 followed by a digest, sometimes 4.2 followed by a digest, this creates confusion as those digests/refs do not make sense to me.
   Examples
   FROM cloudron/base:4.2.0@sha256:46da2fffb36353ef714f97ae8e962bd2c212ca091108d768ba473078319a47f4,
   FROM cloudron/base:5.0.0@sha256:6bec2b5246567ef8b5b13ca0af756e2e596941e440d76b46635211cd84383922

3. The packaging of apps seems at times inconsistent, with similar conventions for the Dockerfile, start.sh, but I can often find differences, sometimes WORKDIR /app/code, sometimes cd /app/code, sometimes we run the app from /app/code, sometimes from /app/pkg/... sometimes we load vars from some env.template, sometimes from env.sh, etc etc.
   it makes comparing those package recipes very difficult, and yet I'm lost in trying to understand what is the best way. Every difference adds more differences to the Dockerfile of course, and makes every package very special and unique why mostly accomplishing the same goal, which is to be compliant to Cloudron platform.

4. I've learned lot more about packaging apps for Cloudron while working on my pythonic app using an alpine flavor, and Cloudron platform does not seem to impose too much constraints in the end, which is good, but as I didn't reach the point of targeting the app store yet, I've likely only scratched the surface? If anyone is willing to share their experience with me, I'm grateful !

Enjoy the end of the year celebrations

Nice, the syntax cloudron exec --app <app> --tty sh works perfectly

Hi,
I've packaged an minimalistic app based on Alpine, and I'm able to package it and make it run on my Cloudron but it seems impossible to debug it unless I install bash addition to the base alpine image.

My attempts to use cloudron exec or cloudron debug have both failed unless bash is present in the image.

Is there a way to run a different shell and then what might I be missing? The source code for box mostly reference bash as a default choice which is totally valid but I just want to know if it's obligatory or not, I couldn't find a clear answer in the source code nor in docs about the packaging requirements.

Thanks!

@plusone-nick said in Focus on Business Apps:

imo the main issue in regards to new apps is the developer experience/on-boarding

Cloudron has had their own "standardized" method for packaging apps for many years now and have basically failed in facilitating a thriving marketplace for Open Source and new custom apps. Way before Supabase, Coolify and others "We"/Cloudron have had: Server/Runtime, Auth, DBs, Backups, DNS & so on readily available with absolutely no streamlined method to build an app using Add-On pieces and simply launch it.
...

And don't get me started with the fact that we still don't have a single "no code/low code" APP/PAGE builder! No lie it makes me lose sleep at night...We can design a UI with Penpot, build databases with several options, build workflows with n8n, do AI stuff with Typebot/Open WebUI but I only have fucking wordpress to build a page!? (excuse my french & no offense WP but really!? it's basically 2025!!)

...

I know, I know before anyone says it! Sounds like a "skill issue" this is all just linux, docker and open standards, languages, protocols so you should know all of this already, its ASSumed that you do...and this is where the problem/current attitude toward "new apps" derives and resides.

...
Don't mistake my passion for hate or anger

TLDR:

1. App/Page Builder
2. Better Docs/Dev Onboarding
3. Compose & Swarm Implementation/Unified Dashboard

I pray this does not continue to fall on deaf ears...Especially since I am willing and able to contribute...
Everyone is here for a mutually beneficial relationship, let's keep that the focus or part ways amicably.

For points 1 and 2, I totally feel you. Anyway there is some hope and I want to share my experience below.

as an experienced developer and devops person, I have to admit it requires some skillset/experience and patience in order to be able to make the effort to package an app. As a busy parent, I had cooked a simple python app, very minimal, and packaged it for alpine, to boost my productivity. Then I wanted to host it on my Cloudron and it was not so easy to make it work, due to permissions issues, various errors (exec format etc), failed healthcheck... Despite having a working Dockerfile and docker-compose.yml in local, it took me 2 weeks of spare time to adapt my app for Cloudron. Mostly because my spare time is very limited and my knowledge of Cloudron packaging is limited too, and also I had a goal to only use ChatGPT.

The base Cloudron image is mostly ubuntu based while I wanted to keep alpine as a base image, and despite this difference I could manage to yet install my app on my Cloudron instance while still keeping it minimal

It took me a few ChatGPT prompts + a few evenings to go over all the issues I faced, yet I succeed! I believe the DevEx is quite horrible at this time, but with patience and help from ChatGPT , and good documentation I'm convinced I could tackle any such challenge as long as the effort is realistic and the app is worth it. The more we cook app, the easier it becomes, and the funnier it is.

I will try to share a bit about this effort soon , so at least people can benefit from the learning. What is interesting, when building your own app, with a minimal setup, is that it is possible to avoid to rely too much on Cloudron "magic" as I don't care at all about the base image, etc.

I had to admit that the information I needed to aggregate for the initial prompt to ChatGPT was huge and sourced from many different parts (docs, git...) and is not an effort everyone is willing to take, so it is worth cooking some ChatGPT app for this I believe.

Anyway the good news is that it is possible to have sort of a recipe to repeat this success, i.e by feeding ChatGPT with examples of Cloudron/Dockerfile/start.sh of similar apps; i.e apps made with similar tech stack; + relevant excerpts from the documentation about packaging apps for Cloudron and Cloudron requirements. And in total it took maybe a few hours of prompting to ChatGPT and git/docker push/cloudron install/update to make the whole thing work.

I hope to build maybe one or two more apps for Cloudron, for my own needs, this time I'll focus on apps I didn't build myself like maybe soulseek and others. Maybe in the end I'll have a good tutorial to help people contribute to Cloudron with sensible apps.

transition could be smoother than I expected it seems, at least based on this thread's comment https://github.com/zadam/trilium/issues/4620#issuecomment-2509921587
Now, I didn't try myself... I was considering to give Trilium a try to replace Obsidian but I'll wait for Trilium Next to be available and stable in Cloudron.

@girish About "app is down", I'm interested in a way to tune "restart automatically" for app being down. It's not the first time I notice an app is down or not responding because it crashed during the night and in the morning I have to manually restart it.
it happened for instance that my wordpress blog was stopped due to high traffic because of being on the frontpage of hacker news... and so was down for several hours... what a pity

oh nice, bringing more fun to Cloudron. I support the idea!

@JLX89 I've tried but I only obtain a json file not a full backup? What am I doing wrong?

I notice the focus becomes stronger on backups, archives and that's for good. despite I did search for this, I couldn't find if it's technically possible or not, so I'm asking here and I'm happy at need to create a separate topic for this, anyway:

• is it possible and planned to download any app backup from Cloudron admin UI without going through the command line?

I bet at some point we save more time as Cloudron users by packaging apps ourselves and documenting the process, maybe improving it via LLM, than waiting for the roadmap

Your post seem to imply we ignore the hard work, but what I think is rather the customers are concerned with staff priorities and worry of the status quo or regression in quality.
There are currently thousands of topics in the wishlist section and no way to see clearly if any will be on the roadmap in the future. If you then compare with how many apps are in the app store it means it would take decades before current wishlist can even partially be addressed.
The staff also mentioned they have more work so cannot deliver interesting apps or apps requiring more complex setup, which raise the natural concern of the customers who see bugs being introduced and dont see more popular apps be included.
So yeah Cloudron has an incredible value but wouldn't be nice to be able for customers to have more influence at least the apps to be picked? Or at least to cleanup the wishlist from the apps that are waiting for too long in the forum to at least not create false hopes.
And as you say packaging Cloudron apps is a challenge but then what is done to simplify this or to call for contributors?
What is done to motivate more customers? Even the referral program was cancelled.
There is of course lot of work around quality and maintenance of apps. This is I believe understood by the customers but yet doesn't invalide the complaints.

I do agree that as a paid customer I feel voting in the forum is a waste of time and also more and more of my questions in various topics are just not answered or the priority/ backlog is not visible to us so it feels like it's going nowhere.
I've seen several topics and complains like this very one but staff gives an impression of being too busy to improve and that's a red flag which becomes very visible to customers, so I Believe more transparency and action is needed or making it more easy for existing customers to contribute more apps and influence the strategy through a serious app voting system.
I stopped suggesting apps to the wishlist because the existing apps in wishlist are waiting for too long without any follow up like nobody from the staff cares anymore. And I want to think I'm wrong.

You know better, so anyway the problem is resolved in the end and that didn't take long, so many thanks!
have a great week-end ahead

Thanks! I've applied the advice immediately.

I notice the impact is partial and sometimes a few dozen or hundred tokens are gone, but lot are left. So it worked in the end but I had to hit the button a few times (7-8?) until reaching 0 and being finally logged out while I would have expected clicking once for all would be enough