versitygw transforme un système de fichiers en serveur S3 avec un seul binaire
Le gateway S3 de Versity, un binaire Go stateless sous licence Apache-2.0, expose n’importe quel stockage POSIX derrière l’API S3, sans déployer MinIO ni Ceph. Les auto-hébergeurs qui veulent brancher Restic, rclone ou Velero sur leur NAS y trouvent un pont plus léger qu’un object store complet.
Semaine du 11 au 18 septembre 2026. Le Versity S3 Gateway — versitygw — fait son entrée dans les radars de l’auto-hébergement : un binaire Go stateless, sous licence Apache-2.0, qui traduit l’API S3 vers un système de fichiers POSIX, ScoutFS, Azure Blob ou un autre serveur S3. Pourquoi c’est important : l’API S3 est devenue l’espéranto du stockage, et ce gateway évite de déployer un object store complet juste pour brancher un outil qui parle S3.
L’API S3 est devenue le protocole universel
Regardez votre boîte à outils : Restic, rclone, Velero, Duplicati, Kopia, les clients de sauvegarde les plus répandus parlent tous S3. Le résultat est une situation étrange — des outils conçus pour l’objet ont supplanté les outils fichiers, alors que la plupart des homelabs stockent encore leurs données sur de simples filesystems POSIX.
La réponse classique est de déployer MinIO, voire Ceph, pour offrir une vraie API S3 au-dessus de ce stockage. C’est puissant, mais c’est une infrastructure de plus à maintenir : déploiement, mises à jour, surveillance, et une surface d’attaque supplémentaire. versitygw propose l’inverse : une traduction inline entre les commandes objet S3 et le stockage existant, sans changer ce stockage.
Ce que fait le gateway, précisément
versitygw est un serveur S3 qui intercepte les requêtes S3 et les convertit en opérations sur un backend. Le projet revendique quatre cas d’usage : transformer un système de fichiers local en serveur S3 avec une seule commande, proxifier des requêtes S3 vers un autre stockage S3, offrir une compatibilité de protocole en mode posix — les mêmes fichiers sont accessibles en POSIX ou en S3 — et fournir une interface simplifiée pour ajouter de nouveaux backends.
Le point décisif est le mode posix : les objets écrits par un client S3 restent des fichiers lisibles, et inversement. Un répertoire partagé NFS ou un disque local peut donc être consommé à la fois par un script shell et par un outil S3 comme rclone, sans duplication. Le déploiement tient en une ligne :
mkdir /tmp/vgw /tmp/vers
ROOT_ACCESS_KEY="testuser" ROOT_SECRET_KEY="secret" \
./versitygw --port :10000 --iam-dir /tmp/vgw \
posix --versioning-dir /tmp/vers /tmp/vgwCette commande monte un serveur S3 sur le port 10000, héberge le répertoire /tmp/vgw, stocke les versions antérieures dans /tmp/vers et active des comptes IAM simples en fichiers JSON plats via --iam-dir.
Un binaire, mais pas un jouet
Ne confondez pas « simple à déployer » avec « minimal ». versitygw embarque une WebGUI optionnelle d’administration et d’exploration, le S3 Select, les métriques, les notifications d’événements et le multipart upload. Deux fonctions sortent du lot pour les gros volumes :
- S3 over RDMA : via vgwrdma, le gateway expose l’API S3 accélérée par le protocole NVIDIA cuObject (GPUDirect Storage), qui contourne la pile réseau du noyau. C’est pensé pour le HPC et les charges intensives en données, pas pour un NAS familial — mais la brique existe et signale l’ambition du projet.
- Hébergement de site statique : un bucket peut être servi comme site web, avec document d’index, pages d’erreur et routage par hôte virtuel.
Côté robustesse, le projet est explicite : chaque pull request doit passer une suite de tests complète avant revue, avec tests unitaires Go, scripts d’intégration multi-backends, tests fonctionnels de bout en bout via le SDK AWS, validation système avec AWS CLI, s3cmd et curl, et analyse staticcheck. La revue de code est humaine — les LLM peuvent assister mais ne décident jamais seuls. Le tout est distribué en binaires pour Linux, macOS, BSD et Windows (amd64/arm64), plus une image Docker et un chart Helm.
Stateless : la vraie carte maîtresse
L’architecture est complètement stateless. Plusieurs instances versitygw peuvent être déployées en cluster derrière un load balancer : n’importe quelle instance peut traiter n’importe quelle requête, ce qui permet d’augmenter le débit agrégé en ajoutant des nœuds, sans coordination d’état. C’est ce qui distingue un gateway de traduction d’un object store : versitygw ne stocke rien, il traduit.
La conséquence pratique est importante pour l’auto-hébergement. Ajouter l’API S3 à un stockage existant ne devrait pas doubler la surface d’exploitation ; avec un gateway stateless, on ajoute un processus jetable, pas un système de stockage à administrer. Si le gateway tombe, on en relance un autre ; les données, elles, restent dans le filesystem.
versitygw face à MinIO
La question évidente : pourquoi ne pas installer MinIO ? La réponse tient au modèle d’architecture. MinIO est un object store complet — il possède ses propres métadonnées, son erasure coding, ses politiques de cycle de vie et son IAM multi-tenant. versitygw est un traducteur : il ne stocke rien, il expose des fichiers existants derrière l’API S3.
Conséquence pratique : si vos données vivent déjà sur un filesystem — un pool ZFS, un volume NFS, un disque local — versitygw les rend accessibles en S3 sans migration ni duplication. MinIO exige, lui, de faire de ses volumes l’autorité de stockage. Le déploiement en Docker tient en quelques lignes :
docker run --rm -p 10000:10000 \
-e ROOT_ACCESS_KEY=testuser \
-e ROOT_SECRET_KEY=secret \
-v /srv/data:/data \
versity/versitygw:latest --port :10000 posix /dataLe compromis est à la hauteur de la simplicité. versitygw ne propose pas d’erasure coding ni de lifecycle aussi riche que MinIO ; il compte sur le filesystem sous-jacent pour la redondance et la durabilité. Pour un homelab ou un petit parc, c’est souvent exactement ce qu’il faut : la robustesse de ZFS pour les données, l’API S3 pour l’interopérabilité, et rien de plus à administrer.
La lisibilité POSIX est l’autre argument. Avec MinIO, les objets sont enfermés dans un format interne ; avec versitygw en mode posix, chaque objet reste un fichier que l’on peut lire avec ls, grep ou un éditeur. C’est un confort de dépannage non négligeable quand un backup doit être inspecté à la main, à trois heures du matin. Enfin, le modèle de licence est un signal : Apache-2.0 pour le cœur, sans restriction d’usage commercial, ce qui élimine le risque de bascule open-core que traversent d’autres projets du secteur. Côté sécurité, le mode --iam-dir fournit des comptes IAM en fichiers JSON plats pour un usage simple ; pour du multi-tenant sérieux, le gateway délègue à l’OIDC et aux backends d’authentification de l’écosystème S3. L’essentiel reste de ne jamais exposer le port S3 directement sur Internet sans TLS — le binaire le supporte nativement.
Verdict
Si vous voulez brancher Restic, rclone ou Velero sur un stockage POSIX que vous possédez déjà, déployez versitygw : un binaire, une commande, et vos outils S3 parlent à vos fichiers sans héberger un object store complet. Si vous avez besoin de vraies sémantiques objet — politiques de cycle de vie, erasure coding, IAM multi-tenant à grande échelle, versioning massif — restez sur MinIO ou Ceph, qui font ce travail en profondeur. Si vous proxifiez du S3 vers un autre S3 ou cherchez une passerelle RDMA pour du HPC, versitygw mérite un test sérieux : son architecture stateless et sa suite de tests en font un candidat crédible, pas un projet de week-end.