VaultS3 se présente comme une nouvelle alternative pour déployer un stockage d’objets compatible S3 d’Amazon dans une infrastructure autonome, avec une approche peu courante : un seul binaire, sans services externes obligatoires, et une consommation en veille que son développeur situe autour de 17 MiB de mémoire. Le projet vise un marché où cohabitent des services gérés comme Amazon S3 et des plateformes open source établies comme Ceph, Garage ou SeaweedFS.

L’essentiel : VaultS3 implémente plus de 80 opérations de l’API S3 et fonctionne comme un seul binaire, avec environ 17 MiB de RAM au repos selon son développeur, même si la consommation grimpe sous charge. Il intègre chiffrement, IAM, OIDC, versionnage, Object Lock, métriques Prometheus et codage par effacement. Il vise Ceph, Garage, SeaweedFS et des services gérés comme Amazon S3, mais son mode distribué conserve encore des composants en bêta.

La compatibilité S3 s’est imposée dans une multitude d’architectures de stockage. Applications de sauvegarde, plateformes d’analyse, référentiels de données, Kubernetes et de nombreux outils d’entreprise s’appuient sur cette interface, qu’il s’agisse d’AWS ou d’une infrastructure auto-hébergée. VaultS3 vise précisément cette seconde catégorie, en évitant la complexité des solutions distribuées classiques. Le projet est écrit en Go et distribué sous licence AGPL-3.0.

De 17 MiB au repos à près de 185 MiB en charge

Ce qui saute aux yeux d’abord, c’est la faible consommation mémoire. Selon les tests publiés par le projet, VaultS3 utilise environ 17 MiB de RAM à l’arrêt, ce qui ne veut pas dire qu’il gère n’importe quelle charge de stockage avec cette quantité. Dans un test d’écriture d’objets de 64 MiB avec 16 opérations simultanées, la consommation grimpe jusqu’à environ 185 MiB. La mémoire nécessaire dépend donc du nombre de connexions, de la taille des objets et de la charge du serveur, et les comparaisons disponibles viennent surtout du projet lui-même plutôt que d’un benchmark indépendant. Mieux vaut donc lire ces 17 MiB comme un indicateur de la légèreté du processus de base, pas comme une exigence fixe pour la production.

VaultS3 concentre l’essentiel de ses fonctionnalités dans un seul exécutable, sans base de données externe pour démarrer : les métadonnées passent par BoltDB. Le projet propose aussi des images Docker, des paquets pour plusieurs distributions Linux et des options pour Kubernetes, avec une interface web intégrée, l’authentification Signature Version 4 d’AWS, IAM, une intégration OIDC et LDAP, un chiffrement AES-256-GCM, des politiques par bucket, des métriques Prometheus et plusieurs mécanismes de protection des données.

VaultS3 face à Ceph, Garage et SeaweedFS

Le stockage compatible S3 compte plusieurs alternatives, ce qui rend le seul critère de la consommation mémoire insuffisant pour trancher.

Solution	Modèle	API S3	Complexité	Orientation principale
VaultS3	Open source, AGPL-3.0	Oui	Basse en mono-nœud	Laboratoires, edge, hébergements légers
Ceph	Open source	Oui, via RGW	Élevée	Clusters d’entreprise et stockage distribué
Garage	Open source	Oui	Moyenne-basse	Stockage distribué léger
SeaweedFS	Open source	Oui	Moyenne	Stockage distribué objets/fichiers
MinIO AIStor	Commercial, tier gratuit limité	Oui	Moyenne	Stockage S3 d’entreprise
Amazon S3	Service cloud géré	Natif	Basse côté utilisateur	Object storage à grande échelle

Ce tableau ne désigne pas de vainqueur, tant les architectures diffèrent. Ceph appartient à une catégorie à part : il peut offrir stockage d’objets, blocs et fichiers sur un seul cluster distribué, avec un RGW qui implémente une large part de l’API S3, versionnage, cycle de vie, politiques, chiffrement, IAM et configuration multisite comprise — un périmètre qui explique pourquoi Ceph continue de s’imposer comme référence du stockage distribué d’entreprise. Cette puissance a un coût opérationnel : déployer Ceph suppose de gérer plusieurs composants et généralement plusieurs serveurs ou OSD pour obtenir une plateforme redondante, la documentation recommandant souvent au moins trois OSD pour la haute disponibilité. VaultS3 vise presque l’extrême opposé : démarrer avec un serveur modeste et une configuration simple.

Garage mérite aussi la comparaison, conçu avec une philosophie de stockage distribué relativement léger, adapté à du matériel et des connexions hétérogènes. VaultS3 tente de se distinguer en intégrant dans le même projet des fonctions supplémentaires d’administration et de protection des données. SeaweedFS, de son côté, va plus loin qu’un simple serveur S3 : son architecture distribuée mobilise plusieurs composants pour gérer volumes, métadonnées et accès, ce qui ouvre plus de possibilités de déploiement mais aussi un ensemble plus complexe à administrer.

MinIO n’est plus vraiment ce qu’il était il y a quelques années

Impossible de faire l’impasse sur MinIO, longtemps la référence pour déployer du stockage compatible S3 hors AWS. Son contexte commercial et sa licence ont changé : MinIO est passé en mode maintenance, un vrai tournant pour le S3 open source. La documentation actuelle précise que MinIO utilise une licence propre pour sa version distribuée, limitant sauf accord Enterprise le logiciel couvert à une instance d’évaluation ou d’usage non productif. La société commercialise désormais sa plateforme sous la famille AIStor, et comparer directement MinIO AIStor à un projet open source comme VaultS3 sous AGPL, en restant sur l’étiquette « stockage S3 open source », risque d’être trompeur. VaultS3 cherche justement à retrouver l’expérience qui a rendu attrayantes les premières plateformes S3 auto-hébergées : télécharger un programme, le lancer, et disposer rapidement d’un endpoint compatible avec les clients S3.

Amazon S3 répond à une autre problématique

L’autre extrême de la comparaison reste Amazon Web Services S3. AWS gère l’infrastructure physique, la redondance, le remplacement du matériel et l’essentiel de la disponibilité. Dans une solution auto-gérée comme VaultS3, ces responsabilités reviennent à l’exploitant des serveurs, ce qui change complètement l’équation économique. Un serveur S3 auto-hébergé peut avoir du sens quand le volume de données locales est important, pour éviter que certaines charges ne quittent l’infrastructure de l’organisation, ou quand le coût de transfert de gros volumes vers le cloud devient élevé — un arbitrage proche de celui qu’on retrouve entre NAS et SAN pour choisir le bon stockage en entreprise. Mais un logiciel seul ne transforme pas automatiquement un serveur en un service équivalent à Amazon S3 : la durabilité finale dépendra de la configuration des disques, des sauvegardes, de la réplication, des serveurs et des centres de données.

Erasure coding et réplication : là où tout se joue encore

VaultS3 ne se contente pas de stocker une seule copie de chaque objet. Il implémente l’erasure coding Reed-Solomon, le versionnage, Object Lock, des sauvegardes programmées et des processus de récupération de fragments endommagés, une logique de protection qu’on retrouve aussi dans le support S3 ajouté par Proxmox Backup Server pour ses sauvegardes. Il propose aussi le clustering via Raft, le hachage cohérent et la réplication active-active. C’est justement là que se trouvent ses principales limites actuelles : le projet distingue lui-même les fonctionnalités stables de celles encore en développement. Les déploiements mono-nœud, y compris avec erasure coding multi-disque, sont les plus matures, tandis que certaines fonctions de clustering et de réplication distribuée restent en bêta.

Pour un labo à domicile, cette nuance compte peu. Pour une entreprise qui veut stocker des téraoctets de sauvegardes ou des données critiques, elle change tout. Un système de stockage ne se juge pas uniquement sur sa consommation mémoire au démarrage : la résilience face aux pannes, la cohérence des données, le comportement lors de partitions réseau, la mise à jour entre versions, la surveillance et la capacité à reconstruire de gros volumes après perte de disques ou de serveurs comptent tout autant.

Une option taillée pour les labos et l’edge, pour l’instant

VaultS3 occupe aujourd’hui un positionnement clair : son faible coût et sa simplicité d’installation en font une option intéressante pour homelabs, petits serveurs, environnements de développement, dispositifs edge ou applications ayant besoin d’un endpoint S3 local. Il peut aussi servir à tester des applications conçues pour S3 sans dépendre en permanence d’un service externe. Pour des déploiements d’entreprise plus importants, Ceph offre une architecture distribuée bien plus mature et un ensemble de fonctionnalités plus large, tandis que les services gérés comme Amazon S3 transfèrent la gestion de l’infrastructure au fournisseur, en échange d’un modèle de consommation et de coûts associés.

VaultS3 cherche à faire la jonction entre ces deux extrêmes. Son vrai test viendra avec la croissance des déploiements et la mise à l’épreuve de ses fonctionnalités distribuées sous charge soutenue, mises à jour et défaillances matérielles. En attendant, ces 17 MiB de RAM au repos rappellent une idée simple : il reste de la marge pour construire un stockage compatible S3 sans avoir besoin d’un cluster complexe dès le départ.

Questions fréquentes

VaultS3 est-il compatible avec Amazon S3 ?

Il implémente plus de 80 opérations de l’API S3 et fonctionne avec des outils et SDK compatibles, sans reproduire pour autant toutes les fonctionnalités d’Amazon S3.

VaultS3 peut-il remplacer Ceph ?

Ça dépend du scénario. VaultS3 mise sur la simplicité et la faible consommation, là où Ceph est conçu pour de vastes systèmes distribués d’objets, blocs et fichiers.

VaultS3 utilise-t-il vraiment seulement 17 MiB de RAM ?

C’est la valeur mesurée par le développeur au repos. En charge, la consommation grimpe, jusqu’à environ 185 MiB lors d’un test d’écriture d’objets de 64 MiB avec 16 opérations concurrentes.

VaultS3 est-il prêt pour la production ?

Sa configuration mono-nœud est la plus mature. Certaines fonctionnalités distribuées, notamment le clustering et la réplication active-active, restent en bêta et demandent des tests approfondis avant de stocker des données critiques.