- Core Utilities: bash, curl, wget, tar, gzip, unzip, jq, rsync, sed, gawk, grep, findutils, coreutils, less, procps, iproute2, net-tools, iputils-ping, sudo.
- Process Management: tini (for proper PID 1 signal handling) and supervisor (for managing multiple processes).
- Configuration Tools: yq and crudini.
- Web & Networking: nginx-full.
- Development Libraries: libssl-dev, libpq-dev (for secure communication and database connectivity).
- System Essentials: gosu, ca-certificates, locales, tzdata
- Ubuntu 26.04

cloudron-minibase : lightweight alternative Cloudron-compatible base image
A 165mb base image for packaging apps that do not need the full runtime stack bundled into cloudron/base (approx 1Gb), built from the official image without language components and tools.
FROM tcmbp132021/cloudron-minibase:ubuntu26.04@sha256:6d673e95c70769042376f0681b82076775463b67417475733ae0f18ba842cb56
---
This is the published linux/amd64 image digest to pin in Dockerfile FROM.
Why use this instead of the official cloudron/base?
The official cloudron/base is still the easiest choice when you want a lot of runtimes and tools ready to go. This image is for a different tradeoff.
The main reason to use cloudron-minibase is not runtime performance. Docker layer sharing means the large official base image often has little impact once layers are already present on the server.
The advantage here is around build time, pull/push time, and keeping app images simpler when they only need one specific runtime.
Additionally the attack surface is much smaller, so less CVs, because the inherited toolchain is much smaller.
What is In / Out
- Build Tools: build-essential, gcc, g++. Rationale: These are for compilation, not execution. Developers should use Multi-Stage builds to compile dependencies and only ship the final binaries/artifacts.
- Media Processing: ImageMagick, GraphicsMagick. Rationale: These are massive libraries. They should only be included if the specific application requires them to avoid unnecessary bloat.
- Version Control: git. Rationale: Not required for production runtime.
- Text Editors: vim. Rationale: For security and to minimize the attack surface.
When to use
- your app only needs one specific runtime
- you want faster builds and smaller image pulls/pushes
- you want a tighter dependency surface
- you prefer each Dockerfile to declare its own runtime explicitly
- you want maximum convenience with runtimes and tools ready to go
- you expect to use the bundled runtimes (Node.js, Python, PHP, Ruby, Go, Java)
- you need nginx, Apache, supervisor, or database CLI clients
- build time and image simplicity are not primary concerns
Typical Use
Start from the pinned base image, then install your app runtime yourself.
FROM tcmbp132021/cloudron-minibase:ubuntu26.04@ssha256:6d673e95c70769042376f0681b82076775463b67417475733ae0f18ba842cb56
RUN apt-get update && apt-get install -y --no-install-recommends \
python3 \
python3-pip \
&& rm -rf /var/lib/apt/lists/*
WORKDIR /app/code
COPY . .
COPY start.sh /app/code/start.sh
RUN chmod +x /app/code/start.sh
CMD ["/app/code/start.sh"]
Cloudron platform features still work as usual: reverse proxying, TLS, health checks, backups of /app/data, addon credentials, and the web terminal.