One of the features customers consistently tell us they value in Minimus is our detailed changelog. It provides a clear, auditable view of every change made to an image, across every version we publish.
Before looking at how it works, it’s worth understanding why this matters in real environments.
In a large organisation, it’s common to consume hundreds of base images. Each of those images may exist in multiple variants and versions, all of which need to be understood, governed, and trusted.
Take Python as a simple example.
You may be running applications across multiple Python versions such as 3.10, 3.11, 3.12, 3.13, 3.14, and beyond as new releases are introduced. For each supported Python version, Minimus builds and maintains a minimal, distroless image designed to include only what is needed to make the image functional.
That approach dramatically reduces the number of components in the image, which in turn reduces the potential surface for change (and, of course, attack). However, change still happens, and it needs to be visible and explainable.
Changes to a Minimus image typically fall into a small number of categories:
When this happens, we rebuild from source, verify provenance, run our testing pipeline, rebuild to compliance standards, and publish a new image. The detailed changelog captures this process in a way that is explicit and reviewable.
For every image version, you can see exactly what changed. That includes:
This allows teams to make informed decisions rather than guessing what is inside an image update.
Every single build that is generated is tagged with the versions of the application as well as the detailed timestamp of the change. You could also easily tie changes to the image digest. That means you can:
For teams integrating images into CI/CD pipelines, this is critical. Some teams may choose to automatically consume vulnerability-only updates, while others may require human review for package changes. The detailed changelog supports both approaches.
The detailed changelog does not exist in isolation. It complements other Minimus features to form a complete workflow:
Together, this means you can track changes, be notified as soon as they happen, and choose how automated or manual your response should be. The changelog provides the depth, while advisories and actions provide the signal and the automation.
Ultimately, our detailed changelog exists to support how teams actually operate. You get clear, published change data. You can audit it, automate against it, or simply use it to build confidence in what you are deploying.
If you would like to see the detailed changelog in action, or understand how it fits into your existing workflows, we would be happy to walk you through it. Get started with Minimus to see detailed changelogs in your image builds.
.svg)
.svg)
.svg)
.svg)
