Comparatif des gestionnaires de fichiers auto-hébergés

Ce qu’est un gestionnaire de fichiers auto-hébergé, et ce qu’il n’est pas

Un gestionnaire de fichiers auto-hébergé est une page web qui donne accès à l’arborescence de répertoires déjà présente sur votre VPS (virtual private server). Vous vous connectez, vous voyez /srv/files exactement comme il se trouve sur le disque, puis vous envoyez un fichier, le renommez, le téléchargez ou transmettez un lien. Rien n’est copié dans un deuxième système. Un fichier déposé dans le navigateur est donc un fichier que ls affiche une seconde plus tard.

Les résultats de recherche mélangent souvent ce type d’outil avec des logiciels qui remplissent d’autres fonctions. Les outils de synchronisation conservent une copie de chaque fichier sur chaque appareil. C’est le rôle d’une alternative auto-hébergée à Dropbox. Le stockage objet ne possède pas d’arborescence de répertoires. Il utilise des buckets et une API. Installer MinIO pour un stockage objet compatible S3 répond donc à un autre besoin. Les panneaux d’administration de serveur gèrent la machine, pas les fichiers. C’est le sujet de la comparaison entre Cockpit et Webmin.

Vous avez besoin d’un gestionnaire de fichiers lorsqu’un collègue doit récupérer une archive de 300 MB sur le serveur, ou lorsque vous voulez corriger une faute de frappe dans un fichier de configuration depuis un téléphone. La tâche est limitée, et les outils le sont aussi.

Gardez un point à l’esprit pendant votre lecture. Il s’agit d’une application web qui dispose d’un accès en lecture et en écriture à votre système de fichiers et qui écoute sur un port. Chaque choix présenté ci-dessous concerne en réalité l’étendue du disque à laquelle ce processus peut accéder.

FileBrowser est archivé : lisez ceci avant de l’installer

FileBrowser, le projet filebrowser/filebrowser, est la réponse que donnent encore la plupart des guides. Son README commence désormais par un avertissement :

File Browser sera archivé le 2026-09-01. La dernière release prévue a déjà été publiée. Il n’y aura plus de release, de correction de bug ni de correctif de sécurité.

Le code sous licence Apache 2.0 continue de fonctionner. Les correctifs de sécurité s’arrêtent. Cela est plus important pour cette catégorie de logiciels que pour la plupart des autres, car leur objectif principal est de fournir un accès en écriture à un système de fichiers via HTTP.

Les mainteneurs expliquent comment continuer à l’utiliser. Ces recommandations restent valables quel que soit l’outil choisi : ne l’exposez pas directement sur Internet, placez-le derrière un reverse proxy qui termine TLS (transport layer security) et gère sa propre authentification, laissez le command runner désactivé et exécutez-le sans privilèges dans un conteneur. Ne montez dans ce conteneur que le répertoire que vous souhaitez servir.

Une ligne de ce README est plus importante que les autres. Les sessions sont des JWT (JSON web tokens) autonomes, et non des identifiants gérés côté serveur. Elles ne peuvent donc pas être révoquées. Un token de session divulgué reste valide jusqu’à son expiration, et changer le mot de passe ne l’invalide pas. Si vous conservez FileBrowser, la couche d’authentification placée devant lui fait l’essentiel du travail.

FileBrowser Quantum : le fork qui évolue encore

Le développement actif a été déplacé vers un fork, FileBrowser Quantum (gtsteffaniak/filebrowser), publié sous la forme de l’image gtstef/filebrowser. Il reconstruit la configuration autour d’un seul config.yaml, au lieu de l’ancien mélange de flags de ligne de commande et de paramètres de base de données. La procédure de test rapide documentée :

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  gtstef/filebrowser:beta

Cette commande sert le répertoire courant sur http://localhost, et la première connexion utilise admin / admin. Modifiez ce mot de passe avant que le conteneur soit accessible depuis une autre machine que la vôtre.

Pour une instance persistante, utilisez Compose, montez le répertoire de données plutôt qu’un seul fichier de base de données, et liez le port à localhost :

services:
  filebrowser:
    image: gtstef/filebrowser:beta
    user: "1000:1000"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 127.0.0.1:8080:80
    restart: unless-stopped

La configuration se trouve dans /home/filebrowser/data/config.yaml et la base de données dans /home/filebrowser/data/filebrowser.sqlite. La version 2.0.0 a modifié le format de la base de données et effectue une migration unique. C’est pourquoi la documentation demande de monter un répertoire : un montage portant sur un seul fichier ne laisse aucun emplacement pour le nouveau fichier issu de la migration. Les chemins à l’intérieur de config.yaml sont des chemins du conteneur. Une source dans la configuration lit donc /folder, et non /srv/files. Une inversion de ces chemins produit une liste de fichiers vide sans générer d’erreur, car le répertoire n’existe réellement pas à cet emplacement.

Le projet publie latest et stable, d’environ 60 MB, avec FFmpeg inclus pour les miniatures vidéo, ainsi que stable-slim, d’environ 15 MB, avec uniquement le cœur de l’application. Ces chiffres proviennent de la page d’installation en août 2026. Épinglez le tag choisi. latest change sans vous prévenir, et un gestionnaire de fichiers qui modifie son format de configuration alors que le conteneur fonctionne peut compliquer sérieusement la maintenance.

Pour cet usage, c’est le plus complet des petits outils. Il sert plusieurs sources avec des règles d’inclusion et d’exclusion. Une seule instance peut donc exposer /srv/media et /srv/docs avec des périmètres différents. Les partages ont une durée d’expiration et peuvent être anonymes ou restreints à un utilisateur. L’authentification prend en charge OIDC (OpenID Connect), LDAP (lightweight directory access protocol), les mots de passe avec authentification à deux facteurs et un mode utilisant un proxy header. Ce mode proxy lui permet de fonctionner derrière un single sign-on (SSO) fourni par un serveur Authentik auto-hébergé, au lieu de maintenir une seconde liste d’utilisateurs.

Filestash : une interface unique au-dessus de vos stockages existants

Filestash fonctionne différemment. C’est une interface qui se connecte à un backend. La liste des backends est longue : FTP, SFTP (protocole de transfert de fichiers SSH), S3, SMB, WebDAV, IPFS et une vingtaine d’autres. Filestash convient lorsque les fichiers ne se trouvent pas sur le serveur qui héberge l’interface.

mkdir -p /srv/filestash && cd /srv/filestash
curl -O https://downloads.filestash.app/latest/docker-compose.yml
docker compose up -d

L’image est machines/filestash:latest. Ouvrez http://your_domain:8334. Le premier écran permet de définir le mot de passe administrateur. Faites-le immédiatement. Tant que ce n’est pas fait, la console d’administration est accessible à toute personne qui trouve le port.

Comprenez le modèle d’identité avant de vous appuyer sur Filestash. Filestash ne conserve pas de base de données d’utilisateurs au sens habituel. Les identifiants sont stockés dans votre navigateur, dans des cookies chiffrés, authentifiés et HTTP only. Rien n’est conservé côté serveur, sauf si vous utilisez la fonction de partage. Dans ce cas, Filestash conserve une version chiffrée persistante de vos identifiants. Les « utilisateurs » sont des comptes de stockage : l’identité se trouve dans le backend, dans le compte SFTP ou la clé S3, pas dans Filestash.

Cette conception est claire, mais elle a un coût. La page de tarification indique que l’offre self-hosted gratuite est sous AGPL v3 (GNU Affero General Public License) et autorise jusqu’à 3 utilisateurs. Elle réserve le SSO (SAML, OIDC et LDAP) et le contrôle d’accès par rôles à l’offre self-hosted payante, à partir de $50 par mois, en août 2026. Si votre projet était de placer Filestash devant le SSO de l’entreprise gratuitement, consultez cette page avant de concevoir votre architecture.

SFTPGo : un serveur de protocoles avec une interface web

SFTPGo est le logiciel le plus complet de cette sélection, et celui qui est le plus souvent recommandé pour la mauvaise raison. Il fournit SFTP, HTTP/S, FTP/S et WebDAV sur un système de fichiers local, un système de fichiers local chiffré, un stockage objet compatible S3, Google Cloud Storage, Azure Blob Storage ou un autre serveur SFTP.

Des binaires, des paquets Debian et Ubuntu ainsi qu’une image de conteneur sont publiés. La ligne du dépôt APT actuelle et sa clé de signature figurent sur la page d’installation de la documentation SFTPGo. Le conteneur est le moyen le plus rapide de le démarrer. Remplacez tag par la version souhaitée :

docker run --name some-sftpgo -p 8080:8080 -p 2022:2022 -d "drakkan/sftpgo:tag"

SFTP écoute sur le port 2022 et les interfaces web sur le port 8080. Montez /srv/sftpgo comme volume. Sinon, les comptes et leurs fichiers disparaissent lorsque le conteneur est recréé, car les répertoires personnels des utilisateurs sont définis par défaut sur /srv/sftpgo/data/<username>.

Il existe deux interfaces web. Leur différence est souvent laissée implicite dans les présentations. WebAdmin, à l’adresse /web/admin, est l’interface d’administration. Vous y créez les utilisateurs, les groupes, les dossiers virtuels et les règles d’événement. Vous y définissez également les quotas, les limites de bande passante et les restrictions d’horaires d’accès. WebClient, à l’adresse /web/client, est l’interface destinée aux utilisateurs finaux. Une personne peut y parcourir ses fichiers, modifier ses propres identifiants, configurer l’authentification à deux facteurs et créer des partages.

Ces partages sont les plus complets de cette comparaison. Un utilisateur peut créer des liens HTTP/S pour partager des fichiers et des dossiers, limiter le nombre de téléchargements et d’envois, protéger le partage par un mot de passe, limiter l’accès selon l’adresse IP source et définir une date d’expiration automatique.

Pourquoi cette réserve, alors ? Le modèle de comptes et le serveur de protocoles sont au cœur du produit, pas l’expérience de navigation. Choisissez SFTPGo lorsque d’autres personnes ont besoin de véritables comptes avec des quotas, lorsque des envois arrivent en SFTP ou FTPS depuis un système que vous ne contrôlez pas, ou lorsqu’un même bucket doit apparaître dans les répertoires personnels de plusieurs utilisateurs. Les dossiers virtuels répondent à ce dernier besoin : un dossier reposant sur un disque local, S3, GCS, Azure Blob, SFTP ou HTTP est monté dans plusieurs comptes, avec un quota distinct par utilisateur sur un dossier partagé. Si vous vouliez seulement une page permettant de parcourir /srv/files, cela représente beaucoup de composants pour un besoin aussi simple.

Deux autres points sont à connaître. L’édition Community est publiée sous licence AGPL-3.0-only avec des conditions supplémentaires. Elle coexiste avec une édition Enterprise sous licence commerciale. La connexion OIDC est disponible dans la version open source. Elle associe les utilisateurs du fournisseur d’identité aux administrateurs et aux utilisateurs SFTPGo dans les deux interfaces web. Vous pouvez également désactiver globalement l’interface client avec enable_web_client dans la configuration httpd, ou pour un utilisateur donné en ajoutant HTTP à ses protocoles interdits. Le gestionnaire de fichiers peut ainsi être disponible pour une personne sans l’être pour tout le monde.

Cloud Commander : deux panneaux et un terminal, pour une seule personne

Cloud Commander est un gestionnaire Node.js sous licence MIT, basé sur une interface à deux panneaux, avec un éditeur intégré, une console et un terminal. Installez-le globalement avec npm i cloudcmd -g ou exécutez le conteneur publié :

docker run -it --rm -v ~:/root -v /:/mnt/fs -w=/root -p 8000:8000 coderaiser/cloudcmd

Lisez cette commande avant de l’exécuter. -v /:/mnt/fs monte l’intégralité du système de fichiers de l’hôte dans le conteneur, et l’exemple ~/.cloudcmd.json fournit "root": "/", "auth": false et "console": true. Ainsi, toute personne qui peut atteindre le port 8000 obtient un accès à l’ensemble de votre disque et à une console de commandes sur le serveur. C’est un choix raisonnable pour un ordinateur portable, mais un mauvais choix pour un VPS.

Limitez son périmètre. Le conteneur lit /root/.cloudcmd.json. La commande publiée fournit ce fichier en montant votre répertoire personnel. Conservez donc le montage de configuration et supprimez le reste :

docker run -d --name cloudcmd \
  -v ~/.cloudcmd.json:/root/.cloudcmd.json \
  -v /srv/files:/srv/files \
  -w=/srv/files \
  -p 127.0.0.1:8000:8000 \
  coderaiser/cloudcmd

Dans ce fichier de configuration, définissez "root" sur /srv/files, "auth" sur true avec un "username" et un "password", puis définissez "console" et "terminal" sur false, sauf si vous avez réellement besoin d’un accès au shell depuis le navigateur. Des équivalents en ligne de commande existent également, notamment --root, --auth, --username, --password et --prefix.

Soyez clair sur ses capacités. Il utilise une seule paire d’identifiants, sans restriction par utilisateur, sans quotas et sans liens de partage. C’est un outil personnel. Liez-le donc à localhost comme ci-dessus et utilisez-le via un tunnel :

ssh -L 8000:127.0.0.1:8000 you@your-vps

Ouvrez ensuite http://127.0.0.1:8000 sur votre propre machine. Le gestionnaire de fichiers n’est jamais exposé publiquement. Le seul service exposé à Internet est le daemon SSH que vous avez déjà sécurisé sur votre VPS.

Pourquoi Nextcloud n’est pas le bon outil pour cette tâche

Nextcloud est un bon logiciel, mais ce n’est pas son rôle. C’est une plateforme de collaboration : une application PHP, une base de données, des tâches en arrière-plan, des clients de synchronisation pour ordinateur et un app store. L’utiliser pour obtenir une interface web de /srv/files implique beaucoup de composants pour une petite tâche, avec un décalage fonctionnel précis. Nextcloud conserve les métadonnées des fichiers dans une table de base de données au lieu de lire le répertoire à chaque requête. Les fichiers écrits par rsync ou une tâche cron peuvent donc rester invisibles dans l’interface jusqu’à ce qu’un scan les détecte, avec sudo -u www-data php occ files:scan --all. Un gestionnaire de fichiers liste le contenu du répertoire au chargement de la page : ce décalage n’existe pas.

Conservez Nextcloud pour ce qu’il fait bien : les calendriers, les contacts, la synchronisation et le partage avec des personnes qui attendent un client pour ordinateur. Nextcloud sur un VPS avec Docker, TLS et sauvegardes décrit cette configuration. Si vous l’exécutez déjà et que vous devez seulement afficher un répertoire existant, activez l’application External Storage et arrêtez-vous là. Une deuxième application web avec un accès en écriture au même disque constitue un deuxième élément à maintenir à jour.

Comment l’exécuter sans exposer tout le serveur

Ne le pointez jamais vers /. Le processus peut lire et modifier tout ce que son compte utilisateur peut atteindre. Un jeton de session volé donne donc exactement ce niveau d’accès au système de fichiers. Servez un seul répertoire, /srv/files, et créez-le à cet effet.

Exécutez-le avec un utilisateur non-root et ne montez que ce qu’il doit servir. Dans Compose, cela correspond à user: "1000:1000", ainsi qu’à un bind mount par répertoire, avec :ro sur tout ce qu’il ne doit jamais modifier :

    volumes:
      - /srv/files:/folder
      - /srv/media:/media:ro

Après cette modification, le résultat habituel est que la navigation fonctionne, mais que les téléversements échouent avec permission denied, car l’identifiant utilisateur dans le conteneur n’est pas propriétaire du répertoire situé à l’extérieur. Comparez les deux commandes : docker exec filebrowser id affiche l’utilisateur du conteneur, tandis que ls -ln /srv/files affiche le propriétaire numérique sur l’hôte. Corrigez le problème avec sudo chown -R 1000:1000 /srv/files. Il s’agit du même problème de propriété que PUID et PGID dans les images Docker servent à résoudre.

Liez le port publié à localhost, 127.0.0.1:8080:80, plutôt qu’à 8080:80. Docker écrit ses propres règles netfilter avant celles d’ufw. Un port publié sans restriction reste donc accessible depuis Internet, même lorsque ufw deny 8080 est actif. Placez un reverse proxy devant le service pour gérer TLS. En HTTP non chiffré, le cookie de session circule en clair sur le réseau, et ce cookie donne accès au système de fichiers. Si Compose vous est encore peu familier, Docker Compose sur un VPS présente l’organisation des fichiers supposée par ces exemples.

Ajoutez une couche d’authentification lorsque celle de l’application est limitée. Une authentification HTTP basic au niveau du proxy suffit pour une instance utilisée par une seule personne. Dès que plusieurs personnes sont concernées, utilisez OIDC ou forward auth avec un identity provider. La révocation d’un compte supprimera ainsi l’accès partout.

Désactivez les fonctions supplémentaires. Tout gestionnaire de fichiers qui propose un shell, un exécuteur de commandes ou un terminal dans le navigateur fournit une exécution de code à distance à toute personne disposant d’une session valide. La documentation de FileBrowser recommande de laisser le command runner désactivé, tandis que la configuration d’exemple de Cloud Commander active la console. Prenez cette décision volontairement, et non selon le comportement par défaut.

Ce qui casse en premier et les erreurs que vous verrez

listen tcp :80: bind: permission denied. Linux réserve les ports inférieurs à 1024 aux processus privilégiés. La configuration documentée de FileBrowser Quantum utilise le port 80. Cela fonctionne dans un conteneur, mais échoue dès que vous exécutez le binaire avec un utilisateur non privilégié sur l’hôte. Définissez un port supérieur à 1024 dans config.yaml et laissez le proxy gérer le port 443.

Les téléversements échouent alors que la navigation fonctionne. L’énumération d’un répertoire nécessite r-x, tandis que l’écriture nécessite w. L’interface web affiche une erreur générique. Vérifiez donc d’abord le système de fichiers, plutôt que les journaux de l’application.

413 Request Entity Too Large. Cette erreur vient de nginx, pas du gestionnaire de fichiers. La valeur par défaut de client_max_body_size est de 1 MB. Un téléversement plus volumineux est donc rejeté par le proxy avant même que l’application le reçoive. Définissez client_max_body_size 4096m; dans le bloc server, ou utilisez 0 pour désactiver ce contrôle.

Les fichiers téléversés ont le mauvais groupe. Les nouveaux fichiers appartiennent à l’utilisateur du processus, quelle que soit la configuration du répertoire parent. Cela empêche un second service de lire la même arborescence. Attribuez un groupe commun aux deux services et définissez le bit setgid sur le répertoire avec sudo chmod g+s /srv/files. Les nouveaux fichiers hériteront ainsi du groupe du répertoire.

Tout fonctionne sur le port, mais plus derrière le proxy. Une application servie sous un sous-chemin construit ses liens à partir d’un préfixe qui doit lui être indiqué. Cloud Commander propose --prefix à cet effet. Lorsqu’aucune option de ce type n’existe, attribuez à l’application son propre sous-domaine et proxifiez le chemin racine.

Quel gestionnaire de fichiers auto-hébergé devriez-vous utiliser ?

• Un seul VPS, un ou deux répertoires, des liens de partage avec expiration et éventuellement le SSO plus tard : FileBrowser Quantum.
• Des fichiers stockés ailleurs, dans un bucket S3, sur un hôte SFTP ou sur un NAS via SMB, avec une vue web unique : Filestash, dans les limites de l’offre gratuite.
• D’autres utilisateurs ont besoin de comptes, de quotas et de transferts via SFTP ou FTPS : SFTPGo. Considérez le client web comme une fonction supplémentaire utile, et non comme la raison principale de votre choix.
• Un outil personnel avec un éditeur et un terminal, accessible via un tunnel SSH et jamais publié : Cloud Commander.
• Nextcloud est déjà installé et vous avez un répertoire existant à exposer : l’application External Storage, sans installer de nouveau logiciel.

Quel que soit votre choix, le déploiement compte davantage que le logiciel. Utilisez un seul répertoire, un utilisateur non-root, un port lié à localhost et une authentification en amont. Configuré ainsi, un gestionnaire de fichiers est un outil pratique. Le même logiciel pointé vers / avec un mot de passe partagé devient un shell distant avec une interface agréable.

FAQ

FileBrowser peut-il toujours être utilisé en toute sécurité en 2026 ?

Le fichier README amont filebrowser/filebrowser indique que File Browser est archivé depuis le 2026-09-01, sans nouvelles versions ni correctifs de bugs ou de sécurité. Le code fonctionne toujours, mais un logiciel non corrigé qui dispose d’un accès en écriture à votre système de fichiers représente un risque qui augmente avec le temps. Si vous le conservez, suivez les recommandations du projet : aucune exposition directe sur Internet, un reverse proxy qui assure la terminaison TLS et sa propre authentification, le command runner désactivé, et un conteneur non privilégié dans lequel seul le répertoire servi est monté. Notez également que ses sessions sont des JWT autonomes, et non des identifiants conservés côté serveur. Elles ne peuvent donc pas être révoquées, et un changement de mot de passe n’invalide pas un token déjà émis. Pour une nouvelle installation, utilisez le fork FileBrowser Quantum, publié sous la forme de l’image gtstef/filebrowser, dont le développement se poursuit.

Un gestionnaire de fichiers auto-hébergé peut-il utiliser mon SSO existant ?

FileBrowser Quantum prend en charge OIDC, LDAP et un mode avec en-tête de proxy. Il peut donc être placé derrière un identity provider existant sans créer une seconde liste d’utilisateurs. L’intégration OpenID Connect de SFTPGo est disponible dans l’édition open source. Elle associe les utilisateurs de l’identity provider aux administrateurs et aux utilisateurs SFTPGo pour les interfaces WebAdmin et WebClient. Filestash constitue l’exception à surveiller : en août 2026, sa page tarifaire place le SSO (SAML, OIDC et LDAP) dans l’offre self-hosted payante à partir de $50 par mois, tandis que l’offre gratuite est indiquée comme étant sous AGPL v3 et limitée à 3 utilisateurs. Lorsqu’une application ne prend pas du tout en charge le SSO, la solution de repli consiste à utiliser la forward authentication sur le reverse proxy. Elle protège la page de connexion, mais ne modifie pas les permissions internes de l’application.

Lesquels de ces outils proposent des liens de partage qui expirent ?

SFTPGo propose l’implémentation la plus complète. Un utilisateur crée un lien HTTP/S depuis le WebClient. Il peut limiter le nombre de téléchargements et de téléversements, définir un mot de passe, restreindre l’accès selon l’adresse IP source et définir une date d’expiration automatique. FileBrowser Quantum prend en charge les partages avec une durée d’expiration. L’accès peut être anonyme ou limité à un utilisateur. Des permissions distinctes permettent aussi, pour chaque partage, d’autoriser la consultation, la modification et le téléversement. Filestash propose également une fonction de partage. C’est le seul cas où le serveur conserve une copie chiffrée persistante des identifiants de stockage, car le lien doit continuer à fonctionner lorsque la session du navigateur est terminée. Cloud Commander ne propose aucun lien de partage.

Est-il sûr de pointer un gestionnaire de fichiers vers / si je suis le seul utilisateur ?

Non. Le risque ne tient pas vraiment au fait que vous vous faites confiance. Le processus dispose d’un accès en lecture et en écriture à tout ce que son compte utilisateur peut atteindre. Tout accès à cette session, un cookie volé, une faille non corrigée dans le gestionnaire de téléversement ou un mot de passe réutilisé donne alors accès à /etc, à vos clés SSH et aux répertoires de données de tous vos services. Limitez plutôt le montage à un seul répertoire : /srv/files au lieu de /. Cloud Commander est le cas le plus risqué, car sa commande Docker publiée monte la racine de l’hôte sur /mnt/fs et sa configuration d’exemple définit "root": "/" avec "auth": false. Modifiez ces deux paramètres avant que ce conteneur n’écoute ailleurs que sur localhost.