Alternative lightweight base image

[timconsidine]

I’ve published a small "swap-in" alternative to cloudron/base:5.1 for packaging small utility apps:

Docker Hub : tcmbp132021/cloudron-minibase:0.0.1

Base image is only 50Mb !!
Apps built with it can be only 200-500Mb.
AppsMonitor, just published as Community App, is only 307Mb.
That compares to 2.5Gb and counting for official full base image packages.

Usage (basically same as a regular Cloudron Dockerfile) :
FROM tcmbp132021/cloudron-minibase:0.0.1@sha256:a9c29ddb555b1a33f1e5b3b70c512e3a799cc691770d5016c70e0195e74764e0

NOTE : This is not about app runtime performance. The large official base image is usually fine there because Docker layer sharing helps a lot. Apps built with cloudron-minibase use mostly the same runtime memory as if they were built with official base image.

For me, the main issue has been build time and image transfer time.
AppsMonitor, using cloudron-minibase, took 43s for entire build script, start to finish, including building and pushing to container repo.

cloudron-minibase is a stripped-down Cloudron-compatible base image with just the basics (it's not alpine or whatever):

• bash
• gosu
• nano
• locale support
• CA certs
• common shell/debug tools

It leaves out the big bundled pieces like:

• Node
• Python
• PHP
• Java
• nginx
• Apache
• DB clients
• supervisor

Need any of the excluded pieces ? Just install them.
The app packager pulls into their app only the runtime components the app actually actually needs.

cloudron-minibase is built from the official cloudron/base:5.1 image, just removing what is not essential.

Main benefits:

• smaller pulls
• smaller pushes
• faster rebuild cycles
• less unused stuff in app images
• nice fit for simple apps or static binaries

If anyone finds this useful, I can share more details or refine it further.

[girish]

Great initiative @timconsidine . I am quite open to this approach. In fact, I already remove PHP in 5.1 base image (it's an image of it's own called php-base). Node is also on it's way out, this is why it's not in the PATH anymore. Each app package is now explicitly opting in to node.

Locally, my cloudron/base:5.1.0 is 2.42GB! It's insane you got this down to 50Mb . If you can share your Dockerfile, I will incorporate your changes into the base image, if that's ok with you

[timconsidine]

@girish thank you.

And thanks for not reacting with horror at the approach !

It feels too good to be true but I just asked my AI to check it, and it says 50Mb also.

`tcmbp132021/cloudron-minibase:0.0.1@sha256:a9c29ddb555b1a33f1e5b3b70c512e3a799cc691770d5016c70e0195e74764e0` is a **manifest list**, not a single image.

For its actual `linux/amd64` image on Docker Hub:
- child manifest: `sha256:85b5d851685962eecb7acfe3adaa77907b023fbe81f09cfc29a722eb03f6c952`
- compressed layers total: `52,223,700` bytes
- with config: `52,227,752` bytes
- size: **49.8 MB**

So the practical answer is: **about 50 MB on Docker Hub**.

My repo is at https://forgejo.tcjc.uk/cca/cloudron-minibase.git.
Sure, please take whatever you want.
There's a MIT licence on it.

Hope you don't find any 'gotchas' !

I thought about producing a series of common deployments :

• cloudron-minibase+node
• cloudron-minibase+python
  -etc.

That's more in keeping with a 'batteries-included' philosophy. But I wanted to run it for a while and discover issues. AppsMonitor seems to running fine after a couple of days.

[timconsidine]

@girish just to clarify
I said 'MIT licence added' but that was just to fill the blanks in my repo.
You're welcome to take /change anything, no attribution needed.

[girish]

@timconsidine thanks. I will have to investigate package by package in our base image what is bloating up the base image. I think with AI this can be done much faster, I will get back with results in a week or so.

[james]

@girish we will have to keep in mind that some start.sh scripts might depend on e.g.: python to do some logic for starting the app.
But AI should be able to figure it out.

[timconsidine]

@girish no rush
entirely at your pace/ schedule - you have many other projects

just building a fairly meaty web app (personal use, may become a Community App if it works out)
cloudron-minibase + python + app code + bundled EverOS : 1.16Gb
dev build/push/pull all faster

[robi]

The question is what the experience is like in the terminal.

On the other hand a Python based app doesn't need to include the entire base image, only the needed parts, but that means specifying all the parts in the Docker file.

So how many base images do we need in parts to keep all the apps happy?

[timconsidine]

@robi said:

The question is what the experience is like in the terminal.

in an app packaged with cloudron-minibase ?
as far as I can tell, it is the same as with cloudron/base.

[robi]

@timconsidine as in all the troubleshooting commands still exist?

[timconsidine]

@robi honestly, I haven't explicitly tested that dimension as the minibase was a test, with those questions to be answered through actually using it.

But at the end of the day, it is simply the official cloudron/base:5.1.0 without node, etc.

I doubt troubleshooting commands would be lost during that process.
And I haven't specifically and deliberately removed any.

[timconsidine]

In the spirit of sharing experience of using cloudron-minibase, I just updated my Community App rybbit.

• 1st update was for latest rybbit upstream using cloudron/base : built app image was 5.29Gb
• 2nd update replaced final multi-stage build with cloudron-minibase + Node : built app image is 2.51Gb.

50% saving in app image size !

[jdaviescoates]

@timconsidine said:

rybbit

https://ca.cloudron.io/app/rybbit could do with a bit more of a description imho (and a working screenshot)

[timconsidine]

@jdaviescoates will get onto it - thanks for the nudge - laziness during publication - sorry.

[timconsidine]

Summary web page for the lightweight alternative, explaining what's in and what's out :
https://communityapps.appx.uk/minibase

Also in preparation for new cloudron base image supporting ubuntu 26.04, moving name convention from cloudron-minibase:0.0.x to tcmbp132021/cloudron-minibase:ubuntu24.04 .

EDIT : minibase has a few extra components, so now 77Mb in size.

[timconsidine]

A neat "trick" for those who are cautious about not building with official base image :

FROM cloudron/base:5.1.0@sha.... AS builder
# Ubuntu 24.04 — full toolchain: Node, Python, nginx, supervisor, etc.
# Build everything here

FROM tcmbp132021/cloudron-minibase:ubuntu24.04@sha.....
# Ubuntu 24.04 — same glibc, same libssl, same everything
COPY --from=builder /what/you/need /where/you/need
CMD ["/app/code/start.sh"]

The built image is in all senses a proper cloudron build in the builder stage.
But the final runtime stage shrinks the image.
There is a level of caution and attention need to ensure that all artefacts are copied in from builder.
But you will soon know if anything is missing.

[girish]

I looked into this a bit . We can't remove so many of the packages. Mostly, it's for sharing between all the packages..

build-essential / gcc / g++, nginx-full, ImageMagick + GraphicsMagick, the whole -dev set (libssl-dev, libpq-dev, jpeg/png/xml, …), mysql/postgres/redis/sqlite/ldap clients, supervisor, git, vim, tini, yq, crudini, are still needed .

I have a new image now which is basically those packages and the hub size is around 300MB. Already something which was 2.3GB. But of course, have to see how this plays out in practice on a cloudron with many apps (because we reduce the sharing).

[timconsidine]

@girish 300Mb is still a world of difference, so I see that as very useful.

As you say, the practical impact may not be huge in practice because of base image layer sharing.

It’s all about build and push/pull times.
And horses for courses. I may have turned tuned aggressively but even your slimmed list has some stuff which may never be used in some apps.

For example a simple go site with data fetched from json, not even SQLite.

[timconsidine]

@girish my last response was typed while waiting in an IKEA queue !
Better quality would be :

Really appreciate your feedback and the effort put into the 300MB 'slim' version, especially when your workload is so heavy with 10.x.x.

I guess the core difference is you are constructing a "platform package" while I was aiming at a "runtime only" image, with the inescapable consequence that the packager adds what they need for that specific app, even if that is more work for them.

For a platform package, your comments make total sense, and of course I defer to your experience and objectives. And 300Mb is a clear win over 2.3Gb with still quite a lot of convenience 'nice to haves' included.

My argument for excluding much of what you mentioned is :

• runtime package doesn't need much of it
• why include mysql and postgres when neither are needed for a specific app
• keeping a lean attack surface ( the less in it, the less that can be abused)
• it is rare that compile stuff is needed at runtime, maybe include that in a multi-stage "builder" stage then omitted in a final "runtime" stage.

For example, a simple Go or Python application that doesn't perform image processing should not be forced to pull ImageMagick or gcc just to run.

My cloudron-minibase does push a lot of responsibility onto the packager.
That may not be popular, but they don't have to use it !
And I totally understand a bit bigger image to meet your goals about platform experience is valuable.

As a test, I updated cloudron-minibase to include :

• tini and supervisor
• libssl-dev and libpq-dev
• yq and crudini
• nginx-full

This gives an image size for cloudron-minibase:0.0.2 of 77Mb.
(FROM tcmbp132021/cloudron-minibase:ubuntu24.04@sha256:ae1e4ab4343f9f9dff05b988db94c8936f8390b8d1e88db80a1ae7afde563aea).

This keeps the base significantly smaller than the 300MB version while providing the tools that 90% of apps actually need at runtime. For the remaining 10% (the ones needing heavy compilation or ImageMagick), the package developer can simply add those specific layers to their own package, build stage or runtime stage. Or simply use your future "cloudron/base-slim" if you decide to release one.

So actually I am totally with (a) following your guidance as to what is best, and (b) using a 300Mb image for simpler packages and (c) continuing to use the full cloudron/base of 2.3Gb where it is justified.

I didn't intend cloudron-minibase to be a disruption or a challenge.
The inital 50Mb was insane, unexpected, and I would still have been happy if it was 300Mb. So no problem at all using a 300Mb base if one becomes available.

[girish]

@timconsidine said:

So actually I am totally with (a) following your guidance as to what is best, and (b) using a 300Mb image for simpler packages and (c) continuing to use the full cloudron/base of 2.3Gb where it is justified.

So the plan is use a new base image which will be 300MB and see how it goes. The dev packages are needed for many of the nodejs and ruby programs unfortunately. But it's a start and we can experiment a bit from here.

Really appreciate your feedback and the effort put into the 300MB 'slim' version, especially when your workload is so heavy with 10.x.x.

This was part of the 10.1 work. It brings a new postgres, dovecot etc. All good stuff