Minimus has been acquired: How to choose a container image alternative

Minimus announced plans to shut down its maintained container image service and close reg.mini.dev on October 22, 2026, prompting customers to quickly evaluate replacements. Echo then acquired Minimus’s key assets and said it would keep the platform running. Echo CEO, Eilon Elhadad, told TechTarget that users now have “endless days” on the Minimus platform.

While that additional time is helpful, customers should use it to compare commitments and consider Minimus alternatives that may be a better long-term fit. Echo’s acquisition announcement does not specify how Minimus images and tags will transfer or which pricing, support, and vulnerability remediation terms customers will receive. When comparing alternatives, evaluate the terms that will affect your images in production. Consider patch deadlines, Known Exploited Vulnerabilities (KEV) coverage, Federal Information Processing Standards (FIPS) validation, production-use rights, and the work required to migrate.

Minimus alternatives at a glance

Use the table below to identify providers that meet your workload requirements, such as a stated service-level agreement (SLA) for remediating Common Vulnerabilities and Exposures (CVEs), FIPS validation, free production access, or compatibility with a particular Linux distribution.

Compare the commitments you're replacing

Minimus Enterprise customers had two-calendar-day remediation for Critical and High CVEs, plus one-calendar-day remediation for KEVs, after an upstream release fixed the vulnerability, excluding only rare and extraordinary exceptions. Community Edition included free access to the entire catalog across all version tags. Echo has not said whether it will continue Minimus’s former remediation commitments or free access to all image tags.

Seven days can describe different obligations

When evaluating Minimus alternatives, compare the written patching terms for the images you plan to run in production. A seven-day window does not always describe the same obligation. Echo, Chainguard, and Docker commit to commercially reasonable efforts, subject to eligibility. RapidFort publishes patch targets rather than a contractual SLA,. Free access also varies by provider, and Echo does not currently publish a free tier.

Before relying on a remediation window, check the conditions that determine whether it applies. Providers limit coverage to certain images, scanner findings, and upstream fixes. Those terms decide whether your CVE is covered and when the remediation clock starts.

• Echo requires supported-scanner detection and an independently fixable CVE.

• Chainguard requires the CVE to be scanner-detected and independently fixable, either by an upstream release or by rebuilding the image.

• Docker treats an upstream fix or mitigating rebuild as an Eligible Fix.

• Bitnami handles ARM64 builds on a best-effort basis.

• RapidFort doesn't attach a contractual effort standard to its patch targets.

The right remediation window for your business depends on the severity you need to prioritize. For eligible Critical CVEs, Chainguard’s seven calendar days is shorter than Echo’s seven business days. For High CVEs, Echo’s seven business days is shorter than Chainguard’s 14 calendar days. Bitnami has the shortest Critical and High windows in this set, two business days after a verified upstream fix, though its Medium and Low windows are about 30 business days, roughly six calendar weeks. Chainguard and Echo are close for Medium and Low at about two weeks, while Docker is 30 calendar days. For CVEs on CISA's KEV catalog, Chainguard is the only provider here with a stated window

For providers with remediation SLAs, the stated window does not start when your team discovers a CVE. It starts only when the provider’s policy says the required fix is available. Chainguard requires a Qualifying Patch, which can be either an upstream release or a rebuild that remediates the CVE. Echo's policy states eligibility conditions but not a clock start. Docker starts the clock when it determines an Eligible Fix is available, while Bitnami requires a verified, stable upstream fix. RapidFort publishes patch targets without stating when the clock starts or whether the days are calendar or business days.

You should also determine what ends the obligation. Echo can count a CVE as resolved when a patched artifact is published, its supported scanners stop reporting it, or its advisory feed documents resolution. Chainguard likewise permits publication to its registry, a clean result from Grype and vexctl, or advisory-feed resolution. Docker permits a patched image, scanner clearance, or an explanatory VEX (Vulnerability Exploitability eXchange) statement asserting the CVE is not exploitable, which closes it without changing the image. These are broader definitions than “the customer deployed a patched image.” Your team still needs to assess the evidence and roll out maintained versions.

Verify FIPS coverage and production-use rights

FIPS claims can help you compare providers, but coverage ultimately depends on the specific images and configurations you plan to deploy. After shortlisting providers, verify that each required image uses a validated cryptographic module, that the certificate covers your deployment environment, and who holds the certificate. Confirm whether planned image updates preserve that validation.

Certificate ownership varies. Minimus holds CMVP (Cryptographic Module Validation Program ) certificates 5177 and 5142 in its own name. Chainguard holds CMVP certificate 5132 for its FIPS Provider for OpenSSL 3.4, so for images that use that module, it is both the image provider and the certificate holder. Echo and Docker both rely on certificate 4985, held by the OpenSSL Project rather than by either vendor. Bitnami limits FIPS coverage to Photon OS images, with certificates held by VMware (Broadcom), Geomys, and Google, depending on the module. RapidFort advertises FIPS-validated cryptography but publishes no FIPS-specific commitment.

Production-use rights differ by plan. Minimus Community allowed free production use of the entire catalog. Docker's Community catalog is under the Apache 2.0 license and permits production use. RapidFort's pricing page does not state whether its five free images may be used in production. Echo publishes no free tier.

Inventory the images you run

Before comparing providers, list the Minimus images you actually run. For each image, record its name, version, architecture, and any FIPS requirement. A provider’s catalog size does not show whether it supports the exact image, version, and architecture your workloads need. Use that inventory to assess the options below.

With that inventory in hand, assess each provider against the requirements on which you cannot compromise. The profiles below cover who each option suits, what it commits to in writing, and the migration work it requires.

Echo: Best for cost-sensitive teams seeking Debian-compatible workflows

What is Echo?

Echo builds and maintains container images on Echo OS, a Debian-aligned system using apt and glibc. Echo acquired key Minimus assets, technology, and customer contracts on August 27, 2026, three days after Minimus announced it was winding down.

Echo says Minimus customers need to take no action. It has not published what happens to the registry, to pricing, or to remediation terms, and Minimus's own notice that reg.mini.dev shuts off on October 22, 2026, and still sits on their site alongside the Echo announcement. Evaluate the specific images you use rather than assuming an Echo replacement will have the same contents or runtime behavior.

Who should use Echo?

Echo is the path of least resistance. They already hold the contracts, so there's no procurement cycle and no vendor evaluation.

The work you avoid is commercial, not technical. Minimus images are built on a Wolfi fork using glibc and apk. Echo OS is Debian-aligned using glibc and apt. Moving to Echo means changing package manager and distro lineage , which is more work than moving to a Wolfi-based alternative, not less. Echo has also not said whether it will keep maintaining Minimus images or move customers onto Echo OS, so staying may delay a migration rather than avoid one.

If its business-day policy meets your security requirements, Echo offers standard Debian package tooling and a broad artifact catalog. If you relied on Minimus's one-calendar-day KEV commitment, Echo's SLA does not preserve it. There is no separate KEV window, and Critical and High CVEs fall under seven business days, roughly nine to eleven calendar days, against Minimus's two calendar days.

If Echo is on your shortlist, ask its sales or account team to confirm the transition terms in writing before you choose a provider or begin a production migration. Ask how long reg.mini.dev will remain available, which Echo images and tags replace the Minimus images you use, and what pricing, support, and remediation coverage you will receive. If you choose Echo, include those terms in your agreement.

Standout features

Echo offers extended support for end-of-life images for up to 24 months.

Echo's catalog spans containers, libraries, OS packages, and Helm charts, with VMs and serverless runtimes in early access.

Echo images are recognized by 14 scanners and 8 registries, including Nexus, Harbor, and JFrog Xray.

Pros and cons

Pricing

Echo offers quote-based pricing per artifact or for broader catalog access based on engineering organization size, which Echo defines as anyone who has committed code to a private repository in the last 180 days. Astartup plan is available on request. Do not assume Minimus Community access will continue under Echo. Before choosing Echo, get a quote for the image families you need and confirm the support and remediation terms it includes.

Chainguard: Best for Minimus workloads that need to stay on Wolfi and apk

What is Chainguard?

Chainguard Containers provides source-built, maintained images designed to include only what a workload needs. Standard images follow a distroless model. Chainguard OS is glibc-based, derived from Wolfi, and uses apk - the same lineage and package manager as Minimus. If you chose Minimus for its source-built architecture and minimal runtime, Chainguard is the closest match in that comparison.

Who should use Chainguard?

Choose Chainguard when a one-calendar-day KEV window, a seven-calendar-day Critical window, or direct cryptographic certificate ownership governs your decision. Paid coverage includes a one-calendar-day remediation window for eligible KEVs, the only KEV commitment amongs providers here. Critical CVEs have a seven-calendar-day window, and High, Medium, and Low CVEs have a 14-calendar-day window.Minimus committed to two calendar days for Critical and High, so Chainguard's High window is longer on paper, though measured High remediation averages 2.05 days. Medium and Low also fall under the 14-calendar-day window. .

The KEV window is the only commitment of its kind in this comparison. It applies once CISA (Cybersecurity and Infrastructure Security Agency) has listed the CVE and a qualifying patch is available, which can be an upstream release or a rebuild that remediates it. Like every provider here, Chainguard limits coverage to eligible images and scanner findings and commits to commercially reasonable efforts rather than guaranteeing a fix for every vulnerability in every image. In practice, a vulnerability your team finds today may not immediately start the one-day clock.

Standout features

Chainguard holds CMVP certificates 5523, 5132, and 5102 for its FIPS Provider for OpenSSL 3.4. For images that use this module, Chainguard is both the image provider and the certificate holder. Other supported modules may have certificates held by other organizations. Before you commit, confirm which module covers the specific images you plan to run. Chainguard's FIPS Commitment page lists every current module with its certificate. FIPS requirements can also affect how quickly an image can be changed, but because Chainguard owns the FIPS module, it can remediate within the FIPS boundary without waiting on a third-party module owner. The implementation is also kernel-independent, so containers run in FIPS mode without requiring a FIPS-enabled host OS.

Chainguard Containers are built on Chainguard OS, a glibc-based distribution derived from Wolfi that uses the apk package manager, which is the same foundation that Minimus forked. Package names and native dependencies still differ, so check that the packages your images need are available in Chainguard.

If your current Dockerfile installs packages during the build or invokes a shell at runtime, it will need to be modified for a standard Chainguard image. Standard images are designed to run an already-built application and omit the package manager and general-purpose shell.

Choose the variant that matches where you need those tools:

• Need packages or a shell only during the build? Use a multi-stage Dockerfile. Build with a -dev variant, which includes a shell and package manager, then copy the required artifacts into a standard runtime image.

• Need specific tooling in production? Use Custom Assembly to add exactly what you need to a minimal image. Use a -dev variant in production when you need an interactive shell.

• Need broader package compatibility or the upstream image’s entry point behavior? For supported images, start with a -full variant. A -full variant mirrors the upstream image's packages and environment, and carries the same CVE remediation SLA. Availability is currently limited, so check the catalog for your image.

Start with the standard image when it supports your runtime, then move to a larger variant only when your workload requires it.

Pros and cons

Pricing

Paid per-image and catalog subscriptions support different rollout sizes and include contractual remediation coverage and support. Get a quote for the image families and FIPS variants you need.

Chainguard Catalog Starter offers five images for free, including production use, with the same hardening, rebuilds, verifiable SBOMs, and SLSA Level 3 provenance as paid images. Chainguard patches them on the same schedule as paid images, but without the contractual CVE SLA or KEV commitment. Catalog Starter requires a business email, and excludes FIPS images, end-of-life, and EmeritOSS versions.

Docker Hardened Images: Best for Minimus Community users replacing free catalog access

What is Docker Hardened Images?

Docker Hardened Images (DHI) is Docker's maintained image catalog, with Alpine- and Debian-based options. Minimus images are glibc-based and use apk. Alpine also uses apk but its packages are built for musl, and Debian keeps glibc but uses apt, so neither base carries your existing packages over.

Who should use Docker Hardened Images?

Choose DHI to replace Minimus Community access with free, production-permitted images. Consider a paid plan if the images you run in production need a contractual patch deadline, support, or FIPS variants.

Choosing an Alpine or Debian base can reduce distribution-level migration work, but it does not guarantee that a DHI image will behave like your Minimus image. DHI runtime images are intentionally minimal. If your Dockerfile installs packages or your team depends on an interactive shell for debugging, use a development stage or other tooling.

Standout features

Docker publishes the full DHI catalog under Apache 2.0, and its Extended Lifecycle Support add-on covers images for five years past upstream end-of-life, the longest window in this comparison.

Docker shipped an MCP server and a GraphQL API in Q3 2026. The server exposes repository search image metadata, SBOM retrieval, CVE checks, and mirror management, so an AI coding agent can evaluate and pull images without a developer navigating the catalog. No other vendor in this list offers a comparable service.

Pros and cons

Pricing

The Community catalog is free under the Apache 2.0 license, including production use. Paid Select and Enterprise offerings add SLA-backed remediation, support, and compliance features, including FIPS variants. Select starts at $5,000 per repository, and Enterprise pricing is quote-based. Use the free catalog when production-use rights meet your needs and you can manage remediation on your own timeline. If your production images require a defined remediation commitment, support, or FIPS variants, evaluate Docker’s paid plans for the image families you run.

RapidFort: Best for teams needing Ubuntu and Red Hat base images

What is RapidFort?

RapidFort offers curated hardened images and a separate platform for profiling and reducing the contents of your own images. Its curated images cover upstream distributions including Ubuntu, Red Hat, Debian, and Alpine, with an emphasis on long-term support versions.

RapidFort offers curated hardened images and a separate platform for profiling and reducing the contents of your own images. Its curated images cover Ubuntu, Red Hat, Debian, and Alpine, with an emphasis on long-term support versions. Ubuntu and Red Hat are the two you won't find elsewhere in this comparison.

Who should use RapidFort?

RapidFort fits teams that need Ubuntu or Red Hat base images. A curated-image subscription supplies maintained images; profiling and removing unused components adds a workflow to operate and test. RapidFort is also offering no-cost migration assistance to Minimus customers and evaluators before October 22. That offer covers the move itself, not the remediation terms you land on afterward.

RapidFort’s curated-image page says it targets Critical CVE fixes within seven days and other severities within 14. It does not state a day unit, when the clock starts, or an SLA, so teams that need Minimus-style remediation terms should ask RapidFort to include those commitments in their subscription agreement.

Standout features

RapidFort supports several upstream distributions, but availability still varies by image. Before migrating a Minimus image, confirm that RapidFort offers the application version, architecture, and dependencies your workload requires.

RapidFort can use runtime insight to identify the files, libraries, and binaries an application actually executes. Its automated hardening can then remove unused components while preserving expected application behavior. Before deploying a hardened version, test workloads that exercise infrequent jobs or features, since those dependencies may not appear in routine runtime observations.

RapidFort’s patch targets address vulnerability remediation, not FIPS coverage. If your workload requires FIPS, confirm the specific image’s cryptographic module and certificate before you select it.

Pros and cons

Pricing

RapidFort’s free tier includes five curated images from a limited catalog, with daily rebuilds and patching. The pricing page does not specify whether those images are licensed for production use. Full Catalog expands access to the broader image catalog, while Images + Platform adds runtime profiling and continuous hardening. If production-use rights or support are requirements, confirm those terms with RapidFort before choosing a plan.

Bitnami Secure Images: Best for teams whose deployments are built on Bitnami Helm charts

What is Bitnami Secure Images?

Bitnami Secure Images is Broadcom’s catalog of hardened, continuously maintained open source applications for production. It provides container images and Helm charts with security metadata such as SBOMs, VEX documents, vulnerability reports, and build provenance. Customers select the applications, packaging formats, and supported base images they need, and Bitnami delivers the resulting artifacts to a customer-controlled registry.

Who should use Bitnami Secure Images?

Consider Bitnami Secure Images if its catalog covers the open source applications and versions you currently run with Minimus, particularly if your team wants maintained Helm charts alongside container images or needs artifacts delivered to its own registry.

Bitnami also has the shortest paid Critical and High remediation window among the providers compared here. For eligible builds, it provides fixes within two business days after a verified, stable upstream fix becomes available. If you run ARM64 workloads, check availability and remediation expectations separately. Broadcom treats ARM64 builds on a best-effort basis, so do not assume they receive the same two-business-day Critical and High remediation target as supported builds.

Before choosing Bitnami, map each Minimus workload to the exact Bitnami image or chart you would deploy. Even when Bitnami offers the same application, its image or chart may use a different base OS, version, packaging format, default configuration, or startup behavior than the Minimus artifact it replaces. Test chart values, image paths, startup behavior, persistence, architecture, and the selected base OS in a staging environment.

Standout features

For eligible builds, Bitnami provides fixes for Critical and High CVEs within two business days and for Medium and Low CVEs within 30 business days, once a stable upstream fix has been verified. It does not publish a separate remediation deadline when a CVE is added to CISA’s KEV catalog.

FIPS coverage depends on the base image you choose. Bitnami offers Photon, Debian, and Red Hat Universal Base Image (UBI) options, but its validated cryptographic modules are available only with Photon OS-based images. Broadcom documents FIPS coverage for selected Photon OS-based images. The applicable certificate depends on the cryptographic module in the image:

• OpenSSL: FIPS 140-3 certificate 5147

• Java: certificate 4986

• Go: certificate 5247

• BoringCrypto: certificate 4973

The older OpenSSL FIPS 140-2 certificate, 4861, moves to the CMVP historical list on September 21, 2026, when NIST moves all remaining FIPS 140-2 validations to that list. FIPS coverage varies across Bitnami image configurations. When evaluating Bitnami for a FIPS-dependent workload, confirm that the specific Photon OS-based image you would migrate to uses a validated cryptographic module and certificate.

Pros and cons

Pricing

Bitnami prices paid subscriptions by active artifact. Each application, packaging format, and base-image combination counts separately. For example, a container image and a Helm chart for the same application may count as two artifacts. Broadcom’s program documentation says artifacts on a Debian 12 base image do not count toward this limit. Before buying, ask Broadcom to confirm the artifact count for the images and charts you need.

If you distribute Bitnami images to customers, confirm that your subscription includes the required redistribution rights. Broadcom’s current terms also require customers to stop using the images when the subscription ends.

Free access is limited to latest tags for nonproduction use. Paid subscriptions provide maintained versions for production, along with support.

Turn your shortlist into a migration plan

Choosing a provider is only the first step. Before committing, confirm that the provider covers the exact images you run and document how its contract, image contents, and operating model differ from Minimus. The work will vary by workload, but most teams should plan for these stages:

1. Inventory every Minimus image reference across build stages, Helm charts, scheduled jobs, and deployment manifests. Record the tag or digest, architecture, application version, FIPS requirements, dependencies, and internal owner.

2. Map each Minimus image to a candidate replacement. Document gaps in application versions, architectures, base distributions, cryptographic modules, package availability, and default configuration.

3. Confirm the commercial and operational terms for each candidate. Review production-use rights, remediation commitments, support, image-retention policies, and access to future releases. If you are considering Echo, get its Minimus transition terms in writing.

4. Test representative workloads in staging. Validate startup behavior, permissions, health checks, package installation, native dependencies, persistent data, signatures, SBOMs, vulnerability evidence, and any required FIPS configuration.

5. Roll out replacements in stages with a tested rollback path. Confirm that new nodes can pull the images through your production registry path, then assign responsibility for adopting future maintained releases.

A matching image name or a successful container start is not enough. A replacement is ready when your team can pull it through the production path, run the workload as expected, verify the required security evidence, and receive future maintained releases under acceptable terms.

Chainguard should be on the shortlist for Minimus customers who prioritize a written KEV remediation window and source-built minimal images. For covered images, Chainguard is both the image provider and FIPS certificate holder, giving your team one vendor to work with when confirming whether an image meets a FIPS requirement.

Compare Chainguard and Minimus, then talk to Chainguard to map your current inventory to available images and understand the build or runtime changes each workload will require.