Pourquoi auto-héberger FileBrowser sur un VPS
FileBrowser est un gestionnaire de fichiers web écrit en Go, distribué sous forme d'un seul binaire. Il expose un dossier de votre serveur dans une interface moderne : upload, téléchargement, prévisualisation, édition de texte, gestion d'utilisateurs et liens de partage. C'est l'outil idéal quand un Nextcloud serait surdimensionné : pas de base de données externe, pas de PHP, une empreinte de quelques dizaines de mégaoctets. Sur un VPS, il devient le point d'accès web à vos données serveur — livrer des fichiers à un client, donner un accès cadré à un dossier, ou simplement gérer les fichiers d'une application sans passer par SFTP. Un VPS est nécessaire car FileBrowser doit lire/écrire dans le système de fichiers et tourner en démon, ce qu'un hébergement mutualisé ne permet pas.
FileBrowser vs alternatives self-hosted
Faites défiler le tableau
| Critère | FileBrowser | Nextcloud | Seafile |
|---|---|---|---|
| Base de données | SQLite intégrée | MySQL/PostgreSQL requis | MySQL/PostgreSQL requis |
| RAM minimum | ~30 Mo | ~500 Mo | ~200 Mo |
| Installation | Un binaire ou image Docker | Docker Compose multi-services | Docker Compose multi-services |
| Gestion d'utilisateurs | Oui, avec scopes | Oui, complète | Oui, complète |
| Synchronisation client bureau | Non | Oui | Oui |
| Partages avec expiration | Oui, natif | Oui | Oui |
| Édition en ligne | Texte uniquement | Texte, Office (OnlyOffice) | Non |
| Cas d'usage principal | Accès et partage léger | Suite bureautique complète | Sync de données volumineuses |
Bénéfices concrets de FileBrowser auto-hébergé
- Ultra-léger : un binaire Go, base SQLite intégrée, démarre en quelques millisecondes.
- Gestion fine des permissions : chaque utilisateur est cantonné à un sous-dossier (scope) avec droits précis.
- Liens de partage avec mot de passe et expiration : transmettez un fichier sans créer de compte au destinataire.
- Édition et prévisualisation dans le navigateur (texte, images, vidéos) sans télécharger.
- Commandes personnalisées et hooks : déclenchez un script à l'upload (conversion, scan antivirus).
- Interface web propre en remplacement du SFTP pour les utilisateurs non techniques.
- Thème sombre natif, interface responsive sur mobile.
- Recherche par nom de fichier en temps réel dans l'arborescence exposée.
Prérequis techniques
FileBrowser est l'un des outils les plus économes en ressources : 1 vCPU et 512 Mo de RAM suffisent amplement, l'espace disque dépendant uniquement du volume de fichiers à servir. Aucune base de données externe n'est requise — la configuration et les comptes sont stockés dans un fichier SQLite local. Il faut Docker et Docker Compose, un sous-domaine fichiers.votredomaine.com pointé vers le VPS, et un reverse proxy pour le HTTPS. Important : prévoyez quel dossier de l'hôte vous voulez exposer (un dossier dédié /srv/partage, jamais la racine du système) et montez-le en volume dans le conteneur. Vérifiez que les ports 80 et 443 sont ouverts sur votre pare-feu, et que votre VPS dispose d'une entrée DNS A (ou AAAA pour IPv6) pointant vers son IP publique.
Déployer FileBrowser pas à pas
Préparer les dossiers et la config
Sur le VPS :
mkdir -p /opt/filebrowser /srv/partage. Créez un fichier vide pour la base :touch /opt/gtsteffaniak/filebrowser.db. Le dossier/srv/partageest celui que FileBrowser exposera. Ajustez les permissions pour que l'UID du conteneur puisse y écrire :chown -R 1000:1000 /srv/partage /opt/filebrowser.Écrire le docker-compose.yml
Basez-vous sur l'image
gtsteffaniak/filebrowser:latest. Montez/srv/partage:/srv(les données),/opt/gtsteffaniak/filebrowser.db:/database/filebrowser.db(la base) et fixezPUID/PGIDà 1000 (ou l'UID réel du dossier partagé). Exposez le port interne 80 vers le reverse proxy uniquement — ne pas mapper directement sur 80/443 de l'hôte si Caddy ou nginx occupe déjà ces ports. Ajoutezrestart: unless-stoppedpour que FileBrowser redémarre automatiquement après un reboot du serveur.Lancer et récupérer les identifiants
Démarrez avec
docker compose up -d. Au premier lancement, FileBrowser crée un compteadminavec un mot de passe affiché dans les logs :docker compose logs filebrowser. Notez-le pour la première connexion. Si les logs ne montrent pas de mot de passe, connectez-vous avecadmin/admin(identifiants par défaut de l'image officielle) et changez-le immédiatement.Mettre en place le reverse proxy et le SSL
Placez FileBrowser derrière un reverse proxy HTTPS. Avec Caddy :
fichiers.votredomaine.com { reverse_proxy filebrowser:80 }. Le certificat Let's Encrypt est généré et renouvelé automatiquement. Avec nginx, créez un vhost dédié avecproxy_pass http://127.0.0.1:<port_conteneur>;et un blocssl_certificatepointant vers les fichiers certbot. Assurez-vous que l'en-têteX-Forwarded-Forest transmis pour que FileBrowser consigne la vraie IP des clients dans ses logs d'accès.Sécuriser et créer les comptes
Connectez-vous, changez immédiatement le mot de passe admin, puis créez des utilisateurs en limitant chacun à son scope (sous-dossier) avec les droits adaptés. Activez la double authentification du reverse proxy si l'accès est sensible. Dans les paramètres de FileBrowser, désactivez les inscriptions publiques (
allow registration: false) et limitez les méthodes d'authentification. Pour un accès très restreint, configurez une basic auth au niveau du reverse proxy en couche supplémentaire.Tester le partage et les liens publics
Uploadez un fichier de test, générez un lien de partage avec expiration (par exemple 7 jours) et mot de passe optionnel. Copiez le lien et ouvrez-le dans un navigateur en mode privé pour vérifier qu'il fonctionne sans session active. Vérifiez que la limite d'expiration est bien respectée en consultant l'heure d'expiration dans l'interface d'administration.
Sécuriser FileBrowser en production
Exposer un gestionnaire de fichiers sur internet sans couche de sécurité supplémentaire est risqué. Plusieurs mesures complémentaires s'appliquent selon votre contexte : restreindre l'accès par IP côté reverse proxy si l'outil n'est destiné qu'à une équipe sur un réseau fixe ; forcer l'authentification HTTP basique devant FileBrowser pour ajouter une barrière avant même l'écran de login de l'application ; activer les journaux d'accès détaillés pour détecter des tentatives de brute-force. FileBrowser n'offre pas nativement de verrouillage après N tentatives échouées : si votre VPS est exposé publiquement, un fail2ban sur les logs nginx ou Caddy avec un pattern sur les 401 est un complément indispensable. Enfin, le dossier exposé doit impérativement être différent du dossier home ou du dossier système — FileBrowser ne connaît que ce que vous lui montez, pas ce qui reste à côté.
Checklist sécurité avant mise en production
- Mot de passe admin changé dès le premier lancement.
- Inscriptions publiques désactivées dans les paramètres FileBrowser.
- Reverse proxy HTTPS actif, redirection HTTP→HTTPS forcée.
- Chaque utilisateur limité à son propre scope de dossier.
- Fail2ban (ou Crowdsec) configuré sur les logs du reverse proxy.
- Expiration activée par défaut sur les liens de partage (paramètre global).
- Sauvegardes régulières de
/opt/gtsteffaniak/filebrowser.db(comptes, config, permissions). - Accès restreint par IP côté reverse proxy si les utilisateurs ont des adresses fixes.
Personnaliser FileBrowser : branding, commandes et hooks
FileBrowser propose plusieurs niveaux de personnalisation accessibles depuis l'interface d'administration. La section Branding permet de remplacer le logo, le nom de l'application et les couleurs — utile pour livrer un accès white-label à des clients. La section Commandes personnalisées (Custom Commands) est l'une des fonctionnalités les plus puissantes : chaque dossier (scope) peut porter des commandes shell disponibles en un clic dans l'interface. Vous pouvez par exemple créer une commande Compresser en ZIP qui appelle un script zip -r /srv/archive.zip /srv/dossier-cible et le rend téléchargeable. Les hooks before_copy, after_copy, before_rename, after_rename, before_upload, after_upload, before_delete, after_delete permettent d'automatiser des actions sans intervention utilisateur : générer une vignette à l'upload d'une image, notifier un webhook Slack, lancer un scan ClamAV, synchroniser vers un stockage objet S3.
Sauvegarder et mettre à jour FileBrowser
FileBrowser stocke toute sa configuration dans un seul fichier SQLite : /opt/gtsteffaniak/filebrowser.db. Ce fichier contient les comptes, les scopes, les permissions, les tokens de partage et les paramètres de l'application. Une sauvegarde quotidienne de ce fichier suffit à garantir une restauration complète. La mise à jour se résume à tirer la nouvelle image Docker : docker compose pull && docker compose up -d. FileBrowser applique automatiquement les migrations de base de données au démarrage — aucune intervention manuelle n'est requise. Avant toute mise à jour majeure, copiez le fichier SQLite en dehors du dossier Docker pour conserver un point de retour sûr. Consultez le changelog GitHub du projet pour identifier les changements cassants entre versions, notamment les éventuelles modifications des URLs d'API internes si vous avez des scripts qui s'y appuient.
Exploitez les « commandes personnalisées » de FileBrowser pour automatiser le post-traitement : associez par exemple un script déclenché à chaque upload (after_upload) qui génère une vignette ou lance un scan ClamAV. Pour les partages clients, créez systématiquement un utilisateur dédié au scope réduit plutôt que de partager le compte admin, et activez l'expiration automatique sur les liens publics afin qu'aucun fichier ne reste accessible indéfiniment. Pour automatiser les sauvegardes du fichier SQLite, un cron quotidien avec cp /opt/gtsteffaniak/filebrowser.db /backup/filebrowser-$(date +%F).db suffit — pensez à purger les copies de plus de 30 jours pour ne pas saturer le disque.
