FileBrowser Quantum: o sucessor do File Browser, que foi arquivado

O File Browser foi, por uma década, a resposta mais simples para quem queria acessar os arquivos de um servidor pelo navegador: um binário em Go, uma pasta, uma porta. No dia 1º de setembro de 2026 o repositório filebrowser/filebrowser, com quase 36 mil estrelas, foi arquivado. Não haverá mais versões, correções de bugs nem de segurança. Quem ainda roda o File Browser em produção precisa de um plano, e o candidato natural é o FileBrowser Quantum, um fork que já tinha seguido caminho próprio muito antes do fim do original. Neste post, você vai entender por que o projeto acabou, o que o Quantum muda e como subir o Quantum com Docker, systemd e Nginx.

Por que o File Browser acabou

O File Browser nasceu como um plugin do servidor web Caddy, escrito por Henrique Dias quando ele tinha 15 anos, e virou projeto independente depois. Em 2020, Henrique já tinha se despedido uma vez (Goodbye File Browser) e passado a manutenção para a comunidade. Mantenedores vieram e foram embora, e no fim de 2025 o projeto estava há cerca de um ano sem manutenção. Ele reassumiu.

Em março de 2026, no texto Update On File Browser, ele colocou o projeto em modo somente manutenção: nada de recursos novos, prioridade para bugs e segurança. O problema é que os alertas de segurança não pararam de chegar. Em 28 de julho de 2026, veio o anúncio definitivo, Goodbye File Browser, for Real This Time. A última versão planejada, a v2.63.23, saiu em 27 de julho, e o arquivamento ficou marcado para 1º de setembro.

Os motivos estão no próprio texto, e são três:

• O código não tem conserto por remendo. Segundo o autor, o File Browser precisaria ser reescrito do zero com segurança e uma boa API em mente, coisas que não estavam na cabeça de um adolescente de 15 anos. O exemplo mais claro são as sessões: tokens expirados continuam funcionando em algumas situações, e o logout não invalida o token.
• Falta de tempo. Algumas horas na maioria dos fins de semana, lendo issues e alertas, não bastavam para manter a qualidade que ele queria.
• Falta de vontade. Era um projeto de mais de dez anos atrás, que cumpriu o objetivo, e manter um código que ele mesmo não considera bom deixou de dar prazer.

Os números confirmam o diagnóstico. A página de alertas de segurança do repositório lista 62 advisories publicados, 50 deles só em 2026, quatro classificados como críticos. Entre eles há injeção de comando antes da autenticação no hook de login, usuários de autocadastro herdando a raiz do servidor como escopo e links simbólicos que deixam um usuário ler e gravar fora da sua pasta.

O que ficou sem correção

O README do projeto arquivado lista duas classes de problema que não serão corrigidas:

• Execução de comandos, runner e hooks. O recurso acumula vulnerabilidades e precisaria de reescrita. Vem desligado por padrão; se alguém o religar com --disable-exec=false, rodar comandos pela interface equivale a ter shell no servidor.
• Sessões e JWT. As sessões são JWTs autocontidos, sem identificador no servidor, e por isso não podem ser revogadas. Logout, troca de senha e renovação deixam os tokens antigos válidos até expirar, e o mesmo token de renovação pode ser usado várias vezes. Um token vazado vale até o fim da validade.

A orientação oficial para quem continuar usando é tratar o File Browser como software sem manutenção: não expor direto à internet, colocar um proxy reverso que termine o TLS e faça autenticação própria, manter o executor de comandos desligado e rodar sem privilégios, dentro de um contêiner, montando só a pasta que precisa ser servida. O próprio Henrique diz preferir que os usuários migrem para uma alternativa, sem recomendar nenhuma específica.

O que é o FileBrowser Quantum

O FileBrowser Quantum é um fork mantido por Graham Steffaniak. O repositório existe desde junho de 2023, bem antes do fim do original, e hoje tem cerca de 8,4 mil estrelas. A licença continua a mesma, Apache 2.0, e o código também é Go, com a interface web embutida no binário.

O README descreve o Quantum como um “fork massivo”: mudou a forma de configurar, de autenticar, de buscar e de compartilhar. Na prática, o que muda para quem vem do original:

• Várias fontes de arquivos (sources) ao mesmo tempo, cada uma com regras de inclusão e exclusão.
• Autenticação por senha com 2FA, OIDC (SSO), LDAP, JWT e proxy.
• Configuração em um único config.yaml, em vez de flags de linha de comando e ajustes guardados no banco.
• Busca indexada, com resultados enquanto você digita e filtros por tamanho, inclusive de pastas.
• Miniaturas de vídeo, documentos de escritório, capas de álbum e modelos 3D, além de tamanho de pastas na listagem.
• WebDAV para montar os arquivos como unidade de rede.
• Compartilhamentos configuráveis: validade, usuários permitidos (inclusive anônimos), tema e permissão de ver, editar ou enviar arquivos.
• API com tokens de longa duração e documentação Swagger em /swagger.
• Controle de acesso por usuário ou grupo e por caminho dentro de cada fonte.

E, tão importante quanto o que entrou, o que saiu: o terminal e a execução de comandos foram removidos, e o README diz que não voltarão. É justamente a área que o autor original declarou impossível de consertar.

Stable ou beta: qual versão usar

O Quantum tem dois canais, e a documentação de versões explica bem a diferença:

• stable (v1.5.x): a versão recomendada para quem está começando e para produção. Atualiza a cada um a três meses. Na data deste post, a mais recente é a v1.5.6-stable, de 4 de setembro de 2026. Usa o banco legado database.db.
• beta (v2.0.0): atualiza a cada uma a três semanas e troca o banco chave-valor por SQLite (filebrowser.sqlite), com camada de estado em memória, log de atividades e permissões por fonte (ver, baixar, modificar, criar e apagar). Exige migração única do banco e da configuração.

Este guia usa a stable. As imagens ficam no Docker Hub (gtstef/filebrowser) e no GitHub Container Registry (ghcr.io/gtsteffaniak/filebrowser). A tag stable traz FFmpeg e pré-visualização de documentos; a stable-slim tem só o serviço e também roda em ARM 32 bits, como Raspberry Pi antigos. Em produção, a documentação sugere fixar a série, por exemplo 1.5-stable, para receber correções sem pular de versão principal.

Arquitetura do guia

A montagem que vamos fazer é a mais comum em servidor: o Quantum roda em contêiner, publicado só em 127.0.0.1, e o Nginx fica na frente com TLS. As pastas de arquivos entram como volumes (as sources), e a configuração, o banco e o cache ficam juntos no diretório data, que é o que você precisa copiar no backup.

Teste rápido com Docker

Para olhar a interface antes de configurar qualquer coisa, sem persistência:

docker run --rm -p 127.0.0.1:8080:80 -v "$PWD:/srv" gtstef/filebrowser:stable

Abra http://127.0.0.1:8080 e entre com admin / admin. A pasta atual aparece como fonte. Quando fechar o contêiner, tudo o que foi configurado some.

Instalação com Docker Compose

Crie a estrutura. No contêiner, o arquivo de configuração padrão fica em /home/filebrowser/data/config.yaml, por isso a configuração, o banco e o cache vão todos para ./data:

mkdir -p filebrowser/data && cd filebrowser

Crie data/config.yaml com duas fontes, uma pasta de arquivos gerais e outra da equipe:

server:
  cacheDir: /home/filebrowser/data/tmp
  externalUrl: "https://arquivos.exemplo.com.br"
  sources:
    - path: /arquivos
      name: "Arquivos"
      config:
        defaultEnabled: true
    - path: /equipe
      name: "Equipe"

auth:
  adminUsername: admin

Os caminhos em sources são os de dentro do contêiner. defaultEnabled: true dá acesso à fonte para todos os usuários; a fonte Equipe, sem essa opção, precisa ser liberada pelo administrador para cada usuário. externalUrl é o endereço público usado nos links de compartilhamento. A documentação avisa: nunca use a raiz / como fonte, nem uma pasta que inclua /var.

Agora o compose.yaml:

services:
  filebrowser:
    image: gtstef/filebrowser:1.5-stable
    restart: unless-stopped
    environment:
      FILEBROWSER_ADMIN_PASSWORD: "${FB_ADMIN_PASSWORD}"
    volumes:
      - /srv/arquivos:/arquivos
      - /srv/equipe:/equipe
      - ./data:/home/filebrowser/data
    ports:
      - "127.0.0.1:8080:80"

A senha do administrador sai de uma variável de ambiente, não do YAML. Guarde-a num .env com permissão restrita e suba o serviço:

printf 'FB_ADMIN_PASSWORD=%s\n' "$(openssl rand -base64 24)" > .env
chmod 600 .env
docker compose up -d
docker compose ps
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/health

A imagem já traz um HEALTHCHECK que consulta /health na porta 80. Se você mudar server.port no config.yaml, sobrescreva o healthcheck no Compose com a porta nova. Mudanças no config.yaml exigem reiniciar o contêiner com docker compose restart.

Se Docker ainda é novidade para você, vale ler a história do Docker para entender de onde vêm volumes, imagens e o Compose.

Sem Docker: binário com systemd

O Quantum também é distribuído como binário para Linux em amd64, arm64, armv6 e armv7. As pré-visualizações de vídeo dependem do FFmpeg instalado no sistema:

VERSION=v1.5.6-stable
ARCH=amd64    # ou arm64, armv7, armv6

sudo apt install -y ffmpeg
curl -fL -o /tmp/filebrowser \
  "https://github.com/gtsteffaniak/filebrowser/releases/download/${VERSION}/linux-${ARCH}-filebrowser"
sudo install -m 0755 /tmp/filebrowser /usr/local/bin/filebrowser

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/filebrowser filebrowser
sudo install -d -o filebrowser -g filebrowser -m 0750 /opt/filebrowser

Crie /opt/filebrowser/config.yaml, agora com os caminhos reais do servidor e escutando na porta 8080 (portas abaixo de 1024 exigiriam root):

server:
  port: 8080
  externalUrl: "https://arquivos.exemplo.com.br"
  sources:
    - path: /srv/arquivos
      name: "Arquivos"
      config:
        defaultEnabled: true

auth:
  adminUsername: admin

O usuário filebrowser precisa ter permissão de leitura e escrita nas pastas das fontes. Depois, a unit /etc/systemd/system/filebrowser.service, baseada na da documentação de instalação em Linux:

[Unit]
Description=FileBrowser Quantum
After=network.target

[Service]
Type=simple
User=filebrowser
WorkingDirectory=/opt/filebrowser
EnvironmentFile=/opt/filebrowser/filebrowser.env
ExecStart=/usr/local/bin/filebrowser -c /opt/filebrowser/config.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo chown filebrowser:filebrowser /opt/filebrowser/config.yaml
printf 'FILEBROWSER_ADMIN_PASSWORD=%s\n' "$(openssl rand -base64 24)" | sudo tee /opt/filebrowser/filebrowser.env >/dev/null
sudo chmod 600 /opt/filebrowser/filebrowser.env
sudo systemctl daemon-reload
sudo systemctl enable --now filebrowser
journalctl -u filebrowser -f

Para ir além de enable e journalctl, veja o guia de comandos essenciais do systemd.

Atrás do Nginx com HTTPS

O Quantum usa cookies para a sessão e eventos em tempo real (SSE) para atualizar a interface, então o proxy precisa repassar o Host e não pode bufferizar a resposta. Uploads grandes também exigem aumentar o limite de corpo do Nginx:

server {
    listen 443 ssl;
    server_name arquivos.exemplo.com.br;

    ssl_certificate     /etc/letsencrypt/live/arquivos.exemplo.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/arquivos.exemplo.com.br/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        client_max_body_size 10G;
    }
}

O certificado pode ser emitido com certbot --nginx -d arquivos.exemplo.com.br. Se quiser servir o Quantum num subcaminho, como https://exemplo.com.br/files/, ajuste server.baseURL no config.yaml e o location no Nginx. O guia de proxy reverso tem exemplos também para Traefik e Caddy.

Um detalhe útil: as rotas de compartilhamento ficam separadas em /public/. Se você colocar autenticação no proxy (um auth_request, por exemplo), pode deixar /public/ de fora, e os links compartilhados continuam funcionando sem login no proxy, protegidos pelo próprio hash e pela senha do compartilhamento. Rotas como /api/, /dav/ e /swagger/ sempre exigem usuário autenticado.

Migrando do File Browser original

Não é troca de imagem: o formato de configuração mudou. O Quantum lê tudo de um config.yaml, enquanto o original usava flags de linha de comando e ajustes guardados no banco. O guia de migração de configuração começa pelo levantamento do que você usa hoje:

ps aux | grep filebrowser        # flags em uso: --port, --address, --baseurl, --root...
systemctl cat filebrowser        # ou o compose.yaml: veja as flags e a pasta do banco

E a correspondência entre as flags antigas e as chaves novas:

• --port → server.port
• --address → server.address
• --baseurl → server.baseURL
• --root → server.sources[0].path
• --database → caminho do banco em server.database (ou variável de ambiente)

Três recursos do original não existem no Quantum: o terminal, os runners (comandos disparados por eventos) e a gestão de usuários pela linha de comando, que passa a ser feita pelo arquivo de configuração ou pela API. Se você dependia de hooks para rodar scripts depois de um upload, planeje uma alternativa fora da ferramenta, como um serviço que observe a pasta.

O guia cobre a configuração. Planeje recriar usuários e compartilhamentos no Quantum, ou aproveite a migração para ligar LDAP ou OIDC e deixar de manter senhas locais. Suba o Quantum em paralelo, apontando para as mesmas pastas, valide com alguns usuários e só então desligue o original.

Cuidados antes de expor

• Troque a senha padrão. O teste rápido entra com admin/admin; em produção, defina FILEBROWSER_ADMIN_PASSWORD e ative 2FA para o administrador.
• Publique só em 127.0.0.1 e deixe o Nginx cuidar do TLS. Um bloqueio de força bruta com fail2ban na frente não custa nada.
• Monte só o que precisa ser servido. Nada de fonte na raiz do sistema; cada volume é uma pasta específica.
• Fixe a versão (1.5-stable) e leia as notas de versão antes de atualizar, principalmente quando a v2.0.0 chegar ao canal stable, porque ela exige migração do banco.
• Faça backup de ./data: é ali que ficam configuração, usuários e compartilhamentos.

Para ficar sabendo quando o serviço cair, dá para monitorar o endpoint /health com o Go Uptime, e o Quantum combina bem com outros serviços self-hosted que já passaram por aqui, como o Vaultwarden e o Gitea.

Se os seus arquivos não estão todos num disco local, e sim espalhados entre SFTP, S3, SMB e WebDAV, vale conhecer o Filestash, que compara as três opções lado a lado.

Conclusão

O fim do File Browser é um exemplo honesto de como um projeto pessoal pode crescer além do que o autor consegue sustentar. Henrique Dias preferiu arquivar a manter um código que ele mesmo não considera seguro, e deixou as vulnerabilidades conhecidas documentadas. Para quem precisa de um gerenciador de arquivos web leve, o FileBrowser Quantum preserva a ideia original (um binário, uma pasta, o navegador) e acrescenta o que faltava: SSO, busca indexada, compartilhamentos com controle e nenhuma execução de comandos pela interface. A documentação completa está em filebrowserquantum.com.