Alternatives auto-hébergées à S3 en 2026 (RustFS, Garage, SeaweedFS, Ceph)
Opter pour un S3 auto-hébergé après MinIO
Amazon S3 est devenu l’API de facto pour le stockage d’objets. Après l’archivage du dépôt open source MinIO en avril 2026, sept alternatives auto-hébergées crédibles subsistent.
Ces options ne sont pas interchangeables. Certaines sont des moteurs de stockage d’objets complets qui gèrent leur propre structure de données ; d’autres sont de simples passerelles qui exposent des fichiers que vous possédez déjà. Cette distinction — entre magasin natif et passerelle basée sur un système de fichiers — détermine davantage les questions de sauvegarde, de récupération et de migration que n’importe quelle liste de fonctionnalités.
Cet article compare RustFS, Garage, SeaweedFS, Ceph RGW, VersityGW, S3Proxy et rclone. Chaque section couvre le modèle de stockage, la couverture des fonctionnalités S3, l’adéquation du projet à vos besoins, et la limitation qui détermine généralement le choix. Un guide décisionnel pour les déploiements sur serveur unique et multi-serveurs conclut l’article.
Pour une vision plus large — stockage d’objets, bases de données, recherche et couches de données natives à l’IA — voir Infrastructure de données pour les systèmes d’IA.
Comparatif des stockages S3 auto-hébergés
La question la plus importante est de savoir si vous avez besoin d’un magasin d’objets distribué ou d’une interface S3 devant un stockage qui existe déjà.
| Logiciel | Modèle de stockage | Distribué | Compatibilité S3 | Fichiers bruts sur disque | Complexité | Utilisation optimale |
|---|---|---|---|---|---|---|
| RustFS | Magasin d’objets natif | Oui | Élevée, sous-ensemble testé | Non | Faible à moyenne | Remplacement général de MinIO |
| Garage | Magasin d’objets natif | Oui | Bonne, API plus étroite | Non | Faible à moyenne | Petits clusters distribués |
| SeaweedFS | Magasin distribué de blobs et fichiers | Oui | Élevée | Non | Moyenne | Très grands volumes de fichiers et stockage mixte |
| Ceph RGW | Passerelle d’objets Ceph | Oui | Élevée | Non | Élevée | Infrastructure de stockage de grande échelle |
| VersityGW | Passerelle S3 au-dessus de POSIX | Dépend du backend | Bonne | Oui | Faible | S3 au-dessus de fichiers normaux |
| S3Proxy | Couche de traduction S3 | Dépend du backend | Modérée | Oui avec filesystem-nio2 | Moyenne | Passerelle et traduction de protocoles |
| rclone serve s3 | Passerelle S3 | Dépend du backend | Basique, expérimentale | Oui avec backend local | Très faible | Déploiements simples et légers |
RustFS est le remplacement le plus direct pour un déploiement MinIO conventionnel. Garage convient aux petits clusters distribués. SeaweedFS et Ceph résolvent des problèmes de stockage plus larges. VersityGW peut exposer un système de fichiers POSIX existant via S3 tout en conservant les charges utiles des objets sous forme de fichiers ordinaires. Pour une matrice de fonctionnalités détaillée entre Garage, MinIO et AWS S3, voir Garage vs MinIO vs AWS S3.
Deux types différents de stockage S3
Un magasin d’objets natif gère sa propre structure de stockage :
RustFS, Garage, Ceph RGW et SeaweedFS appartiennent à cette famille. Les fichiers visibles sur les disques sous-jacents sont des détails d’implémentation, et les applications ne devraient pas les manipuler directement.
Une passerelle S3 basée sur un système de fichiers entretient une relation différente avec le stockage :
Avec des logiciels tels que VersityGW, le système de fichiers peut rester la représentation autoritative. Un objet tel que :
s3://archive/documents/2026/report.pdf
peut correspondre directement à :
/storage/archive/documents/2026/report.pdf
RustFS : Le remplacement le plus proche de MinIO
RustFS est un système de stockage d’objets distribué écrit en Rust et publié sous licence Apache-2.0. Il offre un modèle opérationnel orienté S3 familier pour les utilisateurs de MinIO, ce qui en fait le premier projet à évaluer lors du remplacement de MinIO.
Son implémentation S3 actuelle couvre les opérations attendues par la plupart des applications : seaux (buckets), objets, téléversements multipart, requêtes conditionnelles, métadonnées d’objets, étiquettes, versioning, gestion du cycle de vie, verrouillage d’objets, URL présignés, politiques de seau, CORS, notifications, configuration de réplication et chiffrement côté serveur.
RustFS publie une matrice de compatibilité S3 qui est un sous-ensemble testé, et non une revendication de couverture complète d’Amazon S3. L’instantané vérifié par rapport au commit 1e6f5f1e au 9 août 2026 liste 455 tests standard implémentés, 5 tests de comportement du cycle de vie, 17 tests standard non implémentés et 270 cas exclus qui ne bloquent pas le contrôle de compatibilité. Les listes exécutables situées dans scripts/s3-tests sont la source de vérité lorsque ces compteurs évoluent.
Quand RustFS est approprié
RustFS est un candidat idéal lorsqu’une application s’attend à un vrai magasin d’objets S3.
Les utilisations typiques incluent le stockage d’objets applicatif, les dépôts de sauvegarde, le stockage de médias, les artefacts de pipelines de données et d’IA, l’infrastructure S3 interne, les charges de travail Kubernetes et le remplacement des points de terminaison MinIO existants.
Il fonctionne avec les SDK AWS et les clients S3 courants. Les applications nécessitent normalement un point de terminaison personnalisé, des identifiants, des paramètres de région le cas échéant, et une adresses en style chemin (path-style).
La limitation importante
RustFS possède la représentation du stockage. Les fichiers sous son répertoire de données sont des éléments internes de RustFS.
Cela rend RustFS la mauvaise réponse lorsque la exigence est que chaque objet S3 reste un fichier ordinaire que vous pouvez inspecter, copier, rsync, ou récupérer sans le logiciel de stockage d’objets. Cette exigence sélectionne une passerelle basée sur un système de fichiers.
Garage : S3 distribué sans la complexité de Ceph
Garage est un magasin d’objets distribué compatible S3 pour les installations auto-hébergées de petite et moyenne taille. Deuxfleurs le développe sous licence AGPL v3 et l’exploite en production depuis les premières versions du projet en 2020.
Garage est conçu pour fonctionner sur plusieurs serveurs ordinaires, y compris des serveurs situés dans des emplacements physiques différents. La réplication fait partie de la conception.
Garage est attractif lorsque vous avez trois petits serveurs plutôt qu’un rack de matériel de stockage dédié. Un chemin de configuration fonctionnel, de Docker jusqu’à la disposition du cluster, la réplication et le TLS via un proxy inverse, se trouve dans le Guide de démarrage rapide Garage.
Quand Garage est approprié
Garage a du sens pour les homelabs, les petites plateformes d’hébergement, les serveurs géographiquement distribués, les sauvegardes répliquées et les clusters où Ceph serait excessif.
Son périmètre est plus étroit que celui d’AWS S3. Le tableau de compatibilité de Garage omet les politiques de seau, les ACL et le versioning de seau. Choisissez Garage plutôt que RustFS lorsque la réplication multi-nœuds légère est l’exigence principale. Choisissez RustFS lorsque des comportements S3 plus larges et une compatibilité applicative type MinIO sont plus importants.
SeaweedFS : Bien plus qu’un magasin d’objets
SeaweedFS a commencé par stocker efficacement des nombres énormes de fichiers. C’est aujourd’hui une plateforme de stockage distribuée exposant S3, un système de fichiers FUSE, WebDAV, SFTP et HDFS. SeaweedFS 4.48 a été publié le 28 septembre 2026.
Les serveurs de volume empilent des blobs dans des fichiers de volume en ajout uniquement (append-only). Les maîtres suivent les volumes plutôt que les fichiers individuels. Un filer fournit des sémantiques de système de fichiers hiérarchiques. La conception cible les charges de travail avec des millions ou des milliards d’objets relativement petits.
Support S3
SeaweedFS documente le versioning, le verrouillage d’objets, les règles de cycle de vie, l’étiquetage, le CORS, les sommes de contrôle, les URL présignés, les téléversements multipart, les politiques de seau, l’IAM, le STS et plusieurs modes de chiffrement côté serveur.
Le même cluster peut servir des seaux de table S3 et un catalogue REST Iceberg intégré, de sorte que Spark, Trino, DuckDB et des moteurs similaires puissent utiliser des tables Iceberg sans un Hive Metastore ou Glue séparé. L’exemple S3 en une commande du projet écoute sur le port 8333.
Quand SeaweedFS est approprié
Envisagez SeaweedFS pour les robots d’indexation et les archives, les dépôts d’images et de documents, les milliards d’objets petits, les lacs de données, les charges de travail mixtes S3 et système de fichiers, et les stockages qui croissent en ajoutant des serveurs de volume.
Il y a plus de composants à comprendre que dans une installation RustFS directe. SeaweedFS peut fournir des sémantiques de système de fichiers via son filer et son montage FUSE, mais les objets sont stockés dans son format de volume. Il ne satisfait pas l’exigence que chaque objet S3 reste un fichier ordinaire indépendant sur le système de fichiers hôte.
Ceph RGW : L’option à l’échelle de l’infrastructure
Ceph est plus large que le stockage S3. Un cluster peut fournir des périphériques bloc via RBD, un système de fichiers via CephFS, et du stockage d’objets via RADOS Gateway (RGW). RGW présente une API compatible S3 soutenue par RADOS.
Ceph prend en charge la réplication, le codage par code correcteur, les domaines de défaillance, plusieurs passerelles, les déploiements multi-sites, les politiques d’accès et les outils de gestion de cluster.
Quand Ceph est approprié
Ceph a du sens lorsque le stockage d’objets est une partie d’une plateforme de stockage plus large : volumes persistants Kubernetes, disques de machines virtuelles, systèmes de fichiers partagés, grands dépôts S3 et clusters ayant besoin de domaines de défaillance explicites.
Pour un seul serveur avec plusieurs téraoctets, installer Ceph uniquement pour obtenir un point de terminaison S3 est difficile à justifier. Si vous exploitez déjà Ceph, RGW est le choix S3 évident. Si vous ne le faites pas, RustFS ou Garage atteint un stockage d’objets utile avec moins de mécanismes.
VersityGW : S3 sur des fichiers ordinaires
VersityGW est l’option à évaluer lorsque le système de fichiers lui-même est important. C’est une passerelle S3 sous licence Apache-2.0 qui peut exposer des systèmes de fichiers POSIX, ScoutFS, Azure Blob Storage, d’autres services S3 et des backends personnalisés.
Son backend POSIX mappe les seaux et objets S3 sur des répertoires et des fichiers. Par exemple :
s3://website-assets/images/logo.png
se mappe vers un chemin tel que :
/storage/website-assets/images/logo.png
La charge utile de logo.png reste un fichier normal.
Pourquoi les fichiers bruts sont utiles
Vous pouvez inspecter le stockage avec des outils Unix ordinaires :
find /storage -type f
du -sh /storage/*
Vous pouvez lire un objet sans le serveur S3 :
cat /storage/archive/2026/source.html
Les outils de sauvegarde de système de fichiers conventionnels s’appliquent directement : rsync, restic, borg, tar et zfs send. Si le logiciel de passerelle disparaît, les charges utiles sont toujours des fichiers dans un arbre de répertoires.
Métadonnées S3 sur un backend POSIX
Les métadonnées S3 ne tiennent pas dans un fichier POSIX par elles-mêmes. VersityGW les stocke par défaut dans des attributs étendus. Depuis mars 2026, les métadonnées d’objet sont un seul xattr user.metadata contenant du JSON, car un xattr par clé atteignait les limites de longueur de clé du système de fichiers. La commande versitygw utils convert-xattr-metadata réécrit les anciens attributs par clé. Les lectures repassent toujours à l’ancienne structure si user.metadata est absent.
Les systèmes de fichiers sans xattrs peuvent utiliser --sidecar (ou VGW_META_SIDECAR) pour conserver les métadonnées dans un arbre de répertoires séparé. Le projet marque sidecar et --nometa comme moins testés que les xattrs. --nometa désactive le stockage des métadonnées et vise l’hébergement en lecture seule d’un jeu de données existant ; les politiques de seau et les ACL sont des métadonnées, donc elles sont indisponibles dans ce mode.
Les versions d’objets peuvent vivre dans un répertoire séparé. L’exemple POSIX du projet passe --versioning-dir pour les anciennes versions tandis que la charge utile actuelle reste à son chemin naturel.
Modifier un fichier derrière la passerelle peut laisser les métadonnées S3, y compris les ETags, incohérentes avec les nouveaux octets. Un modèle opérationnel viable est :
Accès applicatif :
Lecture via S3
Écriture via S3
Accès administrateur :
Lire le système de fichiers directement
Inspecter le système de fichiers directement
Sauvegarder le système de fichiers directement
Éviter de modifier les objets derrière la passerelle
VersityGW 1.8.0, déjà la version visée par une version du pilote COSI de septembre 2026, ajoute un service IAM autonome (versitygw iam), AssumeRoleWithWebIdentity STS et des conditions de politique IAM.
S3Proxy : Une couche de traduction générale
S3Proxy implémente l’API S3 et traduit les requêtes vers plusieurs backends : fichiers locaux, Azure Blob Storage, Google Cloud Storage, OpenStack Swift, SFTP et d’autres services S3. Il nécessite Java 17 ou plus récent.
Le fournisseur sur disque recommandé est filesystem-nio2. L’ancien fournisseur filesystem est déprécié. Les clés d’objets deviennent des chemins de système de fichiers, et les métadonnées utilisent des attributs étendus d’utilisateur, de sorte que les charges utiles restent des fichiers ordinaires.
Le backend système de fichiers refuse le versioning d’objets et le chiffrement côté serveur. Le versioning reste non supporté (supportsVersioning() est faux, et ces requêtes restent HTTP 501) car une structure de version écrite sur un disque réel deviendrait un format que le projet devrait maintenir. Le chiffrement côté serveur est refusé pour la même catégorie de raisons : déclarer AES256 sur un fichier en clair que quelqu’un peut lire serait une fausse déclaration. Le backend en mémoire transient-nio2 implémente les deux, et les données meurent avec le processus. Le README du projet liste également les politiques de seau, l’étiquetage d’objets et les ACL autres que private et public-read comme non supportés.
S3Proxy est l’outil lorsque vous avez besoin de cette traduction entre backends. Pour une passerelle S3-vers-POSIX directe, VersityGW offre une surface plus petite.
rclone serve s3 : Léger mais expérimental
rclone serve s3 expose un backend rclone via une API compatible S3. La documentation qualifie toujours la commande d’expérimentale.
Pour un système de fichiers local :
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
Sans --addr, le serveur se lie à 127.0.0.1:8080. --auth-key active la Version 4 de la signature. Les téléversements multipart sont écrits dans l’ordre du numéro de partie vers un objet temporaire et renommés en place à la fin, de sorte qu’un téléversement échoué ne remplace pas un objet existant.
Les objets écrits via un backend local deviennent des fichiers sous ce chemin. La même commande peut se placer devant d’autres distants rclone. C’est un choix raisonnable pour les outils internes, un laboratoire ou un saut de migration temporaire. C’est une couche S3 permanente faible pour de nombreuses applications de production non liées.
Qu’en est-il de MinIO ?
Le dépôt GitHub de MinIO a été archivé le 13 février 2026, brièvement désarchivé, puis archivé à nouveau le 25 avril 2026. Il est en lecture seule. L’avis du dépôt oriente les opérateurs vers AIStor, la distribution commerciale de MinIO, et indique que l’édition communautaire est uniquement disponible en source.
Un déploiement MinIO existant peut continuer à fonctionner, en particulier lorsqu’il est isolé et que son comportement est déjà compris. La chronologie complète, le risque opérationnel et un plan de migration par phases sont dans MinIO CE en 2026.
Pour le comportement S3 du système que vous pouvez quitter, MinIO comme alternative à AWS S3 documente comment MinIO se mappe sur S3. La fiche de triche en ligne de commande MinIO est le compagnon d’audit pour un cluster qui est toujours en ligne. Pour une nouvelle installation, une alternative activement maintenue est la valeur par défaut.
Fichiers bruts vs Stockage d’objets natif
Utilisez RustFS, Garage, SeaweedFS ou Ceph lorsque le magasin d’objets doit contrôler la durabilité, les métadonnées, la distribution et la structure. Cela offre des sémantiques S3 plus riches, la réplication ou le codage par code correcteur, le scaling horizontal et le versioning si le projet l’implémente. Le coût est la dépendance à la représentation sur disque du moteur.
Utilisez VersityGW, S3Proxy ou rclone lorsqu’un système de fichiers existant doit rester autoritatif. Cela offre des fichiers récupérables bruts, des sauvegardes conventionnelles, une inspection directe et la compatibilité avec ZFS, XFS, ext4 et NFS. La durabilité distribuée doit alors venir du système de fichiers ou de la baie de stockage, et non du processus S3. Sur un seul serveur ou un NAS, ce compromis est souvent le bon.
Choisir le bon serveur S3 auto-hébergé
Pour un seul serveur qui doit ressembler à MinIO, commencez par RustFS.
Pour trois serveurs modestes ou plus où la réplication est l’exigence principale, et où l’application peut vivre sans politiques de seau et versioning, choisissez Garage.
Pour des nombres énormes d’objets petits, un accès mixte système de fichiers, ou une charge de travail de lac de données qui peut évoluer vers des tables Iceberg, envisagez SeaweedFS.
Lorsque le même cluster doit également fournir des périphériques bloc et un système de fichiers distribué, choisissez Ceph RGW.
Lorsque l’exigence est spécifiquement une API S3 sur des fichiers ordinaires — un NAS, une archive, un dépôt de documents, un robot d’indexation ou une cible de sauvegarde — commencez par VersityGW.
Lorsque le travail consiste à traduire S3 vers Azure, GCS, Swift, SFTP ou un autre service S3, utilisez S3Proxy.
Lorsque le déploiement est petit, temporaire et peut tolérer un serveur expérimental, rclone serve s3 peut suffire.
Architecture recommandée pour un serveur de stockage unique
Si les applications doivent accéder aux données uniquement via S3, RustFS possède la couche d’objets et le système de fichiers est un détail d’implémentation :
Si les fichiers eux-mêmes doivent survivre à la passerelle, gardez les données dans un arbre POSIX :
Dans la deuxième conception, la redondance est un miroir ZFS, un RAID, des instantanés, une réplication de système de fichiers, ou un outil de sauvegarde conventionnel. Le service S3 peut être remplacé sans réécrire le format de données.
Pensées finales
Le S3 auto-hébergé est toujours existant et maintenu après que le dépôt public de MinIO soit passé en lecture seule. Le choix qui compte est de savoir si S3 possède les octets ou s’il ne fait que servir de façade à des fichiers qui existent déjà. Toutes les comparaisons ci-dessus découlent de cette réponse.
