Skip to main content

​
Distroless explained

Distroless container images are minimal container images without a traditional Linux distribution such as Alpine, Red Hat UBI, Debian, Ubuntu, and Fedora. Distroless images are greatly slimmed down so they contain only the essential runtime dependencies required for an application to run and exclude package managers, shells, and debugging tools.

​
Faster pace of release

Since Minimus images are built directly from source, they are not dependent on a third-party operating system like Alpine or Debian. As a result, Minimus is able to release the updated packages within hours of the change in the upstream code and build images with the updated packages on a daily basis.

​
Reduced attack surface

Container images built on traditional Linux distributions carry significant security and operational overhead. They include package managers, shells, and numerous other utilities that expand the attack surface and increase image size. By removing everything except the runtime requirements and direct dependencies, distroless container images drastically reduce their package count and thereby their attack surface. Without shells, package managers, or development utilities, distroless images provide a minimal, hardened foundation for production workloads that align with security best practices: the less code in your production image, the fewer vulnerabilities now and in the foreseeable future.

​
The Minimus distroless solution

​
The challenge: building without traditional tools

The primary challenge when adopting distroless images is the build process itself. Traditional Dockerfiles rely on distribution package managers like apt-get, yum, or dnf to install dependencies during image construction. A pure distroless image cannot accommodate these commands, creating a migration barrier.

​
The Minimus solution: production & dev image pairs

The packages necessary to build an app often differ from the packages necessary to run the app. This understanding led Minimus to solve the distroless challenge through the complementary image pair strategy. Every Minimus image version comes in two variants: a production image and a dev image. The production image is lean and distroless, containing only runtime essentials. The dev variant includes development tools, a shell, and a package manager and anything else needed to build and test applications using familiar workflows. Learn more about Minimus dev images

​
Migrating to distroless images with Minimus

​
Phase 1: Using multi-stage builds

You can instantly benefit from Minimus distroless images while still maintaining your existing build processes by adopting mutli-stage builds and leveraging Minimus production-dev image pairs. In a multi-stage Dockerfile, you use the dev image (for example., dotnet-sdk:latest-dev) for the build stage which requires a package manager and development tools. Then you copy your artifacts and use the production image for the final runtime stage (for example., dotnet-sdk:latest). See multi-stage build tutorials for go This approach will allow you to maintain your existing build processes. You can continue using apt-get, curl, and other familiar commands in your build stages, while your final image remains minimal and secure.

​
Phase 2: Customizing private images

Once comfortable with Minimus images, you can move security forward with the Minimus Image Creator. Instead of installing packages at build time, you can pre-configure your private image with exactly what you need. This simplifies Dockerfiles, reduces build complexity, and further optimizes your container security posture. The Creator tool enables you to customize Minimus images to meet your application requirements by adding specific packages, defining custom environment variables and more. Private images built with Creator are actively maintained by Minimus just like any standard Minimus image, including daily updates, continuous vulnerability scanning, compliance reports, signatures, and a complete SBOM (Software Bill of Materials) report.

​
What’s included in a distroless image?

Minimus production image, like any distroless image, contains only the essentials to run:
  • The application binary and its required dependencies
  • Core runtime libraries (e.g., glibc)
  • Certificates (for TLS)
  • Language runtimes, if required (e.g., Python, Java, Node.js)
Since the fully distroless image is often too slim to work with during development, every Minimus production image has a complementary dev image variant that includes required developer tools, such as a package manager, shell, etc.

​
Package count comparisons

The SBOM of Minimus production images will (almost) always show a drastic reduction in the number of packages compared to the equivalent Ubuntu, Debian, and even Alpine image.
Image TypeTypical Package Count
Ubuntu-based image~200–400+ packages
Alpine image~50–100 packages
Minimus production image~10–30 packages
Minimus production images are that much slimmer because they exclude the following:
  • Shells (/bin/sh, bash)
  • Package managers (apt, apk, yum)
  • Core utilities (ls, cat, cp, etc.)
  • Compilers and interpreters (unless essential for the application)
  • System services or init systems
Minimus dev images will include these tools to allow users to keep their workflows and leverage multi-stage build techniques to produce more secure apps. Multi-stage builds with Minimus

​
Example

The nginx image is an interesting case in point. The standard image on Docker Hub has over 240 packages. The Minimus nginx image has 15 packages. That’s well over a 90% reduction in the number of packages. The SBOM for the nginx latest image shows the packages in the image include nginx-{version} and associated packages, ca-certificates-bundle, the core runtime library glibc and associated packages, and zlib for compression.