RHEL UBI and Cloud Images: Distroless-Adjacent Server Layers
RHEL's free Universal Base Images give containers a signed, glibc-compatible runtime down to a few megabytes, with UBI micro at the distroless edge.
Netbay Engineering
Netbay Engineering
On this page
For years the base of a container image has been a distribution decision, and Red Hat's answer is the Universal Base Image: RHEL-aligned container layers that any developer can download and use without a subscription. UBI is the admission that for most software, the operating system inside a container only needs to be a set of compatible glibc and userland pieces. UBI micro takes that to the logical endpoint, images of only a few megabytes, distroless in all but name, and built with the microdnf package manager. Paired with the same release's cloud image, the two give you one consistent family from full VPS to minimal container.
What UBI Actually Is
UBI images ship for RHEL 8, 9, and 10 in four tiers: base, minimal, micro, and init. All are built from official Red Hat sources, carry the same package tooling as their RHEL release, and are freely redistributable, with no subscription or login required to pull them. Distroless-adjacent is the accurate label for the micro tier: a shell, a package manager, and a full glibc, but almost nothing else, and deliberately no init system to run multiple processes.
ubi-micro in a Dockerfile
The micro image exists so you can compose your own minimal runtime. A runnable pattern is to start from micro, install the application packages with microdnf, and let the container handle the rest.
FROM registry.access.redhat.com/ubi9/ubi-micro:9.5
RUN microdnf install -y nginx && microdnf clean all
COPY nginx.conf /etc/nginx/conf.d/site.conf
EXPOSE 80
CMD ["/usr/sbin/nginx", "-g", "daemon off;"]microdnf is the small sibling of dnf with a deliberately reduced feature set: it handles install, remove, upgrade, and clean, which is exactly the surface a builder needs.
Composing Content Into the Micro Image
When the packages you need are not present in the micro layer, the standard technique is a multi-stage build: resolve them in the richer UBI base, then copy only the resulting filesystem into the micro image. This keeps the running artifact small and free of a package manager at runtime.
FROM registry.access.redhat.com/ubi9/ubi:9.5 AS builder
RUN dnf install -y --nodocs redis-server && dnf clean all
FROM registry.access.redhat.com/ubi9/ubi-micro:9.5
COPY --from=builder /usr /usr
COPY --from=builder /etc /etc
ENTRYPOINT ["/usr/bin/redis-server", "--bind", "0.0.0.0", "--port", "6379"]The Cloud-Image Twin
The server-side partner of UBI is the same release's cloud image: full package set, systemd, a kernel, intended to run as the whole machine. UBI gives the container layer of that same family, which is more useful than it sounds. One source of truth for package versions, one patching cadence, and one set of tools from a full VPS down to a scratch-sized container makes the mental model simpler and the playbooks reusable.
skopeo inspect docker://registry.access.redhat.com/ubi9/ubi-micro:9.5 | jq '.Layers[].size'The worked example above shows the inspection habit worth keeping: measure the container you ship, because the difference between a distro-shaped base and a micro base shows up in the layer list long before it shows up in the app.
Takeaway
UBI is the honest middle ground: a free, signed, RHEL-compatible runtime for containers, from the same source as the full cloud image, down to a multi-megabyte micro tier. Distroless gets you tiny; UBI gets you tiny with a familiar package manager and a supportable identity.
Pair a Netbay Linux VPS, deployed in under 60 seconds, with UBI-based application images and you have the same family from host to runtime — netbayhosts.in.
Keep reading
Follow along on a real VPS
Deploy Linux in under 60 seconds
These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.
Deploy an instance