Le dépôt MinIO n’est plus maintenu

 (github.com/minio)
2 points par GN⁺ 2026-02-14 | 1 commentaires | Partager sur WhatsApp
  • Le fichier README.md a été modifié pour indiquer explicitement que le projet n’est plus maintenu
  • La mention précédente de « mode maintenance » a été supprimée et remplacée par l’avertissement « THIS REPOSITORY IS NO LONGER MAINTAINED »
  • Deux options de remplacement, AIStor Free et AIStor Enterprise, sont désormais proposées en haut du README
  • Des erreurs de liens dans la documentation ont été corrigées, et l’URL du canal Slack a été rétablie correctement
  • Ce changement confirme que le dépôt open source MinIO est passé en lecture seule (archive)

Principales modifications du README.md

  • La section existante « Maintenance Mode » a été entièrement supprimée et remplacée par un nouveau bloc de commentaire

    • Ce nouveau bloc contient la mention « THIS REPOSITORY IS NO LONGER MAINTAINED »
    • Sous l’entrée « Alternatives », deux produits de remplacement sont indiqués
      • AIStor Free : version autonome gratuite pour la communauté
      • AIStor Enterprise : version distribuée avec support commercial

  • Le lien d’information sur l’abonnement lié à AIStor présent dans la documentation précédente a été supprimé et remplacé par une explication plus concise

Autres corrections et ajustements

  • Le lien Slack a été corrigé, passant de https//slack.min.io à https://slack.min.io
  • Dans les exemples de variables d’environnement, la faute de frappe (GOARCh) a été corrigée en GOARCH
  • Dans le texte de licence AGPLv3, l’erreur orthographique (liabilites) a été corrigée en liabilities
  • Une ligne vide a été ajoutée dans la section « Legacy Binary Releases » pour améliorer la lisibilité

État du dépôt

  • En haut de la page GitHub apparaît la mention « This repository was archived by the owner on Feb 13, 2026. It is now read-only. »
  • Cela signifie que le dépôt a été archivé et qu’il n’est plus possible d’y apporter des modifications ou des contributions

Signification

  • Avec cette modification du README, le dépôt passe officiellement en fin de maintenance et en état d’archivage
  • Les utilisateurs sont orientés vers la gamme AIStor Free/Enterprise à la place de la version open source de MinIO
  • Le support communautaire continue d’être assuré via GitHub et Slack, sur une base best-effort

À lire aussi

1 commentaires

 
GN⁺ 2026-02-14
Commentaires sur Hacker News

  • Je ne pense pas qu’il y ait de problème au fait que MinIO ait fermé son open source
    Il y a beaucoup trop de gens dans le monde qui ne font que l’utiliser gratuitement
    Je teste des alternatives depuis quelques mois et, après MinIO, je pense que RustFS sera le vainqueur
    J’ai comparé Garage, SeaweedFS, Ceph et RustFS ; RustFS et SeaweedFS étaient les plus rapides, et RustFS était le plus pratique à installer et à administrer via sa console
    Ceph est trop complexe, au point qu’il est difficile à déployer sans bien comprendre le code source en profondeur
    Certains critiquent la CLA de RustFS en disant que c’est un « appât », mais je ne pense pas que ce soit excessif comme mécanisme pour réduire les risques juridiques
    Chez Milvus aussi, RustFS est très bien évalué, et au vu des indicateurs techniques, je pense que RustFS finira par l’emporter
    Article d’évaluation de RustFS par Milvus

    • En tant que mainteneur de Milvus, je voudrais partager quelques réflexions
      Le problème des utilisateurs gratuits existe bel et bien, et il devient encore plus grave à l’ère de l’IA
      Beaucoup d’utilisateurs se servent gratuitement du projet, mais la part de ceux qui se convertissent en clients payants est très faible
      Milvus a besoin d’un meilleur object storage pour la stabilité et les performances, et RustFS est un candidat sérieux
      Mais si l’écosystème ne répond pas à ce besoin sur le long terme, nous devrons peut-être envisager de le construire nous-mêmes
      Une discussion sur la durabilité des modèles de licence open source est nécessaire
      Le modèle de l’ère Apache 2.0 montre ses limites, et l’approche consistant simplement à « espérer que les entreprises soutiennent le projet » ne fonctionne plus
      La décision de MinIO mérite l’attention comme signal de ce changement
    • J’exploite Ceph sur un cluster k8s, avec 4 nœuds équipés chacun de deux SSD de 4 To
      La configuration était complexe, mais aujourd’hui c’est très stable
      Claude Code est excellent pour administrer Ceph, et gère facilement la récupération ou la modification de la map CRUSH
      Dire qu’on ne peut pas le déployer sans comprendre le code source en profondeur me paraît exagéré
      Si Ceph correspond à votre cas d’usage, je vous recommande vraiment de l’essayer
    • L’installation de Garage est très simple
      Il suffit d’installer un binaire unique puis d’écrire le fichier de configuration /etc/garage.toml
      On peut le lancer avec garage server, ou demander à une IA d’écrire un script d’initialisation
      AIStore de NVIDIA est aussi un excellent système compatible S3, à voir sur le site officiel d’AIStore
      Il est plus rapide que MinIO, mais un peu moins efficace en matière d’espace
      SeaweedFS donne fortement l’impression d’un projet personnel, et si on ne fait pas de sauvegardes fréquentes, c’est risqué
      Je préfère éviter RustFS à cause du problème de CLA, car j’ai l’impression que cela pourrait reproduire l’affaire MinIO
    • SeaweedFS repose sur la conception Haystack de Facebook, et est optimisé pour un objectif précis : minimiser les consultations de métadonnées
      Il fonctionne par volumes, et les mises à jour se font elles aussi au niveau du volume
      À l’inverse, un object storage généraliste sert aussi de backend analytique et a donc besoin de scans rapides
      SeaweedFS implique donc des compromis différents de ceux d’un object storage généraliste
    • Vous dites que la CLA de RustFS réduit les risques juridiques, mais j’aimerais savoir plus précisément quels risques juridiques elle réduit

  • Quand j’ai arrêté d’exploiter un service open source, la fatigue chronique a disparu
    Travailler gratuitement n’avait rien d’agréable, et maintenir à la fois une version payante et une version communautaire était aussi difficile
    La relation avec les utilisateurs qui ne paient pas finissait par être une source de stress
    On dirait que l’équipe de MinIO a tiré la même leçon

    • L’équipe de MinIO n’a pas travaillé gratuitement
      Avec le modèle COSS (Commercial Open Source Software), elle proposait une version de base gratuite et vendait des fonctionnalités payantes aux clients entreprises
      Le passage au code source fermé est simplement une décision commerciale
      J’ai utilisé SeaweedFS longtemps en production, et aujourd’hui je l’exploite avec Wasabi
      SeaweedFS reste excellent pour du stockage local rapide
    • Faire payer un produit est parfaitement normal, mais faire sa promotion comme FOSS au départ puis changer ensuite de licence me paraît problématique
      Il aurait fallu annoncer clairement ce plan dès le début
      Sinon, il est juste de respecter les engagements pris auparavant
    • Je maintiens un système de stockage open source depuis plusieurs années, et j’y prends toujours plaisir
      Je m’occupe d’un moteur de stockage appelé TidesDB, et même avec le dos en vrac, j’aime tellement ça que je continue
    • Si on crée un projet open source populaire dans le but de gagner de l’argent, c’est qu’on n’a pas vraiment compris l’esprit de l’open source
    • Cela fait presque 30 ans que je participe au logiciel libre, et l’expérience de travailler avec une communauté a été très enrichissante
      C’est subjectif, bien sûr, mais cela peut vraiment être agréable

  • J’ai migré avec succès de MinIO vers Ceph
    J’ai aussi testé SeaweedFS, mais en analysant les bugs avec l’aide de Claude, j’ai constaté que la structure du code était chaotique
    Il ne faut jamais utiliser SeaweedFS en dehors de tests. Le risque de perte de données est trop élevé

    • SeaweedFS est un vieux projet ; il est possible que vous n’ayez vu que les traces d’une base de code legacy
    • Ceph est l’OG de l’object storage
      Il y a eu plusieurs tentatives de remplacement, mais au final Ceph reste celui qui résout le mieux la complexité du problème

  • Je suis en train de migrer MinIO vers Ceph en ce moment
    J’ai monté un cluster Ceph de 3 serveurs avec cephadm, et je réplique 120 To de données à 420 Mo/s
    Ceph est plus complexe que MinIO, mais il est très scalable et stable
    La disparition de la console de MinIO est regrettable
    Elasticsearch n’aime pas les snapshots S3 de Garage, j’ai donc choisi Ceph

    • Ceph est complexe, mais sa couche de consensus est très robuste
      Il faut simplement faire attention à ne pas laisser les disques des nœuds se remplir

  • Il est frappant de voir tant de gens tester dans l’urgence des alternatives pas encore éprouvées en production
    Le vrai risque des dépendances d’infrastructure n’est pas le code fermé, mais le coût de bascule
    Même avec une compatibilité S3, une vraie migration prend des semaines ou des mois à cause des différences subtiles
    Je me demande combien d’utilisateurs de MinIO ont réellement documenté un plan de migration

  • AIStore est cité comme alternative à MinIO
    Il existe aussi plusieurs autres alternatives open source :
    Garage, RustFS, SeaweedFS, Supabase Storage, Scality Cloudserver, Ceph

    • Je suis l’auteur de Filestash
      Il fournit une passerelle S3 et proxy les appels S3 vers SFTP, FTP, NFS, SMB, IPFS, Dropbox, Google Drive, etc.
      Il est entièrement stateless et peut se connecter à différents backends
    • RustFS a beaucoup de fonctionnalités et peut aussi assurer sa propre gestion des clés, mais il est encore en développement
      Le code contient déjà des préparatifs pour un futur changement de licence
      Ceph est celui dont les fonctionnalités S3 sont les plus proches, mais sa configuration est complexe et il est sensible à la latence
      Garage est bien pour du stockage simple, mais il lui manque des fonctions avancées de S3 comme les ACL avancées ou les restrictions de chemin
      Son clustering est adapté au WAN, sans nécessiter de configuration par rack comme Ceph
    • En dehors de MinIO, j’ai utilisé Garage et Ceph, mais j’ai besoin d’un système de fichiers S3 simple pour des tests locaux
      Il semble qu’il n’existe pas encore d’alternative aussi simple
    • J’utilise SeaweedFS sur une machine unique comme stockage compatible S3
      Les fonctions d’administration sont limitées, mais pour l’intégrité des données, je fais davantage confiance à Ceph
      Ceph donne l’impression d’avoir été conçu par des gens qui comprennent vraiment les systèmes distribués
    • J’ai ajouté la liste d’alternatives ci-dessus au dépôt MinIO via une Pull Request
      Lien vers la PR

  • En regardant l’ancien fil HN, on pouvait déjà voir que MinIO était passé en mode maintenance
    Le passage au code fermé était donc annoncé depuis ce moment-là

    • Mais le mode maintenance et « n’est plus maintenu » ne sont pas la même chose

  • MinIO manquait déjà de transparence et s’éloignait de l’esprit open source, en supprimant des issues critiques ou en verrouillant les commentaires
    Je suis donc passé à Garage dès qu’il est passé en mode maintenance
    Je prépare une PR, mais je ne l’ai pas encore soumise

    • Ce genre de projet demande des compétences avancées, donc je ne vois pas pourquoi il faudrait s’occuper des utilisateurs gratuits
      La plupart des projets open source sérieux sont soutenus par l’industrie, et il est difficile pour un développeur web ordinaire d’y contribuer

  • Je recommande de faire un fork et de le conserver en local au cas où le dépôt MinIO serait supprimé
    Sur GitHub, si un dépôt public est supprimé, les forks restent, mais s’il passe en privé, les forks disparaissent aussi
    Quelque chose de similaire est arrivé avec la gem prawn_plus dans l’écosystème Ruby
    Voir la documentation GitHub sur la politique des forks
    Pour ceux qui n’utilisaient MinIO que pour des tests locaux, cela peut devenir un piège qui se referme progressivement

  • Si vous exploitez des solutions d’observabilité qui exigent un object storage, comme Thanos, Loki, Mimir ou Tempo
    il peut être pertinent d’envisager VictoriaMetrics, VictoriaLogs, VictoriaTraces à la place
    Elles reposent sur du block storage et peuvent monter à l’échelle du pétaoctet, tout en offrant de hautes performances et une forte disponibilité sans nécessiter d’administration manuelle