Minimus Is Shutting Down: What to Look for in Your Next Container Image Provider

Minimus is ending operations. For organizations using its hardened container images, the immediate question is what comes next. But this is also an opportunity to reconsider what you should expect from the software foundation underneath your applications.

Minimus has announced that it is ending operations. Its 60-day maintenance period began on August 24, 2026, covering bug fixes, commercial support, and continued upstream image updates. The Minimus registry is scheduled to shut down on October 22, 2026. Images already pulled will continue to run, but they will no longer receive updates after the shutdown.

For teams running Minimus in production, that creates a migration requirement. It also creates an opportunity to step back and ask a more useful question: What should we expect from the software foundation our applications depend on?

Minimus Solved a Real Problem

For organizations using Minimus, the appeal was straightforward: start with a hardened, minimal image rather than inheriting the vulnerability and attack surface of a conventional public base image.

Its approach included source-built images, continuous rebuilding, near-zero CVE positioning, signed SBOMs, provenance, and a documented SLSA Build Level 3 pipeline. It also offered compliance-oriented capabilities spanning FIPS 140-3, FedRAMP, CIS, NIST SP 800-190, and STIG.

That is worth acknowledging. Minimus was never simply about making images smaller. For organizations using it, the underlying objective was to establish a safer software foundation before an application reaches production.

That need has not gone away. The question for Minimus customers is now where to take that model next.

Don't Just Replace Minimus. Re-evaluate Your Container Foundation.

Several providers now offer hardened, minimal, or source-built container images. Docker Hardened Images, Chainguard, Red Hat UBI Micro, Canonical Chiselled Ubuntu, BellSoft Alpaquita, Iron Bank, Google Distroless, and other approaches are available for organizations evaluating their next container foundation.

These offerings are not interchangeable. Two providers can both offer minimal images, SBOMs, signing, and provenance while taking very different approaches to building, verifying, maintaining, and supporting those artifacts.

So instead of asking, “Which vendor looks most like Minimus?”, ask a more important question:

Which provider gives us the strongest foundation for verifiable software delivery?

That is a more useful way to evaluate the market because a container image is not just another dependency. It becomes part of every application built on top of it.

What Should You Evaluate?

1. Attack Surface Reduction

Minimality still matters. Look for images that remove shells, package managers, debugging utilities, and other components that have no reason to exist in production. Fewer components mean fewer packages to monitor, patch, and explain to an auditor, while also reducing the tooling available to an attacker after a compromise.

But minimality is the starting point, not the definition of software security. A small image can still contain software you cannot fully trace or verify.

Reducing what is inside an image is valuable. Knowing what you are running and being able to verify it is the next step.

2. Vulnerability Posture

Look for a defined vulnerability-management process, continuous rebuilding, and a strong vulnerability baseline at delivery.

Minimus demonstrated the value of this model, describing its images as near-zero CVE and continuously rebuilt from source. But the vulnerability count is only one part of the picture. Ask how the artifact was produced, what sources and inputs went into it, whether its provenance can be verified, and how quickly it is rebuilt when those inputs change.

There is also an important practical consideration when comparing CVE claims: scanner results are not necessarily portable. Different scanners and database versions can report different findings for the same image. Any CVE claim should therefore be evaluated against a specific image digest, scanner, scanner version, and database date.

A low CVE count matters. It is not, by itself, proof that an artifact can be trusted.

3. How the Image Is Built

Two providers can both say they build images from source while implementing very different controls around inputs, isolation, reproducibility, secrets, and provenance.

When evaluating a provider, ask whether images are rebuilt from source, whether build inputs are controlled and pinned, whether the build environment is isolated and ephemeral, whether signing secrets are protected from user-defined build steps, whether provenance is generated and signed by the build platform, whether the artifact can be traced back to a source commit, and which images are reproducible.

Minimus documented authenticated provenance signed through Sigstore, isolated ephemeral build environments, platform-managed secrets, and auditable source and build systems. Source rebuilding and build provenance are therefore not unique differentiators.

The more useful question is: How comprehensive is the verification model around the resulting software artifact?

4. Provenance and Verification

An SBOM is an inventory of what is inside an artifact. Provenance provides evidence of where the artifact came from and how it was built. A cryptographic signature provides a mechanism to verify that an artifact or attestation was signed by the expected identity and has not been altered since signing.

These capabilities are related, but they solve different problems.

Think of them as distinct layers:

Inventory → Provenance → Verification → Remediation

An SBOM tells you what is there. Provenance helps establish where it came from and how it was produced. Verification lets you establish confidence that the artifact or attestation came from the expected signing identity and has not been altered. Remediation keeps that artifact secure as vulnerabilities and upstream changes emerge.

Enterprises need the combination.

5. Compliance and Enterprise Assurance

Regulated environments raise the bar on cryptography, software inventory, configuration, provenance, and audit evidence.

FIPS is a good example of why buyers should look beyond a simple compliance label. There is a meaningful difference between FIPS-validated implementations, images built on validated cryptographic foundations, and FIPS-ready images.

Minimus offered FIPS 140-3 capabilities, including images built around validated cryptographic modules. CleanStart provides FIPS 140-3 variants built on validated cryptographic foundations, with coverage depending on the specific image and configuration.

For any regulated workload, the right question is not simply whether a provider says “FIPS.” It is:

What level of compliance does the specific image provide, and what evidence can the provider support?

The same principle applies to other enterprise requirements such as CIS, STIG, NIST, and FedRAMP.

6. Ongoing Maintenance

An image is not secure because it was secure when it was published. Vulnerabilities are disclosed, upstream projects change, and dependencies move. The provider therefore needs a process for monitoring, rebuilding, testing, and delivering updated artifacts.

The Minimus shutdown makes this particularly clear. An image can continue running after its vendor stops operating, but the maintenance model behind that image has ended.

Provider continuity is part of the security decision.

A container foundation is not a one-time download. It is a dependency you expect to be maintained over time.

7. Migration and Operational Support

Image quality is only part of the decision. Moving from one image provider to another can involve compatibility testing, image substitutions, CI/CD changes, deployment configuration, application validation, and production rollout.

For Minimus customers, that migration window is finite. The provider you choose should therefore be evaluated not only on the security properties of its images, but also on how effectively it can help you transition existing workloads.

Where SLSA Fits

SLSA provides an important foundation for establishing confidence in how software is built and where an artifact comes from. Minimus documented a SLSA Build Level 3 implementation, while CleanStart uses signed provenance aligned with SLSA as part of its broader approach to artifact verification.

For buyers, the important question is not just which framework level a provider references. It is how that provenance works together with controlled sources, isolated and hermetic builds, cryptographic signing, SBOMs, and ongoing artifact verification and maintenance.

SLSA is one part of the evaluation. The goal is verified software, not a framework level by itself.

Minimus vs. CleanStart: What Buyers Should Actually Compare

Based on publicly available Minimus documentation as of August 26, 2026, the comparison below focuses on areas that matter to enterprise buyers. The SLSA positions are self-documented rather than third-party certified.

The meaningful difference is not that Minimus lacked modern software supply chain controls. It didn't. The difference is that its maintenance model now has an end date.

That gives Minimus customers an opportunity to choose what they want their next software foundation to look like.

Where CleanStart Fits

CleanStart builds toward one outcome: verified software artifacts for modern software supply chains. The container image is the outcome, verification is the mechanism, and trust is what the organization gains from being able to establish confidence in the artifact it deploys.

CleanStart brings together minimal, hardened images; a near-zero known CVE baseline at delivery; source-built software with controlled and pinned inputs; hermetic build practices; SBOMs; cryptographic signing; signed provenance aligned with SLSA; FIPS 140-3 variants; continuous rebuilding and remediation; and free migration support for organizations moving from Minimus.

The model is straightforward:

Reduce → Rebuild → Verify → Maintain

Reduce unnecessary software. Rebuild from controlled sources. Verify the resulting artifact and its provenance. Maintain it as vulnerabilities and upstream software change.

The outcome is more than a hardened image. It is a software artifact whose contents, origin, build process, and security posture can be evaluated and verified.

How to Verify the Claims Yourself

Don't take a vendor's comparison table on trust. For any candidate provider, including CleanStart:

1. Pull a specific image by digest, not by tag. A mutable tag is difficult to reproduce or independently verify.
2. Verify the signature and provenance attestation against the provider's published identity.
3. Run your own vulnerability scan and record the scanner version and database date alongside the result.
4. Repeat the scan later on the same digest. The resulting evidence can tell you more about the provider's maintenance model than a static datasheet.

This is the difference between buying a security claim and evaluating a security control.

The Bigger Lesson From Minimus

Choosing a container image provider is not only a technical decision. It is a software supply chain decision.

Your base image becomes part of every application built on top of it. It enters CI/CD pipelines, production environments, vulnerability-management programs, compliance processes, and incident response. That makes the provider's long-term model part of your security model.

The question is not simply:

Does this image have fewer vulnerabilities?

It is:

Can we continuously verify, maintain, and trust the software foundation our applications depend on?

That is the standard enterprises should use when choosing their next container image provider.

Moving Away From Minimus?

The Minimus registry is scheduled to shut down on October 22, 2026. Images pulled before then will continue working, but they will stop receiving updates. The practical deadline, therefore, is not simply the day the registry goes dark. It is the next time your organization needs a patched or updated image.

CleanStart offers free migration support for organizations moving from Minimus.

Our team can assess your existing Minimus images, identify CleanStart equivalents, work through compatibility considerations, and help validate the migration path.

Start your migration early.

Get Free Migration Support

Move from Minimus to CleanStart Verified Container Images with support from the team.

Explore CleanStart Verified Container Images

Get Free Migration Support