MinIO archive son dépôt open source et laisse l’object storage auto-hébergé sans correctifs
Le 25 avril 2026, le dépôt minio/minio a été archivé en lecture seule : le serveur S3 auto-hébergé ne reçoit plus de correctifs ni de nouvelles versions. Le 24 août 2026, Docker a annoncé reprendre sa maintenance contre abonnement ELS, forçant les auto-hébergeurs à trancher avant leur prochain audit.
25 avril 2026. Lecture seule. Un milliard de pulls. Le 25 avril 2026, le propriétaire du dépôt minio/minio l’a archivé sur GitHub : le code est désormais en lecture seule, la dernière contribution remonte au 24 avril 2026 et plus aucune release, aucun correctif, aucun backport ne sortira de la branche open source. Le 24 août 2026, Docker a rendu publique sa réponse : reprendre la maintenance de MinIO par l’intermédiaire de son offre Extended Lifecycle Support (ELS), contre abonnement. Pour un auto-hébergeur qui stocke ses sauvegardes, ses médias et ses buckets sur MinIO, c’est un compte à rebours qui s’ouvre.
Un archivage, pas une simple pause
L’archivage du dépôt n’est pas un détail de gouvernance. MinIO est un stockage objet compatible S3, distribué en binaire unique, sous licence AGPL-3.0, et l’un des serveurs les plus déployés de l’auto-hébergement : l’équivalent libre d’Amazon S3 pour qui veut garder ses données chez soi. Docker l’évalue à plus d’un milliard de pulls de son image officielle.
Quand un dépôt de cette ampleur passe en lecture seule, la conséquence est mécanique : le prochain CVE découvert dans MinIO ou dans son arbre de dépendances Go n’aura pas de correctif upstream. Les images que vous tirez aujourd’hui sont figées. Les scanners de vulnérabilités continueront de les signaler, et un audit de conformité lira « logiciel non maintenu en production ».
La date mérite d’être posée précisément. GitHub indique un archivage par le propriétaire le 25 avril 2026. Docker, dans son annonce du 24 août 2026, situe l’arrêt des livraisons open source au 13 février 2026. Peu importe la date retenue : au moment où cet article est écrit, le dépôt minio/minio est en lecture seule, ce qui se vérifie en une requête d’API.
Pourquoi ce cas dépasse MinIO
Le sort de MinIO n’est qu’un symptôme. Docker cite le rapport 2026 Open Source Security and Risk Analysis de Black Duck, selon lequel 93 % des bases de code commerciales embarquent des composants sans activité de développement depuis au moins deux ans. Le même schéma court partout : Node 18, Python 3.8 ou d’anciennes versions d’Airflow tournent encore en production longtemps après la fin de support amont.
La nouveauté, c’est que les cadres réglementaires transforment cette dette technique en défaut d’audit. FedRAMP, DORA et le Cyber Resilience Act européen traitent un logiciel en fin de vie non patché comme un écart de conformité. Le calendrier de migration n’est donc plus dicté par la roadmap interne : il l’est par le calendrier d’audit. Pour MinIO, la question n’est plus « quand migrer » mais « que faire avant la prochaine revue ».
Les trois options, sans quatrième
Concrètement, un auto-hébergeur qui fait tourner MinIO aujourd’hui a trois issues, et « ne rien faire » n’en est pas une :
- Migrer vers un remplaçant. C’est la voie saine à terme : SeaweedFS, Garage (le serveur S3 léger de Deuxfleurs), un Ceph RGW si vous avez déjà un cluster Ceph, ou un retour vers un S3 managé. Nous avions déjà comparé ces options en juillet dans notre panorama des alternatives à S3. Le coût est réel : déplacer un object store de production se mesure en téraoctets, parfois en pétaoctets, et la fenêtre de migration peut durer des mois.
- Porter les correctifs soi-même. C’est ce que permet la lettre de la licence AGPL : le code reste lisible. Mais maintenir un fork de MinIO suppose une ingénierie Go soutenue pour un projet qui ne livre plus de fixes. Irréaliste pour un homelab, et rarement rentable en dessous d’un certain volume.
- Garder ce qui tourne et déléguer la maintenance. C’est exactement la proposition de Docker ELS : une image MinIO maintenue et durcie, avec un suivi des CVE qui couvre l’arbre de dépendances Go, transitives comprises, puis des backports reconstruits et republiés.
Le piège serait de lire cette liste comme un menu à choix libre. Les deux premières options demandent du temps ; la troisième demande de l’argent. Le vrai arbitrage se joue entre ces deux devises.
Docker ELS : le pont, pas la destination
Docker ELS (Extended Lifecycle Support) est un service d’abonnement : vous demandez une image, Docker la construit et la maintient jusqu’à cinq ans après la fin de vie amont. Le modèle ne se limite pas à MinIO — il couvre tout composant en fin de vie que vous devez conserver, et MinIO n’en est que la dernière illustration.
Il faut lire l’offre pour ce qu’elle est : un pont. Elle achète du temps pour mener la migration proprement, sans laisser l’exposition aux CVE grossir pendant que le déménagement des données avance. Elle ne supprime pas le problème de fond — un logiciel dont l’amont est gelé —, elle le repousse et le rend auditable.
Le risque, c’est de confondre le pont avec la destination. Un abonnement ELS qui se renouvelle d’année en année transforme une dette technique en loyer permanent sur un composant figé. La bonne lecture tient en une règle : chaque renouvellement doit être accompagné d’un jalon de migration mesurable vers une cible maintenue, qu’il s’agisse d’un fork communautaire actif, d’un remplaçant ou d’un retour au S3 managé.
# L'image officielle ne bouge plus depuis l'archivage : vérifiez la vôtre
docker images minio/minio --format '{{.Tag}} {{.CreatedSince}}'
docker pull minio/minio:latest # ne rapportera aucune nouvelle coucheDétecter votre exposition avant de trancher
Avant de choisir une option, mesurez l’exposition réelle. Trois vérifications suffisent pour cadrer la décision.
- La version. Un
minio --versionsur chaque nœud vous dit si vous êtes sur une release récente ou une image ancienne. Depuis l’archivage, aucun correctif ne viendra combler l’écart. - La surface. Combien d’applications pointent vers votre instance, et lesquelles portent des données sensibles ? Un bucket de cache se migre en une journée ; un bucket de sauvegardes à valeur juridique se migre en trimestres.
- Le scanner. Les scanners d’images signalent déjà les CVE de MinIO et de son arbre Go. Le nombre ne fera que croître : sans correctif upstream, chaque nouvelle découverte devient un signal permanent.
Cette photographie fixe le calendrier. Un homelab qui stocke quelques gigaoctets peut migrer ce week-end vers Garage. Une flotte qui sert des pétaoctets à des applications métier n’a pas ce luxe : c’est là que le pont ELS devient un achat de temps rationnel, et non un réflexe de confort.
Comparons vite les remplaçants sur le critère qui compte. Garage est léger et multi-nœuds, idéal pour commencer petit. SeaweedFS offre un filer et une passerelle S3 dans un seul binaire. Ceph RGW est lourd mais éprouvé, pertinent si vous exploitez déjà Ceph. Aucun ne réplique MinIO à l’identique : le choix dépend moins de la fonctionnalité que de votre capacité à exploiter le remplaçant.
Verdict
Si MinIO est au coeur de votre stack — vos sauvegardes, vos médias, vos buckets d’application — et que la migration est à plus de six mois, souscrire à Docker ELS est une décision défendable : vous arrêtez l’hémorragie de correctifs et vous gardez vos audits verts pendant que le déménagement avance.
Si MinIO est périphérique ou que votre volume de données est faible, ne payez pas un pont dont vous n’avez pas besoin : migrez directement vers SeaweedFS, Garage ou un S3 managé, et profitez-en pour réévaluer ce que ce stockage devait vraiment faire.
Dans tous les cas, commencez par un geste simple et immédiat : inventoriez vos instances MinIO, relevez la version exacte de chacune, et vérifiez si l’image que vous tirez est déjà figée. Ce que vous ne savez pas fonctionner chez vous, vous ne pourrez ni le patcher ni le migrer — et c’est précisément ce qu’un audit vous reprochera en premier.