Minimus ferme : vos images gèlent le 22 octobre

Ce qui se passe

Minimus cesse ses activités. L'entreprise publiait des images de conteneurs durcies et minimales — le même créneau que Chainguard ou que Docker Hardened Images : une base réduite à l'essentiel, donc moins de paquets, donc moins de CVE à traiter.

Le calendrier annoncé est une fenêtre de maintenance de 60 jours : les images continuent de recevoir les mises à jour amont jusqu'à la mise hors ligne du registre, le 22 octobre 2026.

Pourquoi ça compte, même sans urgence apparente

C'est le point qui mérite qu'on s'y arrête. Le 22 octobre, rien ne cassera. Les images déjà téléchargées continuent de tourner, vos déploiements passent, aucune alerte ne se déclenche.

Ce qui s'arrête, ce sont les mises à jour. Chaque faille publiée après cette date reste non corrigée dans ces couches, indéfiniment. Une base durcie qui ne bouge plus devient, en quelques mois, exactement le contraire de ce pour quoi elle avait été choisie — et sans qu'aucun signal ne l'annonce.

Le risque n'est donc pas la panne, c'est l'oubli. Une image figée dans un Dockerfile que personne ne relit vieillit en silence.

Comment s'y prendre

Docker publie un guide de migration, une liste de contrôle par image, des exemples complets, et propose une assistance gratuite aux clients Minimus. Il faut évidemment lire cela pour ce que c'est : un concurrent qui récupère la clientèle d'un concurrent, et le billet est aussi un argumentaire commercial.

Les éléments vérifiables, eux, tiennent : le catalogue Docker Hardened Images est distribué sous Apache 2.0, utilisable en production, sans plafond d'utilisateurs.

En pratique, la bascule tient souvent à une seule ligne — celle-ci :

FROM minimus/node:22

Le tag de remplacement se lit dans le catalogue de la destination choisie ; le reste du Dockerfile bouge rarement.

La checklist utile, quelle que soit la destination choisie :

1. Inventorier : grep -rn "^FROM" --include=Dockerfile . sur tous vos dépôts, plus les images de base de vos workflows CI.
2. Comparer les équivalents : mêmes versions de runtime, même architecture.
3. Revérifier deux choses après le swap : l'utilisateur non root (les bases durcies n'utilisent pas toutes le même UID) et la présence, ou l'absence, d'un shell — beaucoup d'images minimales n'en embarquent pas, ce qui casse les RUN de vos étapes suivantes et les scripts d'entrée.
4. Comparer les scans avant et après, pour vérifier que la migration ne fait pas rentrer des CVE plutôt que l'inverse.

Rien n'oblige d'ailleurs à aller chez Docker : Chainguard, Wolfi, ou les images distroless de Google répondent au même besoin. Ce qui compte est la date.

À retenir

Une dépendance d'infrastructure peut disparaître sans rien casser, et c'est le scénario le plus dangereux : il ne déclenche aucune alerte. Notez le 22 octobre, et traitez la migration comme une mise à jour de sécurité — parce que c'en est une, différée de deux mois.

Source : Docker