Comparativa de gestores de archivos autoalojados

Qué es un gestor de archivos autoalojado y qué no es

Un gestor de archivos autoalojado es una página web que muestra el árbol de directorios que ya existe en tu VPS (servidor privado virtual). Inicias sesión, ves /srv/files exactamente como está en el disco, y puedes subirlo, cambiarle el nombre, descargarlo o compartir un enlace. No se copia nada en un segundo sistema, por lo que un archivo que añades desde el navegador es el mismo archivo que ls muestra un segundo después.

Los resultados de búsqueda suelen mezclarlo con software que realiza otras tareas. Las herramientas de sincronización mantienen una copia de cada archivo en cada dispositivo, que es para lo que sirve una alternativa autoalojada a Dropbox. El almacenamiento de objetos no tiene ningún árbol de directorios: utiliza buckets y una API. Por eso, ejecutar MinIO para almacenamiento de objetos compatible con S3 responde a una necesidad diferente. Los paneles de administración del servidor gestionan la máquina, no los archivos. Esa es la diferencia que se explica en la comparación entre Cockpit y Webmin.

Necesitas un gestor de archivos cuando un compañero necesita descargar un archivo de 300 MB del servidor o cuando quieres corregir una errata en un archivo de configuración desde un teléfono. La tarea es pequeña, y las herramientas también.

Ten presente un hecho mientras lees. Esta es una aplicación web con acceso de lectura y escritura a tu sistema de archivos que escucha en un puerto. Cada decisión que se describe a continuación determina realmente a qué parte del disco puede acceder ese proceso.

FileBrowser está archivado; lea esto antes de instalarlo

FileBrowser, el proyecto filebrowser/filebrowser, es la respuesta que todavía aparece en la mayoría de las guías. Su README comienza ahora con este aviso:

File Browser se archivará el 2026-09-01. La última versión prevista ya se ha publicado. No habrá más versiones, correcciones de errores ni correcciones de seguridad.

El código con licencia Apache 2.0 sigue funcionando. Las correcciones de seguridad se detienen. Esto es más importante en esta categoría que en la mayoría de los casos, porque el objetivo del software es proporcionar acceso de escritura a un sistema de archivos mediante HTTP.

Los mantenedores documentaron cómo seguir ejecutándolo, y conviene aplicar estas recomendaciones independientemente de la herramienta que elija: no lo exponga directamente a Internet, colóquelo detrás de un reverse proxy que termine TLS (seguridad de la capa de transporte) y realice su propia autenticación, mantenga desactivado el ejecutor de comandos y ejecútelo sin privilegios en un contenedor que sólo tenga montado el directorio que pretende servir.

Una línea de ese README es más importante que el resto. Las sesiones son JWT (JSON web tokens) autocontenidos en lugar de identificadores almacenados en el servidor, por lo que no se pueden revocar. Un token de sesión filtrado sigue siendo válido hasta que caduca, y cambiar la contraseña no lo invalida. Si mantiene FileBrowser, la capa de autenticación situada delante es la que realiza realmente el trabajo.

FileBrowser Quantum: el fork que sigue activo

El desarrollo activo pasó a un fork, FileBrowser Quantum (gtsteffaniak/filebrowser), publicado como la imagen gtstef/filebrowser. Reorganiza la configuración en torno a un único config.yaml, en lugar de la combinación anterior de opciones de línea de comandos y ajustes de la base de datos. La prueba rápida documentada es:

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

Sirve el directorio actual en http://localhost, y el primer inicio de sesión es admin / admin. Cámbialo antes de que el contenedor sea accesible desde cualquier lugar que no sea tu propia máquina.

Para una instancia que vaya a conservar, usa Compose, monta el directorio de datos en lugar de un único archivo de base de datos y enlaza el puerto a 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 configuración se encuentra en /home/filebrowser/data/config.yaml y la base de datos en /home/filebrowser/data/filebrowser.sqlite. La versión 2.0.0 cambió el formato de la base de datos y realiza una migración única. Por eso la documentación pide montar un directorio: un montaje de un único archivo no deja ningún lugar donde guardar el archivo nuevo durante la migración. Las rutas dentro de config.yaml son rutas del contenedor, por lo que un origen en la configuración se lee como /folder, no como /srv/files. Si se invierten, la lista de archivos aparece vacía sin mostrar ningún error, porque el directorio realmente no existe.

El proyecto publica latest y stable con un tamaño aproximado de 60 MB y FFmpeg incluido para las miniaturas de vídeo, y stable-slim con un tamaño aproximado de 15 MB y sólo el núcleo. Esas son las cifras de la página de instalación en agosto de 2026. Fija la etiqueta que hayas elegido. latest cambia sin avisar, y que un gestor de archivos cambie el formato de su configuración mientras el contenedor está en ejecución no es una situación aceptable.

Para este trabajo, es la opción más completa entre las herramientas pequeñas. Sirve varias fuentes con reglas de inclusión y exclusión, de modo que una sola instancia puede exponer /srv/media y /srv/docs con distinto alcance. Los recursos compartidos tienen un tiempo de expiración y pueden ser anónimos o estar restringidos a un usuario. La autenticación admite OIDC (OpenID Connect), LDAP (lightweight directory access protocol), contraseña con dos factores y un modo basado en cabeceras del proxy. Ese modo de proxy permite situarlo detrás del inicio de sesión único (SSO) de un servidor Authentik autoalojado, en lugar de mantener una segunda lista de usuarios.

Filestash: una interfaz para el almacenamiento que ya tiene

Filestash tiene un enfoque diferente. Es una interfaz que se conecta a un backend, y la lista de backends es extensa: FTP, SFTP (protocolo de transferencia de archivos SSH), S3, SMB, WebDAV, IPFS y unos veinte más. Es adecuado cuando los archivos no están en el equipo que ejecuta la interfaz.

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

La imagen es machines/filestash:latest. Abra http://your_domain:8334 y la primera pantalla le permitirá establecer la contraseña de administrador. Establézcala inmediatamente, porque hasta entonces la consola de administración estará abierta a cualquiera que encuentre el puerto.

Comprenda el modelo de identidad antes de basarse en él. Filestash no mantiene una base de datos de usuarios en el sentido habitual. Las credenciales se almacenan en el navegador mediante cookies cifradas y autenticadas, con el atributo HTTP only, y no se conserva nada en el servidor a menos que use la función de uso compartido. En ese caso, Filestash conserva una versión cifrada y persistente de sus credenciales. Los «usuarios» son cuentas de almacenamiento: la identidad reside en el backend, en la cuenta SFTP o en la clave S3, no en Filestash.

Este diseño es sencillo, pero tiene un coste. La página de precios indica que el nivel gratuito autohospedado usa AGPL v3 (Licencia Pública General Affero de GNU) y admite hasta 3 usuarios. También incluye SSO (SAML, OIDC y LDAP) con control de acceso basado en roles en el nivel autohospedado de pago, desde $50 al mes, a fecha de agosto de 2026. Si el plan era «poner Filestash delante del SSO de la empresa de forma gratuita», consulte esa página antes de diseñar la solución.

SFTPGo: un servidor de protocolos que también tiene una interfaz web

SFTPGo es el software más completo de esta selección y el que se recomienda con más frecuencia por el motivo equivocado. Sirve SFTP, HTTP/S, FTP/S y WebDAV sobre un sistema de archivos local, un sistema de archivos local cifrado, almacenamiento de objetos compatible con S3, Google Cloud Storage, Azure Blob Storage u otro servidor SFTP.

Se publican binarios, paquetes para Debian y Ubuntu y una imagen de contenedor. La línea actual del repositorio APT y su clave de firma están en la página de instalación de la documentación de SFTPGo. La opción del contenedor es la forma más rápida de ponerlo en funcionamiento. Sustituya tag por la versión que quiera:

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

SFTP escucha en 2022 y las interfaces web en 8080. Monte /srv/sftpgo como volumen. De lo contrario, las cuentas y sus archivos desaparecerán al recrear el contenedor, porque los directorios personales de los usuarios usan /srv/sftpgo/data/<username> de forma predeterminada.

Hay dos interfaces web. La diferencia es la parte que la mayoría de los artículos deja implícita. WebAdmin, en /web/admin, es administrativa. Sirve para crear usuarios, grupos, carpetas virtuales y reglas de eventos, y para establecer cuotas, límites de ancho de banda y restricciones de horario de acceso. WebClient, en /web/client, es la interfaz para usuarios finales. Permite explorar archivos, cambiar las propias credenciales, configurar la autenticación de dos factores y crear recursos compartidos.

Esos recursos compartidos son los mejores de esta comparación. Un usuario puede crear enlaces HTTP/S para compartir archivos y carpetas, limitar el número de descargas y cargas, proteger el recurso compartido con una contraseña, restringir el acceso por dirección IP de origen y establecer una fecha de caducidad automática.

Entonces, ¿por qué hay que tener precaución? El núcleo del producto es el modelo de cuentas y el servidor de protocolos, no la experiencia de exploración. Elija SFTPGo cuando otras personas necesiten cuentas reales con cuotas, cuando las cargas lleguen por SFTP o FTPS desde un sistema que no controla o cuando un mismo bucket deba aparecer dentro de los directorios personales de varios usuarios. Las carpetas virtuales resuelven este último caso: una carpeta respaldada por disco local, S3, GCS, Azure Blob, SFTP o HTTP, montada en varias cuentas, con una cuota independiente por usuario en una carpeta compartida. Si sólo quería una página explorable sobre /srv/files, esto supone demasiada infraestructura.

Conviene conocer otros dos datos. La edición Community usa AGPL-3.0-only con términos adicionales y existe junto a una edición Enterprise con licencia comercial. El inicio de sesión mediante OIDC está incluido en la compilación de código abierto. Asigna los usuarios del proveedor de identidad a administradores y usuarios de SFTPGo en ambas interfaces web. También puede desactivar globalmente la interfaz de cliente con enable_web_client en la configuración de httpd, o por usuario añadiendo HTTP a los protocolos denegados de ese usuario. Así, el gestor de archivos puede estar disponible para una persona y no para las demás.

Cloud Commander: dos paneles y un terminal para uso personal

Cloud Commander es un gestor de Node.js con licencia MIT basado en el estilo de dos paneles. Incluye un editor integrado, una consola y un terminal. Instálelo globalmente con npm i cloudcmd -g o ejecute el contenedor publicado:

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

Lea ese comando antes de ejecutarlo. -v /:/mnt/fs monta todo el sistema de archivos del host en el contenedor, y el ejemplo ~/.cloudcmd.json incluye "root": "/", "auth": false y "console": true. Esto significa que cualquier persona que acceda al puerto 8000 obtiene acceso a todo el disco y a una consola de comandos del servidor. Es una configuración razonable para un portátil, pero no para un VPS.

Limite el alcance. El contenedor lee /root/.cloudcmd.json. El comando publicado proporciona ese archivo montando el directorio personal. Mantenga el montaje de la configuración y elimine el resto:

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

En ese archivo de configuración, establezca "root" en /srv/files, "auth" en true con un "username" y "password", y "console" y "terminal" en false, salvo que realmente necesite acceso al shell desde el navegador. También existen equivalentes de línea de comandos, incluidos --root, --auth, --username, --password y --prefix.

Sea claro sobre sus capacidades. Usa un único par de credenciales, no permite limitar el acceso por usuario, no ofrece cuotas ni enlaces compartidos. Es una herramienta personal. Por tanto, vincúlela a localhost como se ha indicado y acceda mediante un túnel:

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

Después, abra http://127.0.0.1:8000 en su propio equipo. El gestor de archivos nunca queda expuesto públicamente. El único servicio expuesto a Internet es el daemon de SSH que ya reforzó en su VPS.

Por qué Nextcloud no es la herramienta adecuada para esta tarea

Nextcloud es un buen software, pero no sirve para esto. Es una plataforma de colaboración: una aplicación PHP, una base de datos, trabajos en segundo plano, clientes de sincronización para equipos de escritorio y una tienda de aplicaciones. Ejecutarlo para obtener una vista web de /srv/files implica muchos componentes para una tarea pequeña, y existe una incompatibilidad concreta. Nextcloud guarda los metadatos de los archivos en una tabla de la base de datos en lugar de leer el directorio en cada solicitud. Por eso, los archivos escritos por rsync o un trabajo de cron pueden seguir sin aparecer en la interfaz hasta que un escaneo los detecte, con sudo -u www-data php occ files:scan --all. Un gestor de archivos muestra el contenido del directorio al cargar la página, por lo que ese desfase no existe.

Use Nextcloud para lo que hace bien: calendarios, contactos, sincronización y uso compartido con personas que esperan un cliente de escritorio. Nextcloud en un VPS con Docker, TLS y copias de seguridad explica esa configuración. Si ya lo ejecuta y sólo necesita ver un directorio existente, habilite la aplicación External Storage y deténgase ahí. Una segunda aplicación web con acceso de escritura al mismo disco es otro componente que debe actualizarse.

Cómo ejecutar uno sin exponer todo el servidor

Nunca lo apunte a /. El proceso puede leer y escribir todo lo que esté al alcance de su cuenta de usuario, por lo que un token de sesión robado se convierte exactamente en ese nivel de acceso al sistema de archivos. Publique un solo directorio, /srv/files, y créelo para ese fin.

Ejecútelo con un usuario que no sea root y monte sólo lo que debe publicar. En Compose, esto implica user: "1000:1000" más un montaje bind por cada directorio, con :ro en todo lo que nunca necesite escribir:

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

El resultado habitual de este cambio es que la navegación funciona y las cargas fallan con permission denied, porque el ID de usuario dentro del contenedor no es el propietario del directorio fuera de él. Compare ambos valores: docker exec filebrowser id muestra el usuario del contenedor y ls -ln /srv/files muestra el propietario numérico en el host. Corríjalo con sudo chown -R 1000:1000 /srv/files. Este es el mismo problema de propiedad que PUID y PGID en imágenes de Docker solucionan.

Vincule el puerto publicado a localhost, 127.0.0.1:8080:80, en lugar de 8080:80. Docker escribe sus propias reglas de netfilter antes que las de ufw, por lo que un puerto publicado sin restricciones sigue siendo accesible desde Internet aunque ufw deny 8080 esté activo. Coloque un reverse proxy delante para TLS. Sobre HTTP sin cifrar, la cookie de sesión atraviesa la red en claro, y esa cookie equivale al acceso al sistema de archivos. Si Compose todavía es nuevo para usted, Docker Compose en un VPS explica la estructura de archivos que asumen estos fragmentos.

Añada una capa de autenticación cuando la de la aplicación sea limitada. La autenticación básica HTTP en el proxy es suficiente para una instancia de un solo usuario. Cuando interviene más de una persona, use OIDC o forward auth contra un proveedor de identidad, de modo que revocar una cuenta revoque el acceso en todas partes.

Desactive las funciones adicionales. Cualquier gestor de archivos que ofrezca un shell, un ejecutor de comandos o un terminal en el navegador está ofreciendo ejecución remota de código a quien tenga una sesión válida. La guía de FileBrowser recomienda mantener desactivado el ejecutor de comandos, mientras que la configuración de ejemplo de Cloud Commander habilita la consola. Tome esta decisión de forma explícita, no por defecto.

Qué falla primero y qué errores verá

listen tcp :80: bind: permission denied. Linux reserva los puertos inferiores a 1024 para procesos privilegiados. La configuración documentada de FileBrowser Quantum usa el puerto 80, lo que funciona dentro de un contenedor, pero falla en cuanto ejecuta el binario como un usuario sin privilegios en el host. Configure un puerto superior a 1024 en config.yaml y deje que el proxy gestione el puerto 443.

Las cargas fallan mientras la navegación funciona. Para listar un directorio se necesita r-x y para escribir en él se necesita w. La interfaz web muestra un error genérico, por lo que debe comprobar primero el sistema de archivos en lugar de los registros de la aplicación.

413 Request Entity Too Large. Ese error procede de nginx, no del gestor de archivos. El valor predeterminado de client_max_body_size es 1 MB, por lo que el proxy rechaza una carga grande antes de que la aplicación llegue a recibirla. Configure client_max_body_size 4096m; en el bloque server, o use 0 para desactivar la comprobación.

Los archivos cargados tienen el grupo incorrecto. Los archivos nuevos pertenecen al usuario del proceso, independientemente de lo que indique el directorio contenedor. Esto impide que un segundo servicio lea el mismo árbol. Asigne un grupo compartido a ambos servicios y establezca el bit setgid en el directorio con sudo chmod g+s /srv/files para que los archivos nuevos hereden el grupo del directorio.

Todo funciona en el puerto y falla detrás del proxy. Una aplicación servida bajo una subruta genera enlaces a partir de un prefijo que debe conocer. Cloud Commander dispone de --prefix para este fin. Si no existe una opción equivalente, asigne a la aplicación su propio subdominio y use el proxy para la ruta raíz.

¿Qué gestor de archivos autoalojado debería ejecutar?

• Un VPS, uno o dos directorios, enlaces compartidos con caducidad y quizá SSO más adelante: FileBrowser Quantum.
• Archivos que se encuentran en otro lugar, un bucket de S3, un host SFTP o un NAS mediante SMB, y una sola vista web para todos ellos: Filestash, dentro de los límites del nivel gratuito.
• Otras personas necesitan cuentas, cuotas y cargas mediante SFTP o FTPS: SFTPGo. Considere el cliente web una función adicional útil, no el motivo principal para elegirlo.
• Una herramienta personal con editor y terminal, accesible mediante un túnel SSH y nunca publicada: Cloud Commander.
• Nextcloud ya está en ejecución y existe un directorio que quiere exponer: la aplicación External Storage, sin instalar ningún software nuevo.

El despliegue importa más que la elección. Use un directorio, un usuario que no sea root, un puerto enlazado a localhost y autenticación delante. Un gestor de archivos configurado así es una herramienta práctica. El mismo software apuntando a / con una contraseña compartida es un shell remoto con una interfaz agradable.

FAQ

¿Sigue siendo seguro ejecutar FileBrowser en 2026?

El archivo filebrowser/filebrowser README del proyecto original indica que File Browser se archivará el 2026-09-01 y que no habrá nuevas versiones, correcciones de errores ni correcciones de seguridad. El código todavía funciona, pero el software sin parches que tiene acceso de escritura al sistema de archivos supone un riesgo que aumenta con el tiempo. Si lo conserva, siga las propias recomendaciones del proyecto: no lo exponga directamente a Internet, use un reverse proxy que gestione TLS y su propia autenticación, mantenga desactivado el ejecutor de comandos y use un contenedor sin privilegios con sólo el directorio servido montado. Tenga en cuenta también que sus sesiones son JWT autocontenidos, no identificadores gestionados por el servidor. Por tanto, no se pueden revocar y cambiar la contraseña no invalida un token ya emitido. Para una instalación nueva, use el fork FileBrowser Quantum, publicado como la imagen gtstef/filebrowser, cuyo desarrollo continúa.

¿Puede un gestor de archivos autoalojado usar mi SSO existente?

FileBrowser Quantum admite OIDC, LDAP y un modo de cabeceras del proxy. Por tanto, puede situarse detrás de un proveedor de identidad existente sin mantener una segunda lista de usuarios. La integración de OpenID Connect de SFTPGo está incluida en la versión de código abierto y asigna los usuarios del proveedor de identidad a administradores y usuarios de SFTPGo, tanto para las interfaces WebAdmin como WebClient. Filestash es la excepción que debe vigilar: a fecha de agosto de 2026, su página de precios incluye SSO (SAML, OIDC y LDAP) en el nivel de autoalojamiento de pago, desde $50 al mes, mientras que el nivel gratuito figura como AGPL v3 con hasta 3 usuarios. Cuando una aplicación no admite SSO, la alternativa es la autenticación delegada en el reverse proxy. Esta protege la página de inicio de sesión, pero no modifica los permisos internos de la aplicación.

¿Cuál de estos ofrece enlaces compartidos que caduquen?

SFTPGo ofrece la implementación más completa. Un usuario crea un enlace HTTP/S desde WebClient y puede limitar el número de descargas y subidas, establecer una contraseña, restringir el acceso por dirección IP de origen y definir una fecha de caducidad automática. FileBrowser Quantum admite enlaces compartidos con un tiempo de caducidad. El acceso puede ser anónimo o estar restringido a un usuario, y cada enlace puede tener permisos independientes de visualización, edición y subida. Filestash también tiene una función para compartir. Es el único caso en el que el servidor conserva una copia cifrada y persistente de las credenciales del almacenamiento, porque el enlace debe funcionar cuando la sesión del navegador ya no está activa. Cloud Commander no ofrece enlaces compartidos.

¿Es seguro apuntar un gestor de archivos a / si soy el único usuario?

No. El riesgo no depende realmente de si confía en sí mismo. El proceso tiene acceso de lectura y escritura a todo lo que pueda alcanzar su cuenta de usuario. Por tanto, cualquier acceso a esa sesión, una cookie robada, un error sin corregir en el controlador de subidas o una contraseña reutilizada se convierte en acceso a /etc, a sus claves SSH y al directorio de datos de todos los servicios. Limite el montaje a un solo directorio: /srv/files en lugar de /. Cloud Commander es donde este problema resulta más grave, porque su comando Docker publicado monta la raíz del host en /mnt/fs y su configuración de ejemplo establece "root": "/" con "auth": false. Cambie ambos valores antes de que el contenedor escuche en cualquier dirección distinta de localhost.