Key takeaways
The Minimus free catalog is a curated set of free hardened container images: minimal, built from upstream source, rebuilt daily, and grouped so you can quickly check whether the runtimes and data stores your stack depends on are covered. If you have ever scanned a stock public image and watched the findings pile up before writing a line of config, the appeal of a hardened catalog is obvious. The harder question is whether it covers the images you actually run.
That coverage question is what this article answers. Not how to make your first pull, and not what "free" costs you as a model, but the shape of the catalog itself: how big it is, how it's organized, how you find an image, how current those images stay, and where the catalog is heading. A "hardened" image, for the purposes of this piece, is one built from source with only the packages required to run the workload, which is the minimal-image approach the rest of the catalog is built on.
The free catalog is a set of hardened, minimal container images spanning the components most production stacks are built from: web servers, proxies, language runtimes, message brokers, databases, and observability tooling. Each one is built from upstream source and includes only the packages the workload needs to run, which is what makes it "hardened" rather than a repackaged public image.
These are the same images Minimus ships to paying teams, not a stripped-down demo set. Free access runs through Minimus Community, the no-cost tier, and the images you pull there are the production builds, with their signed SBOMs (Software Bills of Materials) attached. The focus of this article is the catalog itself: what images it includes, how they’re organized, and how they stay current over time.
It helps to read the free catalog as four practical groups: infrastructure and ingress, developer runtimes, applications and middleware, and data stores. The grouping is by what each image does in a stack, so you can scan one column and tell whether your architecture is represented before you search for a single name.
The categories matter less than the coverage they reveal. A typical web application leans on all four at once: an nginx front end, a python or node runtime, a kafka or rabbitmq broker between services, and postgres plus redis behind them. The catalog is built to cover that whole line rather than a single tier, which is the practical test of whether a hardened catalog can actually replace your public base images instead of just one or two of them.
The fastest way to judge coverage is to look at named images you already recognize. The table below lists representative images across the four categories, each linking to its page in the catalog so you can check its tags, SBOM, and current vulnerability report directly.
These are recognizable names on purpose. A catalog earns trust by covering the images teams actually run, not by padding a count with obscure ones. Seeing widely used components such as Kafka, Postgres, and Redis alongside current tags, SBOMs, and vulnerability information helps demonstrate that the catalog is designed for real-world workloads rather than niche use cases.
You browse and search the catalog in the Minimus image gallery, which lists every available image by name. Searching for nginx, postgres, or python takes you straight to that image's page, where the available image lines, version tags, and pull command are laid out for a first-time user.
Each image page is built to answer the same three questions: which versions exist, what's inside this build, and how do I pull it. You'll find the production tag alongside a -dev variant that adds a shell and tools for debugging, a ready-to-copy pull command so you don't type the registry path by hand, and the signed SBOM plus current vulnerability report for that version.
Pulling is deliberately ordinary. The registry lives at reg.mini.dev, and a single docker pull reg.mini.dev/<image>:<tag> fetches the image with no account, token, or credit card in the way; the step-by-step first pull is covered in the getting-started guide. Qualified open source maintainers can also apply for expanded access through the Minimus Open Source Program, which grants free hardened images to eligible projects.
Images are rebuilt daily from source and again whenever an upstream dependency changes, so the digest you pull reflects current packages rather than a months-old snapshot. This cadence applies to the free images, not just paid ones; the rebuild is a property of how Minimus produces the catalog, in a SLSA-aligned pipeline that monitors upstream projects and rebuilds when their sources move.
Freshness is one of the hardest things to evaluate in a container catalog. Coverage alone tells you little about whether images were built last week or last year. Daily rebuilds are what keep the catalog's hardened property true over time: a minimal image that never gets rebuilt slowly accumulates the same known issues as any other stale base.
What this cadence does not change is the host-versus-image boundary. Rebuilding an image keeps the image current; it does not patch the nodes it runs on or the workloads already deployed from an older digest. To benefit from a rebuild, you re-pull and redeploy, which is why pinning and an update habit matter as much as the cadence itself. The Minimus platform overview covers how the build and update machinery fits together end to end.
After you pull, three artifacts let you track what you're running: the image line and version tag, the content digest, and the changelog for that image. An image line such as 1.29 tracks the latest patch within a minor release, while a digest pins you to one exact build, which is what you want in a Dockerfile or compose file for reproducibility.
Each rebuild is documented rather than silent. Minimus publishes detailed changelogs that go beyond version tags, so you can see which packages moved and which fixes landed between one daily build and the next, instead of guessing from a tag that didn't change. Paired with the signed SBOM attached to every version, that gives you a per-digest record of exactly what's inside.
This is where a catalog stops being a static gallery and starts behaving like a maintained supply of images. You can pin a digest for reproducibility, watch the changelog to decide when a rebuild is worth re-pulling for, and verify the SBOM for any version. The versioning and tags documentation covers how image lines, tags, and digests relate, and how to pin them in practice.
The catalog grows continuously, with new image lines added as Minimus onboards upstream projects and as teams request coverage for the stacks they run. Growth is demand-driven rather than a fixed release list: the images that get added are the ones real users need, which is why the catalog already reaches well past classic web and database components.
That direction is visible in what's already there. Alongside the familiar runtimes and data stores, the catalog now includes AI and data-pipeline images such as Ollama, NVIDIA CUDA, Weaviate, and Airflow, reflecting where containerized workloads are actually heading. The same hardened, source-built, daily-rebuilt treatment applies to a vector database or a GPU runtime as to nginx.
If an image your stack depends on isn't in the catalog yet, that gap is the most useful thing you can report, since requests are part of how the inventory expands. The practical takeaway for evaluating coverage today: check the named images your architecture relies on against the Minimus image gallery, note what's missing, and treat the daily-rebuild cadence and per-version changelogs as the signal that the catalog is actively maintained rather than parked.
Yes. The images available through Minimus Community are production builds rather than a separate demo catalog. Teams can standardize on the same image lines across development, testing, and production environments while maintaining consistency across environments.
An image tag points to a version, while a digest identifies one exact build. Tags are useful for tracking updates within a release line, whereas digests are typically used when reproducibility is important because they guarantee the same image contents every time.
The catalog continues to expand as Minimus adds support for new upstream projects and technologies. If a required image is not currently available, that gap can help guide future additions to the catalog.
No. A hardened image reduces risk by minimizing packages, reducing attack surface, and improving software supply chain visibility, but application security still depends on factors such as application code, secrets management, runtime configuration, and access controls.
Look for indicators such as rebuild cadence, signed SBOMs, vulnerability reporting, version history, and changelogs. Together, these provide visibility into how current an image is and what has changed between releases.
.svg)
.svg)
.svg)
.svg)
