Como fazer self-hosting do File Browser em 2026: volumes, contas e compartilhamento seguro

Trate o File Browser como um sistema pequeno, não como uma imagem Docker. O objetivo voltado ao usuário é claro: um gerenciador de arquivos web para um volume anexado; o deployment só é aceitável quando você consegue criar um usuário restrito, fazer upload e renomear um arquivo, editar texto, gerar um compartilhamento e confirmar que o usuário não consegue sair da raiz atribuída a ele.

Essa distinção identifica o modo de falha que os operadores encontram depois dos testes locais: os arquivos montados usam permissões do host que o container não consegue ler. Ela também torna o plano de backup e upgrade específico o suficiente para ser testado.

Encontre todos os bytes persistentes no File Browser

Uma imagem de container pode ser baixada novamente; os arquivos servidos, além do banco de dados e das configurações do File Browser, não podem. Monte /srv antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Inspecione o mount efetivo em vez de confiar no nome de um arquivo Compose e verifique se o usuário do runtime consegue gravar onde o File Browser espera.

Defina a retenção e um destino fora do host, depois ensaie a recuperação sem tocar na produção. O exercício só é aprovado quando os arquivos servidos, usuários, escopos, compartilhamentos e configurações retornam e uma conta restrita continua confinada. Para estados baseados em banco de dados, combine snapshots do storage com exports consistentes com a aplicação, conforme descrito em recuperação point-in-time versus snapshots.

Execute a primeira instância com características de produção

Mantenha a invocação inicial do File Browser reproduzível o suficiente para ser revisada em um 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

Não dependa de latest depois que existirem dados reais. Registre o digest usado, o usuário do container e a propriedade dos mounts. Acompanhe o log da aplicação durante um teste completo — crie um usuário restrito, faça upload e renomeie um arquivo, edite texto, gere um compartilhamento e confirme que o usuário não consegue sair da raiz atribuída a ele — e anote quaisquer migrations antes de colocar a rota atrás do tráfego de produção.

Defina o limite do runtime do File Browser

A saúde do processo e a saúde do produto são coisas separadas no File Browser. A porta 80 pode responder enquanto a transação voltada ao usuário ainda falha. O requisito do runtime local é um caminho persistente separado para o banco de dados e as configurações. Valide isso sob a carga de aceitação; um health check ocioso não consegue provar que o recurso é suficiente.

Use este exercício de readiness depois de mudanças relevantes de configuração: crie um usuário restrito, faça upload e renomeie um arquivo, edite texto, gere um compartilhamento e confirme que o usuário não consegue sair da raiz atribuída a ele. Mantenha verificações externas dispendiosas fora dos probes de liveness para que uma indisponibilidade de um provider não cause um restart loop. O trabalho de capacity planning deve acompanhar o throughput do disco subjacente, o tamanho dos uploads, os downloads simultâneos e a quantidade de diretórios, que representam melhor a pressão real sobre o File Browser do que as requisições de página.

Torne a origem pública inequívoca

Exponha um único hostname HTTPS para o File Browser; mantenha a porta 80 bruta privada. Publique a UI por HTTPS, mas defina cuidadosamente o escopo da raiz servida. Isso impede que browsers e clientes de API conheçam dois endereços concorrentes.

A partir de um cliente limpo, execute a transação conhecida como funcional e inspecione a primeira requisição que falhar. Use o guia de domínio personalizado quando houver problemas de DNS ou TLS. Trate “os arquivos montados usam permissões do host que o container não consegue ler” como um diagnóstico separado da aplicação depois que a rota estiver comprovada.

O release gate do File Browser

Crie uma fixture pequena e descartável do File Browser e mantenha-a para cada release. A fixture deve exercitar o workflow real: criar um usuário restrito, fazer upload e renomear um arquivo, editar texto, gerar um compartilhamento e confirmar que o usuário não consegue sair da raiz atribuída a ele. Registre o digest da imagem, o hostname externo, o endereço da dependência e o resultado esperado para que outro operador possa repetir o teste sem precisar interpretar este guia.

Execute a fixture três vezes. Primeiro, use o deployment novo. Em seguida, substitua o container sem tocar no estado persistente. Por último, restaure o backup em um ambiente vazio. A terceira execução só é aprovada quando os arquivos servidos, usuários, escopos, compartilhamentos e configurações retornam e uma conta restrita continua confinada. Em cada execução, capture a latência e o uso de recursos relacionados ao throughput do disco subjacente, ao tamanho dos uploads, aos downloads simultâneos e à quantidade de diretórios; isso se torna a baseline dos alertas, em vez de uma porcentagem arbitrária de CPU.

Por fim, teste deliberadamente o caminho negativo: envie uma entrada inofensiva próxima do limite de recurso ou formato associado a esta fronteira: os arquivos montados usam permissões do host que o container não consegue ler. Confirme que o File Browser falha de forma visível sem corromper o estado, restaure a condição correta e repita a transação bem-sucedida. Um registro de release contendo esses quatro resultados é uma evidência mais forte do que screenshots de um dashboard ou uma resposta única de curl.

Verificações de capacidade e upgrade

Um health check ocioso diz pouco sobre o File Browser. Monitore o throughput do disco subjacente, o tamanho dos uploads, os downloads simultâneos e a quantidade de diretórios; depois, gere alertas sobre o sintoma percebido pelos usuários: a falha da ação “criar um usuário restrito, fazer upload e renomear um arquivo, editar texto, gerar um compartilhamento e confirmar que o usuário não consegue sair da raiz atribuída a ele”. Mantenha o liveness local e barato; permita que o readiness informe migrations ou inicialização sem provocar uma tempestade de restarts.

A área de risco do upgrade é que as migrations do banco de dados e das configurações do File Browser são importantes, mesmo que os arquivos servidos estejam em um mount separado. Leia as release notes, faça um snapshot do estado, faça o deploy da versão-alvo usando uma cópia restaurada e repita a ação de aceitação. Se os arquivos montados usam permissões do host que o container não consegue ler, correlacione a requisição do cliente com o primeiro log relevante da aplicação em vez de apagar o estado ou adicionar redirects às cegas.

Reduza a autoridade concedida ao File Browser

As credenciais de bootstrap são temporárias; o modelo de confiança é permanente. No File Browser, evite servir / ou um diretório de secrets em vez de um share dedicado; sirva um diretório dedicado em vez da raiz do host e conceda a cada conta o escopo de arquivos mais restrito de que ela precisa.

O File Browser não tem um secret de bootstrap obrigatório nesta baseline; proteja a conta de administrador efetiva ou a autenticação upstream. Execute a imagem sem capabilities Linux desnecessárias e exponha apenas a rota pública da aplicação. Mantenha a atividade administrativa visível sem registrar valores secretos.

Use o Dockup para a camada de plataforma

Para o File Browser, o Dockup é mais útil na fronteira entre uma imagem e um serviço persistente. Ele mantém a rota para a porta 80, o TLS, os valores de secrets e o storage vinculados durante as substituições de containers, independentemente de o compute pertencer ao Dockup ou ao seu servidor anexado.

Finalize com o conhecimento da aplicação: publique a UI por HTTPS, mas defina cuidadosamente o escopo da raiz servida; confirme o requisito local — um caminho persistente separado para o banco de dados e as configurações; e execute esta verificação: crie um usuário restrito, faça upload e renomeie um arquivo, edite texto, gere um compartilhamento e confirme que o usuário não consegue sair da raiz atribuída a ele. Mantenha o resultado como uma verificação de deployment para que a próxima atualização da imagem seja avaliada pelo comportamento, não pelo status do container.

Perguntas frequentes

Do que o File Browser precisa para um deployment em produção?

Encaminhe o container do File Browser na porta 80 por meio de uma única origem HTTPS. O requisito do runtime local é um caminho persistente separado para o banco de dados e as configurações. Não considere o File Browser pronto até conseguir criar um usuário restrito, fazer upload e renomear um arquivo, editar texto, gerar um compartilhamento e confirmar que o usuário não consegue sair da raiz atribuída a ele.

Quais dados do File Browser devem fazer parte de um backup?

Persista /srv e inclua os arquivos servidos, além do banco de dados e das configurações do File Browser, no mesmo manifesto de recuperação. Uma restauração limpa do File Browser só é aprovada quando os arquivos servidos, usuários, escopos, compartilhamentos e configurações retornam e uma conta restrita continua confinada.

O File Browser precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do File Browser e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do File Browser: publique a UI por HTTPS, mas defina cuidadosamente o escopo da raiz servida. No File Browser, o HTTPS protege as credenciais ou o conteúdo dos usuários durante o trânsito e mantém consistente o comportamento do cliente sensível à origem.

Como testar um upgrade do File Browser?

Restaure o estado atual do File Browser em um deployment isolado, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial porque as migrations do banco de dados e das configurações do File Browser são importantes, mesmo que os arquivos servidos estejam em um mount separado. Mantenha a imagem anterior do File Browser até entender os limites da migração de dados e do rollback.