Minimus is ending operations and plans to turn off its registry, reg.mini.dev, on October 22, 2026. The company says images pulled before that date should continue to function, but they will not receive further updated images. For teams that depend on Minimus for maintained container images, the shutdown creates a deadline to inventory current dependencies and choose replacement images.
Docker is positioning Docker Hardened Images (DHI) as a migration destination. The move may be straightforward for some services, but it is not safe to assume that every Minimus image has a direct DHI equivalent or that every migration only requires a one-line Dockerfile change.
What changed for Minimus users
According to Minimus, a 60-day maintenance period began on August 24, 2026. During that period, Minimus says it will provide necessary bug fixes, commercial support, and upstream image updates. Operations are scheduled to cease and the Minimus registry is scheduled to go offline on Thursday, October 22, 2026.
Images pulled before the registry shutdown are expected to keep running, but that should not be confused with ongoing maintenance. Minimus says no further updated images will be provided after the shutdown. In practical terms, teams that continue using those images will need to manage the consequences of relying on an image source that no longer publishes updates.
Minimus also says it will contact Enterprise Edition customers individually about structured termination and applicable refunds for the remaining contract period beyond October 22. Docker is offering Minimus customers free migration assistance at minimus@docker.com, including help with image lists, compliance requirements, and migration-planning questions.
What Docker Hardened Images provide
DHI is available through several subscription paths. Docker describes DHI Community as free and available to every developer through the public dhi.io registry. Community users reference images in the dhi.io/<image>:<tag> form and must authenticate to dhi.io with Docker credentials or an access token before pulling.
DHI Select and Enterprise users use organization-scoped references after mirroring repositories. That means organizations choosing a paid plan need to account for repository mirroring and the resulting image-reference changes. Docker describes Select as a paid annual plan priced per repository. Enterprise adds capabilities including unlimited customizations, optional full-catalog access, the Hardened System Packages repository, and an Extended Lifecycle Support add-on. Exact pricing is not established in the supplied documentation.
The available DHI catalog includes Alpine- and Debian-based images, Ubuntu, Wolfi-based images, and language or framework-specific options. Docker also documents runtime and development variants. Runtime images can omit shells and package managers and may run as non-root by default, while development variants include tools intended for builds and testing. Compatibility variants are available for Helm charts and specialized applications that need tools or configuration not present in minimal runtime images.
For organizations with compliance requirements, Docker documents subscription-dependent FIPS and STIG options. FIPS variants use a -fips tag, while STIG-ready variants are identified through the catalog’s compliance information. These options should be evaluated against the organization’s actual requirements rather than treated as automatically available for every image or subscription.
Dockerfile and pipeline changes
Docker says that, for most services, the main Dockerfile change is updating the FROM line. That can make the initial edit small, but it is not a universal compatibility guarantee. A Minimus image may have supplied a shell, package manager, user configuration, or other behavior that the selected DHI variant does not provide.
A common consideration is separating build and runtime needs. Docker’s DHI guidance documents multi-stage patterns that use a development image for compilation and testing, followed by a smaller runtime image for execution. Teams should select the variant based on what each stage actually requires instead of assuming that a runtime image can also serve as a build environment.
CI/CD systems may require more than a Dockerfile edit. The pipeline could need updated registry references, credentials for dhi.io, organization-mirroring configuration, or new checks for image attestations. The exact changes depend on the current Minimus setup and the DHI subscription and variant selected; Docker’s documentation does not define a single migration procedure for every pipeline.
Kubernetes and registry configuration
Kubernetes deployments pulling from dhi.io, Docker Hub mirrors, or third-party registries require image-pull secrets, according to Docker’s DHI usage documentation. Platform teams should therefore review deployment manifests, namespace-level credentials, and the registry path used by each workload.
Select and Enterprise deployments also need to reflect organization-scoped references after repositories are mirrored. This can affect Kubernetes manifests, Helm values, GitOps repositories, deployment automation, and policy checks that expect a particular registry hostname or image path.
Application startup and health checks deserve explicit testing. Minimal runtime images may not include a shell or package manager, and a non-root default can expose assumptions in entrypoints, file permissions, writable directories, or operational tooling. These are validation concerns, not evidence that a selected image is incompatible; the behavior must be tested for the application and variant involved.
Validate the replacement and its supply-chain metadata
Docker says DHI images include signed attestations such as software bills of materials (SBOMs) and provenance metadata. Its verification guidance documents ways to inspect and verify attestations using Docker Scout, regctl, and cosign.
After selecting a replacement, teams should make verification part of the migration rather than treating a successful build as the only acceptance criterion. Review the image’s available metadata, verify the relevant signatures or attestations using the documented workflow, and preserve the results required by the organization’s supply-chain process. Docker notes that Docker Scout’s --skip-tlog option requires version 1.18.2 or later; other exact tooling requirements are not fully defined by the supplied material.
Security claims about reduced components or attack surface should be understood as Docker’s product claims. The practical, verifiable point for a migration is that teams can inspect the selected image’s published metadata and test its runtime behavior before promoting it.
What you should do before October 22
- Inventory Minimus dependencies. Search Dockerfiles, CI/CD configuration, Kubernetes manifests, Helm charts, deployment repositories, and image registries for Minimus image references, tags, and digests.
- Identify update-sensitive workloads. Separate images that can remain temporarily pinned from services that require continuing upstream updates, bug fixes, or commercial support.
- Choose replacements individually. Review the DHI catalog and migration guidance for the relevant base distribution, language, framework, runtime, development, compatibility, or compliance needs. Do not assume a universal Minimus-to-DHI mapping; no authoritative image-by-image replacement catalog is supplied here.
- Update access and references. Configure authentication for Community pulls from
dhi.io. For Select or Enterprise, account for repository mirroring and organization-scoped references. Update Kubernetes image-pull secrets where required. - Test the complete workload. Build the image, run application startup and health checks, exercise permissions and file access, test shell or package-manager assumptions, and validate the deployment environment.
- Verify image metadata. Use the documented Docker Scout,
regctl, orcosignworkflows as appropriate for the organization’s attestation and provenance requirements. - Document rollback and ownership. The supplied documentation does not provide a Minimus-specific rollback procedure. Teams should define their own rollback plan, including which previously pulled image digests remain available locally or in an internal registry and who approves a return to them.
Availability and migration limitations
DHI Community is described as available now through dhi.io, while Select and Enterprise require paid subscriptions and additional repository configuration. The October 22, 2026 Minimus registry shutdown is an announced future change, and the maintenance period is scheduled to run from August 24 through that date.
The most important limitation is that Docker’s migration guidance does not establish a replacement for every Minimus image. It also does not guarantee compatibility across all workloads. Teams should treat the DHI catalog as a set of candidate destinations, then validate each application’s build, startup, permissions, deployment, compliance, and verification requirements before switching production references.
