Comment auto-héberger File Browser en 2026 : volumes, comptes et partage sécurisé

Considérez File Browser comme un petit système, et non comme une image Docker. L’objectif côté utilisateur est clair pour File Browser : fournir un gestionnaire de fichiers web pour un volume attaché ; le déploiement n’est acceptable que lorsque vous pouvez créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée.

Cette distinction permet de détecter le problème que les opérateurs rencontrent après les tests locaux : les fichiers montés utilisent des permissions de l’hôte que le conteneur ne peut pas lire. Elle permet également de définir un plan de sauvegarde et de mise à niveau suffisamment précis pour être testé.

Identifiez chaque octet durable de File Browser

Une image de conteneur peut être téléchargée à nouveau ; les fichiers servis ainsi que la base de données et les paramètres de File Browser, non. Montez /srv avant le bootstrap, écrivez quelques données d’exemple inoffensives, puis remplacez le conteneur pour vérifier que ce chemin est bien persistant. Inspectez le montage effectif au lieu de vous fier au nom d’un fichier Compose, et vérifiez que l’utilisateur d’exécution peut écrire là où File Browser l’attend.

Choisissez une durée de rétention et une destination hors hôte, puis répétez la procédure de récupération sans toucher à la production. Le test n’est réussi que lorsque les fichiers servis, les utilisateurs, les périmètres, les partages et les paramètres sont restaurés et qu’un compte restreint reste confiné. Pour les états adossés à une base de données, associez les snapshots du stockage à des exports cohérents du point de vue applicatif, comme indiqué dans récupération à un instant donné ou snapshots.

Exécutez la première instance représentative de la production

Rendez la première invocation de File Browser suffisamment reproductible pour pouvoir être relue dans une pull request.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Ne vous appuyez pas sur latest une fois que de vraies données existent. Notez le digest utilisé, l’utilisateur du conteneur et les permissions des montages. Suivez le journal de l’application pendant un test complet — créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée — et notez les éventuelles migrations avant de placer la route derrière le trafic de production.

Délimitez la frontière d’exécution de File Browser

La santé du processus et celle du produit sont deux choses distinctes pour File Browser. Le port 80 peut répondre alors que la transaction côté utilisateur échoue toujours. L’exigence d’exécution locale est un chemin persistant distinct pour sa base de données et ses paramètres. Validez-le avec la charge de travail d’acceptation ; un health check en veille ne peut pas prouver que la ressource est suffisante.

Utilisez cet exercice de readiness après toute modification importante de la configuration : créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée. Gardez les vérifications externes coûteuses hors des probes de liveness afin qu’une panne d’un fournisseur ne provoque pas une boucle de redémarrage. Le travail de capacity planning doit suivre le débit du disque sous-jacent, la taille des imports, le nombre de téléchargements simultanés et le nombre de répertoires, qui reflètent mieux la pression réelle sur File Browser que les requêtes de page.

Rendez l’origine publique explicite

Exposez un seul hostname HTTPS pour File Browser ; gardez le port 80 brut privé. Publiez l’interface utilisateur via HTTPS, mais définissez précisément la racine servie. Les navigateurs et les clients API n’apprennent ainsi pas deux adresses concurrentes.

Depuis un client vierge, exécutez la transaction validée et inspectez la première requête en échec. Utilisez le guide des domaines personnalisés lorsque le DNS ou TLS est incorrect. Traitez « les fichiers montés utilisent des permissions de l’hôte que le conteneur ne peut pas lire » comme un diagnostic applicatif distinct une fois la route validée.

La release gate de File Browser

Créez une petite fixture File Browser jetable et conservez-la pour chaque release. La fixture doit couvrir le workflow réel : créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée. Consignez le digest de l’image, le hostname externe, l’adresse de la dépendance et le résultat attendu afin qu’un autre opérateur puisse répéter le test sans devoir interpréter ce guide.

Exécutez la fixture trois fois. Premièrement, utilisez le déploiement vierge. Deuxièmement, remplacez le conteneur sans toucher à l’état durable. Troisièmement, restaurez la sauvegarde dans un environnement vide. Le troisième test n’est réussi que lorsque les fichiers servis, les utilisateurs, les périmètres, les partages et les paramètres sont restaurés et qu’un compte restreint reste confiné. À chaque exécution, mesurez la latence et l’utilisation des ressources autour du débit du disque sous-jacent, de la taille des imports, du nombre de téléchargements simultanés et du nombre de répertoires ; cela constitue la baseline des alertes, plutôt qu’un pourcentage de CPU arbitraire.

Enfin, testez volontairement le chemin négatif : envoyez une entrée inoffensive proche de la limite de ressource ou de format associée à cette frontière : les fichiers montés utilisent des permissions de l’hôte que le conteneur ne peut pas lire. Vérifiez que File Browser échoue de manière visible sans corrompre l’état, rétablissez la condition correcte et répétez la transaction réussie. Un compte rendu de release contenant ces quatre résultats constitue une preuve plus solide que des captures d’écran d’un dashboard ou qu’une réponse curl ponctuelle.

Vérifications de capacité et de mise à niveau

Un health check en veille apporte peu d’informations sur File Browser. Surveillez le débit du disque sous-jacent, la taille des imports, le nombre de téléchargements simultanés et le nombre de répertoires, puis déclenchez les alertes sur le symptôme observé par les utilisateurs : l’échec de l’action « créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée ». Gardez la liveness locale et légère ; laissez la readiness signaler les migrations ou l’initialisation sans provoquer une tempête de redémarrages.

La zone de mise à niveau à risque concerne les migrations de la base de données et des paramètres de File Browser, même si les fichiers servis se trouvent sur un montage distinct. Lisez les release notes, créez un snapshot de l’état, déployez la version cible sur une copie restaurée et répétez l’action d’acceptation. Si les fichiers montés utilisent des permissions de l’hôte que le conteneur ne peut pas lire, corrélez la requête cliente avec la première entrée pertinente du journal de l’application au lieu de supprimer l’état ou d’ajouter des redirections à l’aveugle.

Réduisez les privilèges détenus par File Browser

Les identifiants de bootstrap sont temporaires ; le modèle de confiance est permanent. Avec File Browser, vérifiez que vous ne servez pas / ou un répertoire de secrets à la place d’un partage dédié, et servez un répertoire dédié plutôt que la racine de l’hôte ; accordez à chaque compte le périmètre de fichiers le plus restreint possible.

File Browser n’impose aucun secret de bootstrap dans cette configuration de référence ; protégez plutôt son véritable compte administrateur ou l’authentification en amont. Exécutez l’image sans capabilities Linux inutiles et n’exposez que la route applicative publique. Assurez la traçabilité de l’activité des administrateurs sans enregistrer les valeurs secrètes.

Utilisez Dockup pour la couche plateforme

Pour File Browser, Dockup est particulièrement utile à la frontière entre une image et un service durable. Il conserve la route vers le port 80, TLS, les valeurs secrètes et le stockage attaché lors des remplacements de conteneurs, que le compute appartienne à Dockup ou à votre serveur attaché.

Terminez avec les connaissances applicatives : publiez l’interface utilisateur via HTTPS, mais définissez précisément la racine servie ; confirmez l’exigence locale — un chemin persistant distinct pour sa base de données et ses paramètres ; puis exécutez cette vérification : créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée. Conservez le résultat comme contrôle de déploiement afin que la prochaine mise à jour de l’image soit évaluée sur son comportement plutôt que sur l’état du conteneur.

Foire aux questions

De quoi File Browser a-t-il besoin pour un déploiement en production ?

Faites passer le conteneur File Browser sur le port 80 via une seule origine HTTPS. L’exigence d’exécution locale est un chemin persistant distinct pour sa base de données et ses paramètres. Ne considérez pas File Browser comme prêt tant que vous ne pouvez pas créer un utilisateur restreint, importer et renommer un fichier, modifier du texte, générer un partage et confirmer que l’utilisateur ne peut pas sortir de la racine qui lui est attribuée.

Quelles données de File Browser doivent être incluses dans une sauvegarde ?

Rendez /srv persistant et incluez les fichiers servis ainsi que la base de données et les paramètres de File Browser dans le même manifest de récupération. Une restauration propre de File Browser n’est réussie que lorsque les fichiers servis, les utilisateurs, les périmètres, les partages et les paramètres sont restaurés et qu’un compte restreint reste confiné.

File Browser nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de File Browser et gardez le port 80 sur la route interne. Appliquez correctement le paramètre de File Browser : publiez l’interface utilisateur via HTTPS, mais définissez précisément la racine servie. Pour File Browser, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transit et garantit un comportement cohérent des clients dépendant de l’origine.

Comment tester une mise à niveau de File Browser ?

Restaurez l’état actuel de File Browser dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de la base de données et des paramètres de File Browser sont importantes, même si les fichiers servis se trouvent sur un montage distinct. Conservez l’ancienne image File Browser jusqu’à ce que les limites de migration des données et de rollback soient bien comprises.