Garage : un object store S3 conçu pour la géo-réplication

MinIO reste le réflexe quand on cherche un object store S3-compatible self-hosted, mais son design vise avant tout la performance dans un même datacenter. Pour des cas d'usage qui imposent une réplication entre plusieurs sites distants, avec de la latence et des liens parfois capricieux, l'approche atteint vite ses limites.

Garage propose une autre stratégie : un object store distribué leaderless, taillé pour la géo-réplication, basé sur les principes du papier Dynamo et sur des CRDT pour gérer les conflits sans coordinateur central. Cet article détaille l'architecture, le déploiement, la compatibilité S3 réelle et les cas où Garage prend l'avantage sur les alternatives plus connues.

• Qu'est-ce que Garage
• Architecture : leaderless, Dynamo, CRDT
• Modèle de réplication géographique
• Compatibilité S3 : ce qui marche, ce qui ne marche pas
• IAM Garage vs ACL S3
• Déploiement d'un cluster
• Comparaison Garage vs MinIO
• Cas d'usage pertinents
• Licence AGPLv3 : ce que ça implique

Garage est un object store S3-compatible open source développé par Deuxfleurs, un collectif français d'hébergement associatif. Le projet existe depuis 2020 et est utilisé en production par Deuxfleurs et plusieurs autres acteurs du fédiverse pour héberger Mastodon, PeerTube, Matrix, Nextcloud.

La dernière version stable au moment de la rédaction est la v2.3.0, publiée le 16 avril 2026. Le code est distribué sous licence AGPLv3.

Le positionnement diffère nettement de MinIO ou Ceph RGW :

1. Géo-distribution comme cas d'usage prioritaire : Garage est pensé d'emblée pour des clusters dont les nœuds sont répartis sur plusieurs sites physiques distants, avec de la latence (jusqu'à 200 ms) et des liens à 50 Mbps minimum.
2. Leaderless, sans coordinateur : aucun nœud n'est maître. Le routage des requêtes et la cohérence reposent sur du hashing cohérent et des CRDT, à la manière de Dynamo et Cassandra.
3. Empreinte minimale : un binaire Rust unique, démarrant sur 1 Go de RAM et 16 Go de disque, capable d'absorber des téraoctets en production.

Garage s'inspire directement du papier Dynamo (Amazon, 2007) et du modèle Cassandra. Trois choix de design structurent le système.

Hashing cohérent pour le routage. Chaque objet est identifié par une clé qui, hashée, désigne les nœuds responsables de son stockage. Aucun service de coordination type ZooKeeper ou etcd. Les nœuds connaissent la topologie du cluster et calculent localement quelle machine doit recevoir l'écriture.

CRDT pour les métadonnées. Les opérations qui modifient les métadonnées (création de bucket, gestion des clés d'accès, listes d'objets) reposent sur des Conflict-Free Replicated Data Types. Deux nœuds qui reçoivent des modifications concurrentes en partition réseau peuvent fusionner leurs états une fois la connexion rétablie, sans conflit ni coordinateur.

Cohérence configurable. Le paramètre replication_factor détermine le nombre de copies (3 recommandé). Les niveaux de cohérence sont ajustables selon les besoins, mais le défaut vise un compromis lecture/écriture qui reste disponible même si certains nœuds sont injoignables.

                 ┌──── Site Toulouse ────┐
                 │  ┌──────┐  ┌──────┐   │
                 │  │ G1   │  │ G2   │   │
                 │  └──────┘  └──────┘   │
                 └───────────┬───────────┘
                             │
        ┌────────────────────┼────────────────────┐
        │                    │                    │
┌───── Site Lyon ─────┐  WAN/VPN  ┌──── Site Bordeaux ───┐
│  ┌──────┐  ┌──────┐ │           │  ┌──────┐  ┌──────┐  │
│  │ G3   │  │ G4   │ │           │  │ G5   │  │ G6   │  │
│  └──────┘  └──────┘ │           │  └──────┘  └──────┘  │
└─────────────────────┘           └──────────────────────┘

         replication_factor = 3, une copie par site

Le cœur de la valeur ajoutée de Garage est sa gestion des zones. Chaque nœud déclare sa zone (typiquement un site physique). Garage répartit les copies de chaque objet de manière à ce que les replication_factor copies soient sur des zones différentes, automatiquement.

Concrètement, avec replication_factor=3 et trois zones (Toulouse / Lyon / Bordeaux), chaque objet existe en trois exemplaires, un par zone. La perte d'une zone entière laisse encore deux copies disponibles. La lecture peut s'effectuer depuis n'importe quelle zone, sans surcharge réseau interzone.

Le système tolère :

• La perte d'un nœud dans une zone (le second nœud de la zone prend le relais).
• La perte d'une zone entière (les deux autres zones restent en service).
• Un partitionnement réseau temporaire : les nœuds isolés continuent de servir les lectures locales et fusionnent les écritures à la reconnexion via les CRDT.

Cette résilience est obtenue sans bascule manuelle ni élection de leader. C'est ce qui distingue Garage des solutions où un site primaire et un site secondaire sont définis explicitement.

Garage implémente un sous-ensemble de l'API S3, documenté précisément dans la page S3 compatibility status. À jour de la v2.3.0 :

Cette liste mérite d'être lue avant toute décision. L'absence de versioning est le point qui élimine Garage pour certains workflows (sauvegarde S3 avec rétention par version, conformité réglementaire qui impose l'immuabilité). L'absence de chiffrement côté serveur est compensée par le chiffrement côté client (la doc renvoie vers un aws s3 cp --sse ou un chiffrement applicatif).

À l'inverse, les fonctionnalités présentes (multipart, presigned URLs, lifecycle minimal) couvrent largement les cas d'usage des applications fédérées : Nextcloud, Mastodon, PeerTube, Matrix fonctionnent sans modification.

Là où S3 expose un système ACL/Policies par bucket, Garage propose son propre modèle : une matrice d'autorisation par clé d'accès et par bucket. Trois permissions élémentaires : read, write, owner.

# Créer une clé d'accès
garage key create my-app-key

# Créer un bucket
garage bucket create photos

# Donner les droits à la clé sur le bucket
garage bucket allow --read --write --key my-app-key photos

Pas de notion de policy JSON, pas d'utilisateurs IAM imbriqués, pas de rôles. C'est volontairement minimaliste. Les bucket aliases permettent à plusieurs utilisateurs d'avoir un bucket nommé identiquement sans collision (chaque alias est local à un utilisateur).

Le contrepoint : si une application S3 attend des policies (par exemple un outil de gestion de droits déclaratifs), il faudra adapter le workflow ou utiliser un autre object store.

Garage se déploie soit en binaire natif, soit en container. Voici un docker-compose minimal pour un nœud :

services:
  garage:
    image: dxflrs/garage:v2.3.0
    container_name: garage
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./garage.toml:/etc/garage.toml:ro
      - ./meta:/var/lib/garage/meta
      - ./data:/var/lib/garage/data

Configuration minimale dans garage.toml :

metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "lmdb"

replication_factor = 3
consistency_mode = "consistent"

rpc_bind_addr = "[::]:3901"
rpc_public_addr = "10.0.1.10:3901"
rpc_secret = "<random hex 64 chars>"

[s3_api]
api_bind_addr = "[::]:3900"
s3_region = "garage"
root_domain = ".s3.garage.example.com"

[s3_web]
bind_addr = "[::]:3902"
root_domain = ".web.garage.example.com"
index = "index.html"

[admin]
api_bind_addr = "[::]:3903"
admin_token = "<random hex 32 chars>"

Une fois trois nœuds démarrés, on les relie et on assigne les zones :

# Sur le noeud 1, récupérer son ID
garage node id

# Sur le noeud 2 et 3, les connecter au noeud 1
garage node connect <node1-id>@10.0.1.10:3901

# Définir le layout : 3 noeuds, 3 zones, 100 Go par noeud
garage layout assign <node1-id> -z toulouse -c 100G -t toulouse-1
garage layout assign <node2-id> -z lyon     -c 100G -t lyon-1
garage layout assign <node3-id> -z bordeaux -c 100G -t bordeaux-1

# Appliquer le layout
garage layout show
garage layout apply --version 1

Le cluster est opérationnel. L'endpoint S3 est disponible sur le port 3900 de chaque nœud.

Les deux projets sont S3-compatibles et open source, mais leurs cibles diffèrent.

Pour un usage multi-DC, Garage est plus simple à opérer et plus tolérant aux liens réseau imparfaits. Pour un usage intensif en lecture/écriture dans un même rack, MinIO offre plus de fonctionnalités et une meilleure densité grâce à l'erasure coding.

Garage prend tout son sens dans plusieurs contextes.

Stockage souverain multi-sites

Pour une organisation qui dispose de plusieurs salles ou datacenters distribués sur le territoire et qui veut un object store S3-compatible sans dépendre d'un cloud provider, Garage est la voie la plus simple. La géo-réplication native évite de construire une couche au-dessus d'un MinIO + DNS failover ou d'un Ceph RGW multi-site.

Backend pour applications fédérées

Mastodon, PeerTube, Matrix Synapse, Nextcloud fonctionnent nativement sur Garage. Pour un acteur qui héberge ces services en interne ou pour ses clients, Garage offre un stockage durable sans surdimensionnement.

Backups 3-2-1 chez plusieurs hébergeurs

Le scénario classique : un cluster Garage à trois nœuds, un par hébergeur (par exemple Asolta, Scaleway, OVH), avec replication_factor=3 et une zone par hébergeur. Chaque écriture est répliquée chez les trois fournisseurs simultanément. La perte d'un fournisseur entier n'entraîne aucune perte de donnée et le service reste disponible. Combiné à Restic ou rclone côté client, on obtient une stratégie de sauvegarde géographiquement diversifiée sans verrou propriétaire.

Object store pour hébergement web mutualisé

Pour un hébergeur qui veut proposer un endpoint S3 à ses clients pour leurs assets, leurs backups WordPress, ou leurs CDN d'origine, Garage présente l'avantage d'une opération simple. Le multi-tenancy via clés d'accès et bucket aliases couvre l'isolation des clients sans complexité IAM.

Garage est sous AGPLv3, licence copyleft à propagation réseau. Implications concrètes :

• Usage interne sans modification : aucune obligation, aucun engagement.
• Modification de Garage : si vous modifiez le code et que vous l'utilisez pour fournir un service accessible en réseau à des tiers (clients, utilisateurs), vous devez publier vos modifications sous AGPLv3.
• Inclusion dans un produit propriétaire : à éviter sans audit légal préalable.

Pour la majorité des déploiements (usage interne, hébergeur qui n'a pas modifié le code), l'AGPLv3 ne change rien à l'opération quotidienne. Pour un projet qui envisage de patcher Garage et de le commercialiser sous une autre forme, c'est une étude juridique à mener.

• MinIO sur Kubernetes : object store S3-compatible
• Stratégie de sauvegarde 3-2-1
• Lifecycle S3 et archivage
• Sauvegardes Restic vers MinIO via Rclone
• Cloud souverain : enjeux et options

• Garage HQ (site officiel Deuxfleurs) présentation, architecture
• Documentation Garage, déploiement, configuration, opération
• S3 compatibility status, liste exhaustive des endpoints supportés
• Forge Deuxfleurs (releases) version v2.3.0, changelog
• Dépôt miroir GitHub, code source

Garage occupe un créneau bien défini : object store S3-compatible leaderless et géo-distribué, là où la majorité des alternatives sont conçues pour un seul datacenter. Le compromis assumé est une compatibilité S3 partielle (pas de versioning, pas de SSE, pas de policies) en échange d'une opération radicalement plus simple sur des clusters multi-sites. Pour des charges qui réclament toute la richesse de l'API S3 ou de très hautes performances dans un même rack, MinIO ou Ceph RGW restent les bonnes options. Pour de la résilience géographique sans coordinateur ni complexité opérationnelle, Garage est une réponse difficile à battre.