Comparativo de gerenciadores de arquivos self-hosted

O que é um gestor de ficheiros self-hosted e o que não é

Um gestor de ficheiros self-hosted é uma página web sobre a árvore de diretórios que já existe no seu VPS (servidor privado virtual). Inicia sessão, vê /srv/files exatamente como está no disco e pode enviar, mudar o nome, descarregar um ficheiro ou fornecer uma ligação. Nada é copiado para um segundo sistema. Por isso, um ficheiro que envia pelo navegador é o mesmo ficheiro que ls apresenta um segundo depois.

Os resultados de pesquisa confundem este conceito com software que desempenha outras funções. As ferramentas de sincronização mantêm uma cópia de todos os ficheiros em todos os dispositivos. É esse o objetivo de uma alternativa self-hosted ao Dropbox. O armazenamento de objetos não tem uma árvore de diretórios. Tem buckets e uma API. Por isso, executar o MinIO para armazenamento de objetos compatível com S3 responde a uma pergunta diferente. Os painéis de administração do servidor gerem a máquina, não os ficheiros. Essa é a questão abordada na comparação entre Cockpit e Webmin.

Pretende um gestor de ficheiros quando um colega precisa de obter um arquivo de 300 MB do servidor ou quando quer corrigir um erro de digitação num ficheiro de configuração através do telemóvel. A tarefa é pequena, e as ferramentas também.

Tenha este facto presente durante a leitura. Trata-se de uma aplicação web com acesso de leitura e escrita ao seu sistema de ficheiros, à escuta numa porta. Todas as escolhas abaixo dizem respeito, na prática, à quantidade do seu disco a que esse processo pode aceder.

O FileBrowser foi arquivado; leia isto antes de o instalar

O FileBrowser, o projeto filebrowser/filebrowser, é a resposta que a maioria dos guias ainda apresenta. O README começa agora com um aviso:

O File Browser foi arquivado em 2026-09-01. A última versão planeada já foi lançada. Não haverá mais versões, correções de bugs ou correções de segurança.

O código Apache 2.0 continua a funcionar. As correções de segurança deixam de ser lançadas. Isto é mais importante nesta categoria do que na maioria das outras, porque o objetivo do software é permitir acesso de escrita a um sistema de ficheiros através de HTTP.

Os responsáveis pelo projeto documentaram como continuar a utilizá-lo, e vale a pena seguir estas recomendações independentemente da ferramenta escolhida: não o exponha diretamente à Internet, coloque-o atrás de um reverse proxy que termine o TLS (transport layer security) e faça a sua própria autenticação, mantenha o executor de comandos desativado e execute-o sem privilégios num contentor com apenas o diretório que pretende disponibilizar montado no seu interior.

Uma linha desse README é mais importante do que as restantes. As sessões são JWTs (JSON web tokens) autónomos, e não identificadores mantidos no servidor, pelo que não podem ser revogados. Um token de sessão exposto continua válido até expirar, e alterar a palavra-passe não o invalida. Se mantiver o FileBrowser, a camada de autenticação à sua frente é que está a fazer o trabalho principal.

FileBrowser Quantum: o fork que continua a ser desenvolvido

O desenvolvimento ativo passou para um fork, o FileBrowser Quantum (gtsteffaniak/filebrowser), publicado como a imagem gtstef/filebrowser. A configuração foi reorganizada em torno de um único config.yaml, em vez da combinação antiga de flags da linha de comandos e definições na base de dados. O teste rápido documentado é:

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

Isto disponibiliza o diretório atual em http://localhost, e o primeiro início de sessão usa admin / admin. Altere-o antes de o contentor ficar acessível a partir de qualquer local que não seja a sua própria máquina.

Para uma instância permanente, use Compose, monte o diretório de dados em vez de um único ficheiro de base de dados e associe a porta 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

A configuração fica em /home/filebrowser/data/config.yaml e a base de dados em /home/filebrowser/data/filebrowser.sqlite. A versão 2.0.0 alterou o formato da base de dados e executa uma migração única. Por isso, a documentação pede a montagem de um diretório: uma montagem de um único ficheiro não deixa espaço para o novo ficheiro criado pela migração. Os caminhos dentro de config.yaml são caminhos do contentor. Por isso, uma origem na configuração deve indicar /folder, e não /srv/files. Inverter estes caminhos produz uma lista de ficheiros vazia sem qualquer erro, porque o diretório realmente não existe.

O projeto publica latest e stable com cerca de 60 MB e FFmpeg incluído para miniaturas de vídeo, além de stable-slim com cerca de 15 MB e apenas os componentes principais. Estes são os valores indicados na página de instalação em agosto de 2026. Fixe a tag escolhida. latest muda sem o informar, e um gestor de ficheiros que altera o formato da configuração enquanto o contentor está em execução é uma fonte de problemas.

Para esta função, é a opção mais completa entre as ferramentas pequenas. Disponibiliza várias origens com regras de inclusão e exclusão. Assim, uma instância pode expor /srv/media e /srv/docs com âmbitos diferentes. As partilhas têm um prazo de validade e podem ser anónimas ou restritas a um utilizador. A autenticação suporta OIDC (OpenID Connect), LDAP (lightweight directory access protocol), palavra-passe com dois fatores e um modo baseado num cabeçalho de proxy. Esse modo de proxy permite colocá-lo atrás de single sign on (SSO) através de um servidor Authentik autoalojado, em vez de manter uma segunda lista de utilizadores.

Filestash: uma interface sobre o armazenamento que já tem

Filestash tem uma abordagem diferente. É um frontend que se liga a um backend, e a lista de backends é extensa: FTP, SFTP (protocolo de transferência de ficheiros por SSH), S3, SMB, WebDAV, IPFS e cerca de mais vinte. É adequado quando os ficheiros não estão no servidor que executa a interface.

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

A imagem é machines/filestash:latest. Abra http://your_domain:8334. O primeiro ecrã define a palavra-passe de administrador. Defina-a imediatamente, porque, até o fazer, a consola de administração fica aberta a qualquer pessoa que encontre a porta.

Compreenda o modelo de identidade antes de criar a sua configuração. O Filestash não mantém uma base de dados de utilizadores no sentido habitual. As credenciais são armazenadas no seu browser através de cookies encriptados, autenticados e com o atributo HTTP only. Nada é mantido no servidor, a menos que utilize a funcionalidade de partilha. Nesse caso, o Filestash mantém uma versão persistente e encriptada das suas credenciais. Os "utilizadores" são contas de armazenamento: a identidade reside no backend, na conta SFTP ou na chave S3, e não no Filestash.

Este desenho é simples, mas tem um custo. A página de preços indica o nível gratuito self-hosted como AGPL v3 (GNU Affero General Public License), com até 3 utilizadores. Também inclui SSO (SAML, OIDC e LDAP) com controlo de acesso baseado em funções no nível self-hosted pago, a partir de $50 por mês, em agosto de 2026. Se o plano era "Filestash à frente do SSO da empresa, gratuitamente", consulte essa página antes de definir a arquitetura com base nessa premissa.

SFTPGo: um servidor de protocolos que também tem uma interface web

O SFTPGo é o software mais completo desta lista e aquele que é mais frequentemente recomendado pelo motivo errado. Disponibiliza SFTP, HTTP/S, FTP/S e WebDAV sobre sistema de ficheiros local, sistema de ficheiros local cifrado, armazenamento de objetos compatível com S3, Google Cloud Storage, Azure Blob Storage ou outro servidor SFTP.

São publicados binários, pacotes para Debian e Ubuntu e uma imagem de container. A linha atual do repositório APT e a respetiva chave de assinatura estão na página de instalação da documentação do SFTPGo. A opção com container é a forma mais rápida de o colocar em execução. Substitua tag pela versão pretendida:

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

O SFTP escuta na porta 2022 e as interfaces web na porta 8080. Monte /srv/sftpgo como um volume. Caso contrário, as contas e os respetivos ficheiros desaparecem quando o container é recriado, porque os diretórios pessoais dos utilizadores usam /srv/sftpgo/data/<username> por predefinição.

Existem duas interfaces web, e a diferença entre elas é a parte que a maioria dos textos deixa implícita. O WebAdmin, em /web/admin, é administrativo. É aqui que cria utilizadores, grupos, pastas virtuais e regras de eventos, além de definir quotas, limites de largura de banda e restrições de horário de acesso. O WebClient, em /web/client, é a interface do utilizador final. É onde uma pessoa navega pelos ficheiros, altera as próprias credenciais, configura a autenticação de dois fatores e cria partilhas.

Essas partilhas são o ponto mais forte desta comparação. Um utilizador pode criar ligações HTTP/S para partilhar ficheiros e pastas, limitar o número de transferências e carregamentos, proteger a partilha com uma palavra-passe, limitar o acesso por endereço IP de origem e definir uma data de expiração automática.

Então, por que motivo é necessária cautela? O foco principal está no modelo de contas e no servidor de protocolos, não na experiência de navegação. Escolha o SFTPGo quando outras pessoas precisarem de contas reais com quotas, quando os carregamentos chegarem por SFTP ou FTPS a partir de um sistema que não controla, ou quando um único bucket tiver de aparecer nos diretórios pessoais de vários utilizadores. As pastas virtuais fazem isso: uma pasta suportada por disco local, S3, GCS, Azure Blob, SFTP ou HTTP, montada em várias contas, com uma quota separada por utilizador numa pasta partilhada. Se tudo o que pretendia era uma página navegável sobre /srv/files, isto representa uma quantidade elevada de componentes para essa finalidade.

Há mais dois factos importantes. A edição Community usa a licença AGPL-3.0-only com termos adicionais, e existe também uma edição Enterprise licenciada comercialmente. O início de sessão OIDC está incluído na compilação de código aberto e associa os utilizadores do fornecedor de identidade aos administradores e utilizadores do SFTPGo em ambas as interfaces web. Também pode desativar globalmente a interface de cliente com enable_web_client na configuração httpd, ou por utilizador adicionando HTTP aos protocolos negados desse utilizador. Assim, o gestor de ficheiros pode existir para uma pessoa sem ficar disponível para todas.

Cloud Commander: dois painéis e um terminal para uma pessoa

O Cloud Commander é um gestor Node.js com licença MIT, baseado no estilo de dois painéis, com editor integrado, consola e terminal. Instale-o globalmente com npm i cloudcmd -g ou execute o contentor publicado:

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

Leia esse comando antes de o executar. -v /:/mnt/fs monta todo o sistema de ficheiros do anfitrião no contentor, e o exemplo ~/.cloudcmd.json fornece "root": "/", "auth": false e "console": true. Essa combinação significa que qualquer pessoa que consiga aceder à porta 8000 obtém acesso a todo o disco e a uma consola de comandos no servidor. É uma predefinição razoável para um portátil, mas inadequada para um VPS.

Restrinja o âmbito. O contentor lê /root/.cloudcmd.json, que o comando publicado fornece montando o seu diretório pessoal. Mantenha a montagem da configuração e remova o restante:

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

Nesse ficheiro de configuração, defina "root" como /srv/files, "auth" como true com um "username" e "password", e "console" e "terminal" como false, a menos que queira mesmo permitir acesso a uma shell pelo navegador. Também existem equivalentes de linha de comandos, incluindo --root, --auth, --username, --password e --prefix.

Seja claro sobre o que esta ferramenta é. Existe um único par de credenciais, não há restrições por utilizador, quotas nem ligações de partilha. É uma ferramenta pessoal. Por isso, associe-a a localhost como acima e aceda através de um túnel:

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

Depois, abra http://127.0.0.1:8000 no seu próprio computador. O gestor de ficheiros nunca fica exposto publicamente. O único serviço exposto à internet é o daemon SSH que já protegeu no seu VPS.

Por que o Nextcloud é a ferramenta errada para este trabalho

O Nextcloud é um bom software, mas não serve para isto. É uma plataforma de colaboração: uma aplicação PHP, uma base de dados, tarefas em segundo plano, clientes de sincronização para desktop e uma loja de aplicações. Executá-lo para obter uma visualização Web de /srv/files envolve muitos componentes para um trabalho pequeno e existe uma incompatibilidade específica. O Nextcloud mantém os metadados dos ficheiros numa tabela da base de dados, em vez de ler o diretório a cada pedido. Por isso, os ficheiros escritos pelo rsync ou por um cron job podem continuar invisíveis na interface até que uma verificação os inclua, com sudo -u www-data php occ files:scan --all. Um gestor de ficheiros lista o diretório quando a página é carregada, pelo que essa diferença não existe.

Use o Nextcloud para aquilo que faz bem: calendários, contactos, sincronização e partilha com pessoas que esperam um cliente para desktop. Nextcloud num VPS com Docker, TLS e cópias de segurança descreve essa configuração. Se já o executa e apenas precisa de ver um diretório existente, ative a aplicação External Storage e pare aí. Uma segunda aplicação Web com acesso de escrita ao mesmo disco é mais um componente para atualizar.

Como executar um sem expor o servidor inteiro

Nunca o aponte para /. O processo pode ler e escrever tudo a que a conta do utilizador tiver acesso. Assim, um token de sessão roubado transforma-se exatamente nesse nível de acesso ao sistema de ficheiros. Sirva apenas um diretório, /srv/files, e crie-o especificamente para esse fim.

Execute-o com um utilizador não root e monte apenas o que ele serve. No Compose, isso significa user: "1000:1000" e um bind mount por diretório, com :ro em tudo o que nunca precisar de alterar:

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

O resultado habitual dessa alteração é a navegação funcionar e os uploads falharem com permission denied, porque o ID de utilizador dentro do contentor não é proprietário do diretório fora dele. Compare os dois valores: docker exec filebrowser id mostra o utilizador do contentor; ls -ln /srv/files mostra o proprietário numérico no host. Corrija-o com sudo chown -R 1000:1000 /srv/files. Este é o mesmo problema de propriedade que PUID e PGID em imagens Docker existem para resolver.

Associe a porta publicada a localhost, 127.0.0.1:8080:80, em vez de 8080:80. O Docker escreve as suas próprias regras netfilter antes das regras do ufw. Por isso, uma porta publicada diretamente continua acessível a partir da Internet mesmo quando ufw deny 8080 está ativo. Coloque um reverse proxy à frente para tratar do TLS. Em HTTP simples, o cookie de sessão atravessa a rede sem encriptação, e esse cookie dá acesso ao sistema de ficheiros. Se o Compose ainda for novo para si, Docker Compose num VPS explica a estrutura de ficheiros assumida por estes exemplos.

Adicione uma camada de autenticação quando a autenticação da própria aplicação for limitada. A autenticação básica HTTP no proxy é suficiente para uma instância usada por uma só pessoa. Quando estiver envolvida mais do que uma pessoa, use OIDC ou forward auth com um identity provider. Assim, revogar uma conta revoga o acesso em todo o lado.

Desative as funcionalidades adicionais. Qualquer gestor de ficheiros que disponibilize uma shell, um executor de comandos ou um terminal no navegador está a oferecer execução remota de código a quem possuir uma sessão válida. A orientação do próprio FileBrowser é manter o executor de comandos desativado, enquanto a configuração de exemplo do Cloud Commander ativa a consola. Tome essa decisão deliberadamente, e não por predefinição.

O que falha primeiro e os erros que verá

listen tcp :80: bind: permission denied. O Linux reserva as portas abaixo de 1024 para processos privilegiados. A configuração documentada do FileBrowser Quantum usa a porta 80. Isto funciona dentro de um contentor, mas falha assim que executa o binário como utilizador sem privilégios no host. Defina uma porta acima de 1024 em config.yaml e deixe o proxy gerir a porta 443.

Os uploads falham, mas a navegação funciona. Listar um diretório requer r-x. Escrever nele requer w. A interface web apresenta um erro genérico. Por isso, verifique primeiro o sistema de ficheiros, e não os logs da aplicação.

413 Request Entity Too Large. Esse erro vem do nginx, não do gestor de ficheiros. O valor predefinido de client_max_body_size é 1 MB. Por isso, um upload maior é rejeitado no proxy antes de chegar à aplicação. Defina client_max_body_size 4096m; no bloco server ou use 0 para desativar a verificação.

Os ficheiros enviados ficam com o grupo errado. Os ficheiros novos pertencem ao utilizador do processo, independentemente do grupo do diretório envolvente. Isto impede que um segundo serviço leia a mesma árvore. Atribua um grupo partilhado aos dois serviços e defina o bit setgid no diretório com sudo chmod g+s /srv/files. Assim, os ficheiros novos herdam o grupo do diretório.

Tudo funciona na porta direta, mas falha atrás do proxy. Uma aplicação servida sob um subcaminho cria links a partir de um prefixo que tem de ser configurado. O Cloud Commander tem --prefix para este efeito. Quando não existir uma opção equivalente, atribua à aplicação o seu próprio subdomínio e faça o proxy do caminho raiz.

Qual gestor de ficheiros autoalojado deve executar?

• Um VPS, um ou dois diretórios, partilha de links com expiração e talvez SSO mais tarde: FileBrowser Quantum.
• Ficheiros que estão noutro local, num bucket S3, num anfitrião SFTP ou num NAS através de SMB, e uma única vista web para todos: Filestash, respeitando os limites do nível gratuito.
• Outras pessoas precisam de contas, quotas e carregamentos através de SFTP ou FTPS: SFTPGo, considerando o cliente web um recurso útil adicional, e não o motivo principal da escolha.
• Uma ferramenta pessoal com editor e terminal, acedida através de um túnel SSH e nunca publicada: Cloud Commander.
• O Nextcloud já está em execução e existe um diretório para expor: a aplicação External Storage, sem instalar software novo.

Independentemente da escolha, a implementação é mais importante do que o produto. Um diretório, um utilizador que não seja root, uma porta associada a localhost e autenticação à frente. Um gestor de ficheiros configurado dessa forma é uma ferramenta de conveniência. O mesmo software apontado para / com uma palavra-passe partilhada é um shell remoto com uma interface agradável.

FAQ

O FileBrowser ainda é seguro para executar em 2026?

O README filebrowser/filebrowser do projeto upstream informa que o File Browser foi arquivado em 2026-09-01 e que não haverá mais releases, correções de bugs ou correções de segurança. O código ainda funciona, mas software sem patches e com acesso de escrita ao seu sistema de ficheiros representa um risco que aumenta com o tempo. Se o mantiver, siga as recomendações do próprio projeto: não o exponha diretamente à internet, use um reverse proxy com TLS e autenticação própria, mantenha o command runner desativado e execute-o num contentor sem privilégios, montando apenas o diretório servido. Tenha também em conta que as sessões são JWTs autónomos, e não identificadores armazenados no servidor. Por isso, não podem ser revogados, e a alteração da palavra-passe não invalida um token já emitido. Para uma instalação nova, use o fork FileBrowser Quantum, publicado como a imagem gtstef/filebrowser, cujo desenvolvimento continua.

Um gestor de ficheiros self-hosted pode usar o meu SSO existente?

O FileBrowser Quantum suporta OIDC, LDAP e um modo de proxy header. Assim, pode ficar atrás de um fornecedor de identidade existente sem manter uma segunda lista de utilizadores. A integração OpenID Connect do SFTPGo está incluída na build open source e associa os utilizadores do fornecedor de identidade aos administradores e utilizadores do SFTPGo, tanto na interface WebAdmin como na WebClient. O Filestash é a exceção a considerar: em agosto de 2026, a página de preços inclui SSO (SAML, OIDC e LDAP) no nível self-hosted pago, a partir de $50 por mês, enquanto o nível gratuito é apresentado como AGPL v3 com até 3 utilizadores. Quando uma aplicação não suporta SSO, a alternativa é usar forward authentication no reverse proxy. Isto protege a página de login, mas não altera as permissões internas da aplicação.

Qual destes serviços fornece links de partilha que expiram?

O SFTPGo tem a implementação mais completa. Um utilizador cria um link HTTP/S a partir da WebClient e pode limitar o número de downloads e uploads, definir uma palavra-passe, restringir o acesso pelo endereço IP de origem e definir uma data de expiração automática. O FileBrowser Quantum suporta partilhas com tempo de expiração. O acesso pode ser anónimo ou restrito a um utilizador, e cada partilha pode ter permissões próprias para visualização, edição e upload. O Filestash também tem uma funcionalidade de partilha. É o único caso em que o servidor mantém uma cópia persistente e encriptada das credenciais de armazenamento, porque o link tem de funcionar depois de a sessão do browser terminar. O Cloud Commander não fornece links de partilha.

É seguro apontar um gestor de ficheiros para / se eu for o único utilizador?

Não. O risco não depende apenas de confiar em si próprio. O processo tem acesso de leitura e escrita a tudo o que a conta de utilizador conseguir alcançar. Assim, qualquer caminho até essa sessão, um cookie roubado, um bug sem patch no handler de upload ou uma palavra-passe reutilizada pode dar acesso a /etc, às suas chaves SSH e ao diretório de dados de todos os serviços. Em vez disso, limite o mount a um único diretório: /srv/files em vez de /. É no Cloud Commander que este problema é mais grave, porque o comando Docker publicado monta a raiz do host em /mnt/fs e o exemplo de configuração define "root": "/" com "auth": false. Altere ambos antes de o contentor escutar em qualquer endereço que não seja localhost.