W3CSVG

Gérer un espace de stockage S3 sur son homelab

Dec 11, 2025

Dans un environnement Homelab, la gestion du stockage constitue rapidement un sujet central. À mesure que les services se multiplient – conteneurs, applications auto-hébergées, solutions de sauvegarde, pipelines CI/CD – la nécessité d’un système de stockage à la fois flexible, résilient et accessible devient incontournable. Le protocole S3, initialement conçu par Amazon Web Services, s’est imposé comme un standard de facto pour le stockage objet en raison de son universalité et de sa simplicité d’intégration.

L’objectif de cet article est d’expliquer pourquoi il est pertinent de disposer d’un espace de stockage compatible S3 dans un Homelab, d’exposer les difficultés rencontrées avec MinIO, puis de détailler les alternatives crédibles telles que SeaweedFS ou Garage. Une implémentation concrète de SeaweedFS sera également présentée.

Pourquoi faut-il avoir un stockage S3 dans son home lab

Le protocole S3 est devenu une pierre angulaire du stockage objet. Même dans un Homelab, il répond à une large variété de besoins qu’un simple partage de fichiers ou une solution NAS traditionnelle ne suffit pas à couvrir.

La majorité des applications modernes savent fonctionner avec un backend S3 :

  • systèmes de sauvegarde (Restic, Velero, Borg via gateways)
  • plateformes multimédias ou d’archivage
  • solutions Kubernetes (OpenShift, Longhorn, Harbor, etc.)
  • outils DevOps pour stocker artefacts et journaux

Disposer d’un S3 local devient alors un excellent moyen de comprendre les workflows modernes tout en augmentant la robustesse de son Homelab. Il présente plusieurs avantages :

  • isoler les données des services applicatifs
  • séparer stockage fichier et stockage objet
  • simplifier les sauvegardes et restaurations
  • s’initier aux concepts utilisés dans les environnements professionnels

La trahison de MinIO

MinIO a longtemps été considéré comme la solution de référence pour disposer d’un S3 auto-hébergé. Léger, performant et simple à déployer, il dominait clairement le segment Homelab. Cependant, plusieurs évolutions de son modèle et de son positionnement ont modifié la donne.

Changements de licence et restrictions d’usage

MinIO a adopté une politique de licence beaucoup plus restrictive, orientée vers une monétisation accrue. Certaines fonctionnalités avancées ne sont plus accessibles librement, et la distinction entre usage communautaire et usage commercial est devenue floue, créant de l’incertitude même pour les environnements personnels avancés.

Dégradation de l’expérience pour les utilisateurs Homelab

Plusieurs utilisateurs ont observé :

  • une complexification des mises à jour
  • des limitations pour certaines configurations distribuées
  • une communication moins transparente sur les évolutions

Pour beaucoup, MinIO n’est plus la solution ouverte, stable et accessible qu’elle était. D’où la nécessité de se tourner vers des alternatives réellement adaptées à un Homelab.

Les options de remplacement : SeaweedFS ou Garage

Deux solutions émergent clairement aujourd’hui comme remplaçantes crédibles : SeaweedFS et Garage. Chacune propose une approche différente du stockage objet, avec des avantages spécifiques selon l’usage.

SeaweedFS : performance et flexibilité

SeaweedFS est un système de fichiers distribué dont l’un des modules expose une API S3 complète. Points forts :

  • très haute performance grâce à un design orienté volume/chunks
  • architecture modulaire (master, volume server, filer, S3 gateway)
  • excellente scalabilité même dans un Homelab
  • GitOps plus simple à mettre en oeuvre
  • Gratuit si inférieur à 30 TB

SeaweedFS convient aux environnements où performance et modularité sont prioritaires.

Garage : simplicité et robustesse

Garage est une solution écrite en Rust, pensée dès le départ pour les petits clusters et les environnements auto-hébergés. Points clés :

  • installation minimaliste
  • résilience très élevée grâce à un consensus léger
  • faible consommation de ressources
  • Communautaire et esprit libre
  • Français

Garage est idéal pour un cluster peu puissant ou pour un opérateur cherchant une solution stable, sans complexité.

Choisir entre les deux

  • Pour une architecture modulaire, scalable et très performante : SeaweedFS.
  • Pour une solution simple, distribuée et économique : Garage.

J’ai décidé de partir sur la solution de Seaweedfs pour son aspect modulaire et la facilité à scripter la mise en place des systèmes dans mon environnement que j’essaie d’être le plus possible GitOps.

Impléméntation de Seaweedfs

Comprendre l’architecture

SeaweedFS repose sur quatre composants principaux :

  • Master Server : gestion des métadonnées et du placement des volumes.
  • Volume Servers : stockage physique des données.
  • Filer : interface POSIX/structured pour le stockage.
  • S3 Gateway : exposition de l’API S3 compatible AWS.

Il y a également une interface d’administration web en Alpha que j’ai installé sur mon cluster. L’objectif était de pouvoir débugger des problématique de connexion entre les différents services. Je reviendrai dessus plus tard.

Déploiement avec docker

Pour déployer dans mon homelab, j’utilise docker compose qui va me permettre de gérer toutes les ressources dans un seul document. Cependant j’ai besoin de fichiers de configuration pour le filer et l’API S3. L’arborescence de mon dossier est la suivante :

seaweedfs/
├── config/
│   ├── filer.toml
│   └── s3.json
├── nginx/
│   └── seaweedfs.conf
├── docker-compose.yml
└── generate_s3_keys.sh

Le filer.toml est très simple et reprend le fichier proposé dans le wiki de seaweedfs.

[leveldb2]
enabled = true
dir = "/data/filerldb2"

[redis2]
enabled = false

[mongodb]
enabled = false

[mysql2]
enabled = false

[postgres2]
enabled = false

Le S3.json va lui reprendre la configuration des profils pour chaque Bucket que je vais gérer. Pareil assez simple puisqu’il est basé sur le template du wiki.

{
  "identities": [
    {
      "name": "admin_user",
      "credentials": [
        {
          "accessKey": "your_access_key",
          "secretKey": "your_secret_key"
        }
      ],
      "actions": ["Admin", "Read", "Write", "List", "Tagging"]
    },
    {
      "name": "readonly_user",
      "credentials": [
        {
          "accessKey": "readonly_key",
          "secretKey": "readonly_secret"
        }
      ],
      "actions": ["Read", "List"]
    }
  ]
}

Le dossier Nginx contient le fichier de configuration que je mettrai dans /etc/nginx/sites-available/ pour mettre le service disponible derrière mon proxy.

Maintenant la partie la plus importante, la mise en place du docker file. Voici la version finale :

services:
  master:
    image: chrislusf/seaweedfs:latest
    command: "master -volumeSizeLimitMB 10240 -ip=master -port=9333 -mdir=/data -defaultReplication=000"
    restart: unless-stopped
    networks:
      - seaweed_net
    volumes:
      - ./data/master:/data
    # Aucun port exposé

  volume:
    image: chrislusf/seaweedfs:latest
    command: "volume -mserver=master:9333 -port=8080 -dir=/data -max=3"
    restart: unless-stopped
    depends_on:
      - master
    networks:
      - seaweed_net
    volumes:
      - ./data/volume:/data
    # Aucun port exposé

  admin:
    image: chrislusf/seaweedfs:latest
    command: "admin -port=23646 -masters=master:9333"
    restart: unless-stopped
    depends_on:
      - master
    networks:
      - seaweed_net
    ports:
      - "23646:23646"

  filer:
    image: chrislusf/seaweedfs:latest
    command: 'filer -master="master:9333" -ip=filer -port=8888'
    restart: unless-stopped
    depends_on:
      - master
      - volume
    networks:
      - seaweed_net
    volumes:
      - ./config/filer.toml:/etc/seaweedfs/filer.toml:ro
      - ./data/filerldb2:/data/filerldb2
    # Aucun port exposé

  s3:
    image: chrislusf/seaweedfs:latest
    command: "s3 -filer=filer:8888 -port=8333 -ip.bind=0.0.0.0 -config=/etc/seaweedfs/s3.json"
    restart: unless-stopped
    depends_on:
      - master
      - volume
      - filer
    networks:
      - seaweed_net
    volumes:
      - ./config/s3.json:/etc/seaweedfs/s3.json:ro
    ports:
      - "8333:8333"

networks:
  seaweed_net:
    name: seaweed_net

Les pièges à éviter

J’ai rencontré plusieurs difficultés lors de l’implémentation de ce système.

  1. Le localhost dans la commande console fait référence au localhost du contenaire et pas au réseau docker. Pensez donc à mettre le nom des hostnames à la place.
  2. Si le fichier ne suit pas le langage attendu par seaweedfs, il ne sera pas pris en compte et sans message d’erreur.
  3. Les buckets peuvent être déclarés même s’ils n’existent pas.
  4. Si l’instance S3 n’a pas configuré ip.bind, elle n’écoutera que sur localhost. Il est donc primordial de le configurer.
  5. Ne pas faire confiance à ChatGPT ou Deepwiki qui sortent des paramètres qui n’existent pas.

Une fois ces pièges évités, vous devriez avoir un service up and running !