Ce que Garage est, et ce qu'il n'est pas
Garage est un magasin d'objets compatible S3 pensé pour les déploiements auto-hébergés de petite taille, éventuellement répartis sur plusieurs sites. Il tient dans un conteneur, n'a pas besoin d'un serveur de base de données à côté, et sur un déploiement mono-nœud il consomme quelques mégaoctets de mémoire au repos.
Ce qu'il n'est pas, il faut le dire tout de suite : Garage n'a pas de console web. L'administration passe par l'outil en ligne de commande garage et par une interface d'administration HTTP. Ce n'est pas une fonction oubliée, c'est un choix : le service reste petit et sa surface d'exploitation étroite. Des projets communautaires proposent une interface dans le navigateur par-dessus l'interface d'administration si vous y tenez.
Si vous cherchiez ce point précis parce que MinIO a retiré sa console de l'édition communautaire en 2025 — puis cessé de publier ses images Docker communautaires — la réponse honnête est que Garage ne vous rendra pas cette console. Il vous rend en revanche un projet dont la licence AGPLv3 ne réserve aucune fonction à une édition payante.
Ce que Garage fait bien sur un VPS
- API S3 standard : compatible avec
awsCLI,rclone,mc,restic, les SDK Python/Go/Rust et la quasi-totalité des clients S3 du marché. - Empreinte mémoire minime : quelques mégaoctets au repos — il cohabite sans friction avec un serveur web, une base de données ou un reverse proxy sur le même VPS.
- Pas de dépendance externe : ni PostgreSQL, ni Redis, ni etcd. Le moteur de métadonnées est embarqué (LMDB ou SQLite au choix).
- Réplication optionnelle : en mono-nœud, un seul disque suffit ; en multi-nœuds, Garage réplique les objets entre machines, même sur des sites différents.
- Licence AGPLv3 franche : aucune fonctionnalité réservée à une édition payante, pas de limite sur le volume ni sur le nombre de compartiments.
- Sous-domaines virtuels : Garage gère le routing
<bucket>.s3.votre-domaine.com, ce qu'attendent certains clients S3 et SDK.
Prérequis : dimensionner votre VPS pour un storage bucket
Garage lui-même est frugal — c'est le volume de données que vous stockez qui décide de la taille du disque, pas le service. Un VPS d'entrée de gamme suffit à faire tourner le daemon. Pour une utilisation typique (sauvegardes applicatives, assets d'un site) :
- CPU : 1 vCPU suffit ; Garage est peu intensif en calcul.
- RAM : 512 Mo disponibles sont confortables ; le moteur LMDB tient ses index en mémoire mappée.
- Disque : SSD NVMe de la taille de vos données, plus 20 % de marge pour les métadonnées. Un nœud unique conserve une seule copie de vos objets — planifiez en conséquence.
- OS : Debian 12 ou Ubuntu 22.04 LTS, Docker et le plugin Compose installés.
Pour installer Docker en une commande :
curl -fsSL https://get.docker.com | shConfiguration minimale du storage bucket
Garage lit un fichier garage.toml. Pour un nœud unique, l'essentiel tient en quelques lignes — notez le replication_factor = 1, qui dit explicitement qu'il n'y a pas de réplication :
metadata_dir = "/var/lib/garage/meta"
data_dir = "/var/lib/garage/data"
db_engine = "sqlite"
replication_factor = 1
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "127.0.0.1:3901"
rpc_secret = "<64 caractères hexadécimaux>"
[s3_api]
s3_region = "garage"
api_bind_addr = "[::]:3900"
root_domain = ".s3.votre-domaine.com"
[admin]
api_bind_addr = "[::]:3903"
admin_token = "<jeton d'administration>"Le rpc_secret doit faire 32 octets, soit 64 caractères hexadécimaux : openssl rand -hex 32. Le root_domain détermine le schéma de sous-domaine pour le routing par compartiment — remplacez-le par votre domaine réel.
Déployer Garage et créer votre premier compartiment S3
Créer la structure de répertoires
Commencez par créer un dossier de travail et le fichier de configuration :
mkdir -p /opt/garage/config openssl rand -hex 32 # → copiez ce secret dans rpc_secret openssl rand -base64 32 | tr -d '=' | head -c 40 # → admin_tokenÉcrivez le
garage.tomldans/opt/garage/config/, en remplaçant les deux jetons générés ci-dessus.Écrire le Compose et démarrer
Depuis la version 2.3, Garage monte une grappe d'un seul nœud et crée son premier compartiment automatiquement, à partir de variables d'environnement. Cela évite la séquence manuelle
layout assign/layout apply/bucket create/key create:services: garage: image: dxflrs/garage:v2.3.0 restart: unless-stopped command: ["/garage", "-c", "/etc/garage/garage.toml", "server", "--single-node", "--default-bucket"] environment: GARAGE_DEFAULT_BUCKET: mon-compartiment GARAGE_DEFAULT_ACCESS_KEY: GK<30 hex> GARAGE_DEFAULT_SECRET_KEY: <64 hex> ports: - "127.0.0.1:3900:3900" - "127.0.0.1:3903:3903" volumes: - ./config:/etc/garage - garage-meta:/var/lib/garage/meta - garage-data:/var/lib/garage/data volumes: garage-meta: garage-data:L'image est distroless : pas de shell, entrypoint vide. La commande doit nommer le binaire en chemin absolu (
/garage) et passer le fichier de configuration (-c). Sans ces deux éléments, le conteneur boucle surNo such file or directory.La clé d'accès S3 doit avoir la forme
GKsuivi de 30 caractères hexadécimaux exactement — c'est la forme que Garage attend.Démarrez :
docker compose up -dVérifier que l'API répond
Un appel anonyme sur l'API S3 doit répondre 403 — c'est le signe que le service est vivant et refuse une requête non signée :
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3900/ # 403 → l'API répondL'interface d'administration répond 200 avec le jeton :
curl -H "Authorization: Bearer $ADMIN_TOKEN" http://127.0.0.1:3903/v2/ListBucketsSi vous obtenez
connection refused, le conteneur n'a pas démarré — vérifiezdocker compose logs garage.Exposer l'API derrière nginx et un certificat TLS
Ne publiez jamais le port 3900 directement sur l'interface publique. Publiez-le sur la boucle locale et laissez nginx faire le proxy et le certificat TLS. Un bloc minimal pour
s3.votre-domaine.com:server { listen 443 ssl; server_name s3.votre-domaine.com *.s3.votre-domaine.com; ssl_certificate /etc/letsencrypt/live/s3.votre-domaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/s3.votre-domaine.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3900; proxy_set_header Host $host; } }Le certificat wildcard
*.s3.votre-domaine.comcouvre les sous-domaines par compartiment. Utilisez certbot en mode DNS-01 pour l'obtenir. C'est ce que fait l'installation en un clic du Marketplace.Tester avec un client S3
Avec les variables d'environnement positionnées,
awsCLI fonctionne sans modification :export AWS_ACCESS_KEY_ID=GK... export AWS_SECRET_ACCESS_KEY=... export AWS_DEFAULT_REGION=garage # Lister les compartiments aws --endpoint-url https://s3.votre-domaine.com s3 ls # Déposer un fichier aws --endpoint-url https://s3.votre-domaine.com s3 cp monFichier.txt s3://mon-compartiment/ # Avec rclone rclone lsd garage:mon-compartimentPour
restic, configurez la variableRESTIC_REPOSITORY=s3:https://s3.votre-domaine.com/mon-compartimentetRESTIC_PASSWORD— la commanderestic initinitialise le dépôt de sauvegardes.
Cas d'usage courants d'un storage bucket S3 auto-hébergé
Un storage bucket Garage sur VPS couvre plusieurs besoins courants sans dépendance à un cloud tiers.
Ce qu'on déploie derrière Garage
- Sauvegardes restic ou Borg : configurez votre dépôt de backup en pointant vers
s3:https://s3.votre-domaine.com/backups. La compatibilité S3 est native dans restic depuis sa première version. - Origine d'un site statique : stockez les assets compilés de votre frontend et servez-les via nginx ou Cloudflare en mode proxy. Aucune requête S3 signée n'atteint le client final.
- Stockage d'uploads applicatifs : vos applications Laravel, Django ou Rails peuvent écrire dans Garage via leur SDK S3 habituel, sans changer une ligne de code — seul l'endpoint change.
- Artefacts CI/CD : GitHub Actions ou GitLab CI peuvent pousser les artefacts de build vers Garage avec
aws s3 cp, au même titre que vers S3 d'AWS. - Logs et métriques d'archivage : Loki, Vector ou Fluentd savent écrire dans un stockage objet compatible S3 pour l'archivage long terme.
- Partage de fichiers entre services : deux conteneurs sur le même VPS ou sur deux VPS différents accèdent au même compartiment via l'API S3, sans montage NFS.
Garage vs alternatives S3 auto-hébergées
Faites défiler le tableau
| Critère | Garage | MinIO (communautaire) |
|---|---|---|
| Licence | AGPLv3 — sans restriction d'usage | AGPLv3, mais console retirée de l'édition libre en 2025 |
| Images Docker | Publiées activement sur Docker Hub (`dxflrs/garage`) | Images communautaires arrêtées en 2025 sur Docker Hub |
| Console web | Absente (CLI + API admin) | Console supprimée de l'édition communautaire |
| Multi-sites | Nativement prévu (zones géographiques) | Possible mais requiert un cluster dédié |
| Empreinte mémoire | Quelques Mo au repos | Plusieurs dizaines de Mo en entrée |
| Compatibilité S3 | Bonne sur la surface courante | Très étendue, y compris extensions AWS |
Compartiments, accès et permissions
Garage gère les accès à la clé : chaque clé S3 peut être autorisée sur un ou plusieurs compartiments, en lecture seule ou lecture-écriture. Pour une sauvegarde automatisée, créez une clé dédiée avec accès au seul compartiment de backup — pas à l'ensemble du serveur.
La commande garage key create <nom> génère une clé, et garage bucket allow --key <id> --read --write <compartiment> lui donne les droits. Vous pouvez aussi passer par l'API d'administration en HTTP si vous préférez l'automatiser dans un script.
Ce qu'il faut garder en tête
Un nœud unique n'est pas de la redondance. Garage sait répliquer entre plusieurs machines, éventuellement sur des sites différents — c'est même sa raison d'être. Mais tant que vous n'avez qu'un nœud, vos objets existent en un seul exemplaire, sur un seul disque. Gardez la discipline de sauvegarde que vous auriez de toute façon — une sauvegarde de votre bucket de sauvegardes vers un second emplacement (bande, autre serveur, cloud) n'est pas un luxe.
Exposez l'API derrière un domaine et du TLS, pas sur une IP nue. C'est à la fois une exigence de sécurité et une nécessité pratique : plusieurs clients S3 refusent de fonctionner sans TLS, et le routing par sous-domaine de compartiment exige un certificat wildcard.
La compatibilité S3 porte sur la surface courante, pas sur chaque extension propre à AWS. Les clients, bibliothèques et outils de sauvegarde standard fonctionnent sans modification ; si vous dépendez d'un appel inhabituel (Object Lambda, S3 Select, Replication cross-account…), vérifiez-le dans la documentation du projet avant de migrer.
Surveillez l'espace disque. Un bucket de sauvegardes qui grossit sans politique de rétention remplit le disque silencieusement. Configurez une règle de cycle de vie ou un cron qui purge les snapshots anciens via garage bucket lifecycle.