RustFS 1.0 : une alternative S3 à MinIO, quelle maturité en production ?

RustFS 1.0.0 est disponible depuis le 16 septembre 2026. Ce logiciel de stockage objet distribué, écrit en Rust et publié sous licence Apache 2.0, franchit le cap de sa première version stable. L’équipe le présente désormais comme prêt pour la production. Annonce officielle RustFS.

Cette sortie intervient dans un contexte important pour le stockage S3 auto-hébergé : MinIO Community Edition n’est plus maintenu. Son dépôt officiel a été archivé le 25 avril 2026 et porte explicitement cette mention. Pour les équipes qui l’exploitent, la question est désormais celle de la relève, pas seulement du choix entre deux projets open source actifs. État du dépôt officiel MinIO.

RustFS est une option à examiner pour ces installations, comme pour un nouveau besoin de stockage objet. Il ne devient pas pour autant un successeur équivalent par défaut.

Mais une première version stable ne suffit pas à décider d’une migration. Avant de lui confier des données importantes, il faut distinguer trois sujets : les fonctions disponibles, les preuves d’adoption et le comportement de la plateforme en exploitation.

RustFS : du stockage objet compatible S3

Le stockage objet organise les données dans des compartiments, les buckets. Une application accède à chaque objet par une clé et une API, plutôt que par un disque directement attaché à sa machine virtuelle.

Ce modèle convient notamment aux fichiers déposés par les utilisateurs d’un SaaS, aux médias d’un site, aux exports ou aux artefacts de construction d’une application. Certains outils de sauvegarde utilisent également une destination S3, avec des exigences propres qu’il faut vérifier.

Le dépôt RustFS documente une API compatible S3, des mécanismes de contrôle d’accès, une console et des intégrations d’exploitation. Il précise aussi des limites selon les fonctions : les moteurs KMS Vault et AWS sont annoncés pour la production, tandis que les moteurs Local et Static sont réservés au développement et aux tests. Dépôt et matrice de fonctionnalités RustFS.

L’intérêt pour une infrastructure maîtrisée est concret : choisir où résident les données, comment les accès sont accordés et comment le service est exploité. Ce contrôle suppose en contrepartie de prendre en charge capacité, mises à jour, supervision et reprise après incident.

Ce que change la version 1.0

La version GA marque la sortie du cycle alpha, bêta et release candidate. Dans son annonce, RustFS met notamment en avant les uploads multipart, l’erasure coding, les politiques de cycle de vie, le déploiement distribué et la réplication. Présentation de la version stable.

Ces briques répondent à des besoins différents. L’upload multipart sert aux transferts de gros objets. L’erasure coding répartit données et informations de redondance pour tolérer certaines défaillances. Les règles de cycle de vie permettent d’organiser la conservation des objets.

Leur présence dans une fiche fonctionnelle ne décrit toutefois pas le résultat d’une panne sur votre architecture. La tolérance réelle dépend notamment de la répartition des disques, des nœuds et des domaines de panne. Il faut mesurer ce qui reste accessible pendant une reconstruction, et avec quelles performances.

Un essai concluant doit donc aller plus loin qu’un démarrage réussi et quelques fichiers envoyés depuis la console.

Adoption : une visibilité importante, un recul encore court

À la sortie de la 1.0, le projet revendique plus de 32 000 étoiles GitHub, 160 contributeurs, 10 millions de téléchargements d’images Docker et 2,7 millions d’instances déployées. Son code est ouvert depuis juillet 2025, après un début de développement en février 2024. Chiffres et chronologie publiés par RustFS.

Ces indicateurs témoignent d’un intérêt pour le projet. Ils ne mesurent pas tous la même chose : une étoile exprime une attention, un téléchargement peut provenir d’un test ou d’un pipeline, et une instance ne correspond pas nécessairement à un client de production.

La méthode de comptage des instances n’est pas détaillée dans cette annonce. Nous ne disposons donc pas, à partir de ces chiffres, d’une mesure vérifiable du nombre de clusters critiques exploités durablement.

Au 21 septembre 2026, la version stable a cinq jours. C’est trop court pour disposer d’un recul sur ses mises à jour successives, ses restaurations et ses incidents en production à grande échelle.

Les retours de bêta montrent ce qu’il faut tester

Un retour utilisateur publié le 4 août sur le dépôt documente les difficultés rencontrées avec les versions bêta 11 et 12 : saturation mémoire suivie de cycles de récupération, échecs d’écriture avec quotas, problèmes d’upload multipart et incompatibilités avec un registre de conteneurs.

L’auteur précise qu’il n’a pas constaté de perte d’objets. Le ticket est désormais fermé. Il porte sur des bêtas et ne démontre pas que ces défauts existent encore dans la 1.0. Retour d’exploitation, ticket RustFS nº 5716.

Son enseignement reste utile : des points de contrôle de santé répondaient correctement alors que certaines opérations applicatives échouaient. Pour qualifier un stockage, il faut donc tester la chaîne complète, depuis l’application qui écrit jusqu’à celle qui relit les données.

Une console disponible et un service qui répond en HTTP ne suffisent pas à prouver qu’un registre, une application métier ou une sauvegarde fonctionne correctement.

Après MinIO Community : préparer la relève et vérifier la compatibilité

L’arrêt de la maintenance de MinIO Community ne signifie pas l’arrêt de toutes les offres MinIO. L’éditeur poursuit AIStor, vers lequel renvoie désormais le dépôt communautaire. Cette distinction compte : remplacer une installation Community et choisir une offre de l’éditeur ne sont pas la même décision. Dépôt officiel MinIO.

AIStor dépasse le seul service de stockage objet S3. Sa présentation actuelle rassemble stockage objet, tables Apache Iceberg pour l’analytique et mémoire persistante pour les agents IA. Le stockage compatible S3 reste toutefois une composante de l’offre : AIStor n’est donc pas réservé aux applications d’intelligence artificielle. Présentation officielle d’AIStor.

Pour un besoin limité à des buckets applicatifs, notre comparaison porte sur le service S3, ses conditions de licence, son support et ses contraintes d’exploitation, pas sur l’ensemble des fonctions orientées IA. L’arrêt de MinIO Community justifie de préparer une trajectoire de migration ; il ne dispense pas de qualifier RustFS avant de lui transférer les données.

Une API commune facilite l’évaluation d’un autre fournisseur de stockage. Elle ne garantit pas que chaque comportement soit identique.

Avant une migration depuis MinIO, la recette doit couvrir les opérations réellement utilisées : uploads interrompus puis repris, URLs présignées, métadonnées, pagination des listes, droits, versionnement et suppression. Si un outil exige du verrouillage d’objets ou une rétention particulière, cette exigence doit être validée explicitement sur la version retenue.

Il faut également distinguer compatibilité de l’API S3 et compatibilité des données sur disque. Le dépôt RustFS indique que l’interopérabilité avec le format disque MinIO reste en preview, derrière une option de compilation. Il précise que les objets chiffrés par MinIO ne sont pas lisibles par RustFS dans ce mode. Limites documentées dans le dépôt.

Nous ne conseillerions donc pas de remplacer simplement un binaire sur un volume de production. Une migration doit prévoir une copie contrôlée, une vérification des objets et des métadonnées, une bascule documentée et un retour arrière réaliste.

RustFS peut également être évalué face à Ceph RGW pour un besoin de stockage objet S3. Il ne remplace pas les autres usages de Ceph, notamment le stockage bloc des machines virtuelles. Documentation d’architecture Ceph.

Ce que nous vérifierions avant une mise en production

Notre qualification porterait sur cinq points.

1. Les usages applicatifs. Rejouer les opérations réelles avec les mêmes clients S3, tailles d’objets, droits et niveaux de concurrence.
2. Le fonctionnement dégradé. Tester la perte d’un disque ou d’un nœud, une coupure réseau et le redémarrage après interruption. Mesurer les erreurs et les délais de récupération.
3. L’intégrité et la restauration. Comparer les objets avant et après les essais, contrôler les listes et restaurer depuis une copie indépendante.
4. Les mises à jour. Épingler une version, valider le chemin de migration et documenter les conditions d’un retour arrière. Conserver une image précédente ne garantit pas à lui seul la compatibilité des données.
5. L’exploitation quotidienne. Surveiller capacité, latence, erreurs S3, mémoire et récupération, avec des alertes reliées à une procédure d’intervention.

Ces vérifications doivent être proportionnées au risque. Un cache reconstructible n’exige pas les mêmes garanties que les documents clients d’une plateforme métier.

La redondance interne ne remplace pas non plus une sauvegarde indépendante. Une suppression autorisée ou une compromission peut affecter un stockage parfaitement disponible. Les objectifs de restauration doivent être définis avant la bascule, comme pour tout PRA et ses engagements RTO/RPO.

Notre lecture : un candidat à qualifier, sans précipiter les migrations

RustFS mérite désormais un pilote pour les équipes qui évaluent un stockage S3 auto-hébergé. Nous commencerions par un environnement de recette ou des données reconstructibles, puis par un périmètre limité dont la restauration est maîtrisée.

Pour un stockage critique, notre décision dépendrait des résultats obtenus sur la version stable, du comportement sous incident et des conditions de support. Nous ne le retiendrions pas par défaut comme copie unique de données importantes ou comme dépôt principal de sauvegarde sans cette qualification.

Cette analyse repose sur les publications et la documentation disponibles au 21 septembre 2026 ; elle ne constitue pas un retour d’exploitation de RustFS par Forget About IT.

La 1.0 rend l’évaluation pertinente. La mise en production doit rester une décision mesurée, fondée sur vos données et vos contraintes.

FAQ : RustFS, MinIO et stockage S3

Qu’est-ce que RustFS ?

RustFS est un logiciel de stockage objet distribué écrit en Rust et publié sous licence Apache 2.0. Son API compatible S3 permet de l’évaluer pour héberger des objets applicatifs sur une infrastructure maîtrisée.

RustFS est-il prêt pour la production ?

L’équipe déclare la version 1.0.0, publiée le 16 septembre 2026, prête pour la production. Le recul sur cette première version stable reste court. Notre recommandation est de qualifier les usages réels, les pannes et les restaurations avant un déploiement critique.

RustFS peut-il remplacer MinIO sans migration ?

La compatibilité S3 ne garantit pas une substitution transparente. Il faut tester les clients, les droits et les opérations utilisées. La compatibilité avec le format disque MinIO est indiquée en preview dans le dépôt consulté et comporte notamment une limite sur les objets chiffrés par MinIO.