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 likeapt-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 imagesGeneral process adjustments
Adopting the Minimus solution can help you drastically improve your security posture. The distroless approach also involves the following practices:- Moving out dev libraries from the production image. Learn more
- Separating the build stage from the runtime final build using multi-stage builds. Learn more
- Escalating privileges temporarily in the Dockerfile build stage to compensate for the non-root default user. Learn more
- Using Python virtual environments (venv) and other similar options. See example
- Switching to sidecar debugging tools so the production image doesn’t always include the extra packages. Learn more
Migrating to distroless images with Minimus
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 thedev 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.
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. Image Creator 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 the Image 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.Building off static
If you are used to building an image from scratch by pulling a starter base image from Alpine or another distribution on Docker Hub and adding your own packages, Minimus Creator offers an optimal solution. Here’s how it works: If you are starting from a language framework, you can select the relevant image as your starter image, whether it is Ruby, Golang, etc. Otherwise, you can build off of Static, Glibc-Dynamic, Glibc-Dynamic-FIPS or another base image from the Minimus gallery. As the next stage, you can add any number of packages as suits your needs. The package selector offers every package available from the MinimOS distro, including FIPS alternatives. You can build anything you set your mind to. The Minimus build pipelines take care of building the image and maintaining and updating it daily, and will alert you of any conflicts or other issues if encountered. Building your private distroless image from scratch is truly effortless with Minimus Creator. As an added benefit, Creator also supports bundling certificate files and custom configuration files, and managing environment variables as part of the build. Minimus Creator outputs a single-layer image which has the advantage of being smaller and faster to pull than an image built with Dockerfile.Experimenting with direct package access
If you prefer, you can install Minimus packages directly using a package manager with Minimus images. This might be useful for testing out different options before building a private image with Creator. Package access allows you to add Minimus packages directly in your Dockerfile. With direct package access, you’ll be responsible for rebuilding when packages are updated to fix CVEs. Image Creator automates this process, which is why it’s recommended. Package access is not enabled by default but is available upon request. Learn moreWhat’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)
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 Type | Typical Package Count |
|---|---|
| Ubuntu-based image | ~200–400+ packages |
| Alpine image | ~50–100 packages |
| Minimus production image | ~10–30 packages |
- 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
nginx 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 includenginx-{version} and associated packages, ca-certificates-bundle, the core runtime library glibc and associated packages, and zlib for compression.