To be fair, you will get the same footprint with a multi-stage build and images that depend on the same shared base.
Let say that we will have a CloudronBase (Image LVL1), this image will include only ubuntu + minim software used for debugging.
As a second step you will get different images with all the dependencies for the different cases:
One image for every type of DB: MariaDB, pSQL, MongoDB.
One for the webservers: Nginx, and Apache (that can maybe already include PHP).
Then as the last level (3) of images, we have the language, like: node, python, etc, etc.
This will have the same footprint as the one big image that we have now, it will always be a Cloudron Base, but it will be like:
Yes to slit the image in multiple parts will be a big work, but then we can update all the lvl with less effort.
And as a second bonus, we will be able to have a server with just 2 WordPress, without unused library and software.
To resume, what I propose is to keep the idea of an cloudron base, but to slit it, so that the apps can be developed easily, but servers with 20 GB of storage don't louse 10% of their space for code that they will never use.
@necrevistonnezr click on the command(s) that interest you, that takes you to another page.
On the first one - bat - the install instructions are right at the bottom (lots of scrolling)
Didn't look at the others yet.
@robi very interesting. I use Jitsi (self-hosted elsewhere) and would like to see Jitsi here in AppStore, but I wonder always if a conferencing load on my Cloudron instance will impact performance. Maybe the peer-to-peer would mitigate that.
@robi there is a already bunch of "workarounds" for rsync. Empty directories, executable bit of files cannot be stored in most object storage. So, there is fsmetadata.json file that stores this information outside of the files. When restoring, we use that file to restore back the state. I guess we can extend that file to also save and restore timestamps.
If anyone wants this leave a note and I can look into it in the future.
it's not so easy, you need to compile all the C extensions modules that you are using. For example, are not compatible libraries because there's no way to easily compile them are tensorflow, pytorch.
But in generaly Yes is compatible with all the python code because it's a fork of its default interpreter/compiler CPython.