Cómo autoalojar File Browser en 2026: volúmenes, cuentas y uso compartido seguro

Trata File Browser como un sistema pequeño, no como una imagen de Docker. El objetivo de cara al usuario es claro: un gestor de archivos web para un volumen conectado; el despliegue solo es aceptable cuando puedes crear un usuario restringido, subir y cambiar el nombre de un archivo, editar texto, generar un enlace compartido y confirmar que el usuario no puede salir de su raíz asignada.

Esta distinción detecta el fallo con el que se encuentran los operadores después de las pruebas locales: los archivos montados usan permisos del host que el contenedor no puede leer. También hace que el plan de copias de seguridad y actualizaciones sea lo bastante específico como para probarlo.

Encuentra todos los bytes duraderos de File Browser

Una imagen de contenedor se puede descargar de nuevo; los archivos servidos, junto con la base de datos y la configuración de File Browser, no. Monta /srv antes del bootstrap, escribe datos de ejemplo inocuos y reemplaza el contenedor para demostrar que esa ruta es realmente persistente. Inspecciona el montaje efectivo en lugar de confiar en un nombre de archivo de Compose y comprueba que el usuario del runtime puede escribir donde File Browser lo necesita.

Elige la retención y un destino externo al host, y después ensaya la recuperación sin tocar producción. La prueba solo se supera cuando vuelven los archivos servidos, los usuarios, los ámbitos, los enlaces compartidos y la configuración, y una cuenta restringida permanece confinada. Para el estado respaldado por una base de datos, combina snapshots del almacenamiento con exportaciones coherentes con la aplicación, tal como se describe en recuperación a un punto en el tiempo frente a snapshots.

Ejecuta la primera instancia con forma de producción

Mantén la primera invocación de File Browser lo bastante reproducible como para revisarla en un 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

No dependas de latest cuando ya existan datos reales. Registra el digest utilizado, el usuario del contenedor y la propiedad de los montajes. Sigue el log de la aplicación durante una prueba completa —crear un usuario restringido, subir y cambiar el nombre de un archivo, editar texto, generar un enlace compartido y confirmar que el usuario no puede salir de su raíz asignada— y anota cualquier migración antes de poner la ruta detrás del tráfico de producción.

Delimita el límite de ejecución de File Browser

La salud del proceso y la salud del producto son independientes en File Browser. El puerto 80 puede responder aunque la transacción de cara al usuario siga fallando. El requisito del runtime local es una ruta persistente independiente para su base de datos y configuración. Valídalo con la carga de aceptación; un health check en reposo no puede demostrar que el recurso sea suficiente.

Usa este ejercicio de readiness después de cambios de configuración importantes: crea un usuario restringido, sube y cambia el nombre de un archivo, edita texto, genera un enlace compartido y confirma que el usuario no puede salir de su raíz asignada. Mantén las comprobaciones externas costosas fuera de las sondas de liveness para que una interrupción del proveedor no provoque un bucle de reinicios. El trabajo de capacidad debe seguir el throughput del disco subyacente, el tamaño de las subidas, las descargas simultáneas y el número de directorios, aspectos más cercanos a la presión real de File Browser que las solicitudes de página.

Haz que el origen público no sea ambiguo

Expón un único hostname HTTPS para File Browser y mantén privado el puerto 80 sin procesar. Publica la UI mediante HTTPS, pero delimita cuidadosamente la raíz servida. Así evitas que los navegadores y los clientes de API conozcan dos direcciones en conflicto.

Desde un cliente limpio, ejecuta la transacción validada e inspecciona la primera solicitud que falla. Usa la guía de dominios personalizados cuando el problema esté en DNS o TLS. Trata “los archivos montados usan permisos del host que el contenedor no puede leer” como un diagnóstico de aplicación independiente una vez validada la ruta.

El gate de releases de File Browser

Crea un fixture pequeño y desechable de File Browser y consérvalo para cada release. El fixture debe ejercitar el workflow real: crear un usuario restringido, subir y cambiar el nombre de un archivo, editar texto, generar un enlace compartido y confirmar que el usuario no puede salir de su raíz asignada. Registra el digest de la imagen, el hostname externo, la dirección de la dependencia y el resultado esperado para que otro operador pueda repetir la prueba sin tener que interpretar esta guía.

Ejecuta el fixture tres veces. Primero, usa el despliegue nuevo. Segundo, reemplaza el contenedor sin tocar el estado duradero. Tercero, restaura la copia de seguridad en un entorno vacío. La tercera ejecución solo se supera cuando vuelven los archivos servidos, los usuarios, los ámbitos, los enlaces compartidos y la configuración, y una cuenta restringida permanece confinada. En cada ejecución, captura la latencia y el uso de recursos en torno al throughput del disco subyacente, el tamaño de las subidas, las descargas simultáneas y el número de directorios; esto se convierte en la línea base de las alertas, en lugar de un porcentaje de CPU arbitrario.

Por último, prueba deliberadamente la ruta negativa: envía una entrada inocua cerca del límite de recurso o formato asociado a este límite: los archivos montados usan permisos del host que el contenedor no puede leer. Confirma que File Browser falla de forma visible sin corromper el estado, corrige la condición y repite la transacción correcta. Un registro de release que contenga esos cuatro resultados aporta pruebas más sólidas que las capturas de un dashboard o una respuesta puntual de curl.

Comprobaciones de capacidad y actualización

Un health check en reposo dice muy poco sobre File Browser. Supervisa el throughput del disco subyacente, el tamaño de las subidas, las descargas simultáneas y el número de directorios, y genera alertas según el síntoma que experimentan los usuarios: el fallo de la acción “crear un usuario restringido, subir y cambiar el nombre de un archivo, editar texto, generar un enlace compartido y confirmar que el usuario no puede salir de su raíz asignada”. Mantén liveness local y económica; deja que readiness informe de las migraciones o la inicialización sin provocar una tormenta de reinicios.

El área de riesgo de la actualización es que las migraciones de la base de datos y la configuración de File Browser son importantes, aunque los archivos servidos residan en un montaje independiente. Lee las notas de la release, crea un snapshot del estado, despliega la versión objetivo sobre una copia restaurada y repite la acción de aceptación. Si los archivos montados usan permisos del host que el contenedor no puede leer, relaciona la solicitud del cliente con la primera entrada relevante del log de la aplicación en lugar de eliminar el estado o añadir redirects a ciegas.

Reduce la autoridad de File Browser

Las credenciales de bootstrap son temporales; el modelo de confianza es permanente. Con File Browser, presta atención a que se sirva / o un directorio de secrets en lugar de un recurso compartido dedicado, y sirve un directorio dedicado en lugar de la raíz del host; además, asigna a cada cuenta el ámbito de archivos más reducido que necesite.

File Browser no tiene un secret de bootstrap obligatorio en esta configuración base; protege su cuenta de administrador real o la autenticación upstream. Ejecuta la imagen sin capabilities de Linux innecesarias y expón únicamente la ruta pública de la aplicación. Mantén visible la actividad administrativa sin registrar valores secretos.

Usa Dockup para la capa de plataforma

Para File Browser, Dockup resulta más útil en el límite entre una imagen y un servicio duradero. Mantiene la ruta al puerto 80, TLS, los valores de secrets y el almacenamiento conectados durante los reemplazos de contenedores, tanto si el compute pertenece a Dockup como si pertenece a tu servidor conectado.

Termina aplicando el conocimiento de la aplicación: publica la UI mediante HTTPS, pero delimita cuidadosamente la raíz servida; confirma el requisito local —una ruta persistente independiente para su base de datos y configuración—; y ejecuta esta verificación: crea un usuario restringido, sube y cambia el nombre de un archivo, edita texto, genera un enlace compartido y confirma que el usuario no puede salir de su raíz asignada. Conserva el resultado como una comprobación del despliegue para que la siguiente actualización de la imagen se evalúe por su comportamiento y no por el estado del contenedor.

Preguntas frecuentes

¿Qué necesita File Browser para un despliegue de producción?

Enruta el contenedor de File Browser en el puerto 80 a través de un único origen HTTPS. El requisito del runtime local es una ruta persistente independiente para su base de datos y configuración. No consideres que File Browser está listo hasta que puedas crear un usuario restringido, subir y cambiar el nombre de un archivo, editar texto, generar un enlace compartido y confirmar que el usuario no puede salir de su raíz asignada.

¿Qué datos de File Browser deben incluirse en una copia de seguridad?

Haz persistente /srv e incluye los archivos servidos, junto con la base de datos y la configuración de File Browser, en el mismo manifiesto de recuperación. Una restauración limpia de File Browser solo se supera cuando vuelven los archivos servidos, los usuarios, los ámbitos, los enlaces compartidos y la configuración, y una cuenta restringida permanece confinada.

¿File Browser necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de File Browser y mantén el puerto 80 en la ruta interna. Aplica correctamente la configuración de File Browser: publica la UI mediante HTTPS, pero delimita cuidadosamente la raíz servida. En File Browser, HTTPS protege las credenciales o el contenido de los usuarios durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de File Browser?

Restaura el estado actual de File Browser en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de la base de datos y la configuración de File Browser son importantes, aunque los archivos servidos residan en un montaje independiente. Conserva la imagen anterior de File Browser hasta comprender sus límites de migración de datos y rollback.