Tutoriais de VPS
Implantar o OpenList (AList) em uma VPS (2026): Docker, WebDAV, montagem de nuvens, HTTPS e configuração de segurança
Implante o OpenList (AList) em uma VPS com Docker Compose, configure HTTPS com domínio, WebDAV, armazenamento local e drivers de nuvem, e entenda proteção de acesso, limitação de velocidade, custos de tráfego, backup, atualizações e falhas comuns.
Implantar o OpenList (AList) em uma VPS (2026): Docker, WebDAV, montagem de nuvens, HTTPS e configuração de segurança
Se você quer reunir Alibaba Cloud Drive, OneDrive, Google Drive, S3, WebDAV ou discos locais atrás de um único ponto de entrada web, o OpenList é uma das opções auto-hospedadas mais populares no momento. Ele é um fork do AList mantido pela comunidade e oferece pré-visualização de arquivos, links diretos, WebDAV, reprodução online, cópia entre armazenamentos e muitos drivers de armazenamento em nuvem.
Projetos assim costumam ser mal interpretados como "depois de instalar, você tem uma nuvem sem limite de velocidade". A velocidade real ainda depende da API da nuvem, da rede entre a VPS e o armazenamento, das permissões da conta, dos limites do provedor e da largura de banda de saída. Este artigo trata apenas do uso do OpenList em contas de armazenamento e arquivos para os quais você tem autorização, e não aborda a burla de permissões de plataforma, limites de download ou regras de compartilhamento.
O OpenList serve para:
- Quem quer unir várias nuvens pessoais ou buckets de armazenamento de objetos em um único diretório de arquivos;
- Quem quer dar aos familiares ou a uma equipe pequena um ponto de entrada unificado para navegar em arquivos;
- Quem precisa de WebDAV para que computadores, celulares ou softwares de mídia acessem diretórios remotos;
- Quem quer discos locais da VPS, S3 e nuvens na mesma interface de gerenciamento;
- Quem precisa de pré-visualização de arquivos, links diretos, compartilhamento temporário, reprodução de vídeo online ou cópia entre armazenamentos.
Se você precisa de colaboração entre várias pessoas, auditoria de permissões, histórico de versões e clientes de sincronização, Nextcloud, Seafile ou uma nuvem comercial são mais adequados. O OpenList é mais uma "camada de agregação e acesso ao armazenamento" e não deve ser tratado como seu único backup.
O programa principal do OpenList é muito leve; o que realmente consome recursos são miniaturas, reprodução de vídeo online, empacotamento de arquivos, cache, downloads com aria2 e múltiplos acessos simultâneos.
| Cenário | Configuração recomendada | Observações |
|---|---|---|
| Navegação pessoal e links diretos | 1 núcleo, 1 GB, SSD de 20 GB | Montar apenas pouco armazenamento, sem transcodificação |
| Uso familiar e WebDAV | 2 núcleos, 2 GB, NVMe de 40 GB | Deixar espaço para cache, logs e sistema |
| Vários armazenamentos, reprodução online | 2–4 núcleos, 4 GB, NVMe de 60 GB | Ficar atento à largura de banda de saída e ao número de conexões |
| Equipe pequena ou ponto de entrada público de arquivos | 4 núcleos, 8 GB, NVMe de 100 GB+ | Requer limitação de velocidade, monitoramento, backup e auditoria |
Se os arquivos ficam de fato nas nuvens, você não precisa comprar um disco local de VPS muito grande; se quiser usar armazenamento local, armazenar miniaturas em cache ou executar downloads offline, a capacidade de disco deve ser calculada conforme o crescimento dos dados. Você pode começar lendo Como escolher a configuração de uma VPS e Uma VPS precisa de armazenamento de objetos?.
| Opção | Posicionamento principal | Mais adequado para | Principais contrapartidas |
|---|---|---|---|
| OpenList | Agrega muitas nuvens e armazenamento local | Quem quer acesso unificado a vários armazenamentos | A autorização de contas, os limites do provedor e as diferenças entre drivers precisam ser tratados por você |
| AList | O projeto original e seu ecossistema | Quem tem configurações antigas ou depende de tutoriais antigos | Confirmar a manutenção do projeto e o estado da versão antes de migrar |
| Cloudreve | Nuvem auto-hospedada e uploads de usuários | Quem precisa de usuários, cotas, uploads e um sistema de compartilhamento | Custo maior de implantação e manutenção do banco de dados |
| Nextcloud | Colaboração, sincronização, permissões e plugins | Colaboração de arquivos em equipe | Maior uso de recursos e complexidade de atualização |
| Seafile | Sincronização eficiente de arquivos | Sincronização multidispositivo e discos de equipe | Requer planejamento separado de banco de dados e armazenamento |
A vantagem do OpenList não é substituir todas as nuvens, mas colocar o armazenamento existente atrás de um ponto de entrada unificado. Se você precisa realmente trazer seus dados de volta para o seu próprio servidor, deve planejar diretamente armazenamento local, armazenamento de objetos e backups, em vez de apenas montar nuvens de terceiros.
Use um Ubuntu 22.04/24.04 LTS ou Debian 12 limpos. Primeiro confirme que o Docker está disponível:
docker version
docker compose version
Crie o diretório de dados e restrinja as permissões:
sudo mkdir -p /etc/openlist
sudo chmod 750 /etc/openlist
cd /opt
sudo mkdir -p openlist
sudo chown -R "$USER":"$USER" /opt/openlist
cd /opt/openlist
O diretório de dados do OpenList contém o banco de dados, a configuração, os usuários, os drivers de armazenamento e o estado de execução. Não o coloque em um diretório temporário e não monte o diretório raiz do host diretamente no contêiner.
O Compose oficial usa a imagem openlistteam/openlist e monta o /etc/openlist do host no /opt/openlist/data do contêiner. Em produção, recomenda-se fixar a versão; comece com a v4.2.4 atualmente confirmada:
services:
openlist:
image: openlistteam/openlist:v4.2.4
container_name: openlist
restart: unless-stopped
user: "0:0"
environment:
UMASK: "022"
TZ: Asia/Shanghai
volumes:
- /etc/openlist:/opt/openlist/data
ports:
- "127.0.0.1:5244:5244"
- "127.0.0.1:5245:5245"
Salve como /opt/openlist/compose.yaml e inicie:
cd /opt/openlist
docker compose up -d
docker compose ps
docker compose logs --tail=100 openlist
Vincular a porta apenas a 127.0.0.1 serve para que a internet só possa acessar por meio do proxy reverso. O exemplo oficial mapeia diretamente 5244 e 5245, mas em uma VPS pública não é aconselhável expor a porta de gerenciamento original à internet.
Para ver as informações iniciais, verifique primeiro os logs do contêiner:
docker logs openlist --tail=100
Após o primeiro login, altere imediatamente a senha de administrador e o caminho de entrada segura, e salve as informações de recuperação. Não grave senhas iniciais, cookies ou tokens de armazenamento em repositórios públicos.
Prepare um domínio dedicado, por exemplo drive.example.com, e aponte o registro A para a VPS. Você pode usar Caddy, Nginx ou 1Panel como proxy reverso. Usando o Caddy como exemplo:
drive.example.com {
reverse_proxy 127.0.0.1:5244
}
O Caddy solicitará os certificados automaticamente, mas somente se o DNS, as portas 80/443, o firewall e a hora do servidor estiverem corretos. Depois que o painel ou a configuração do proxy estiver pronta, teste:
curl -I https://drive.example.com
Se encontrar falhas na solicitação de certificados, loops de redirecionamento ou erros de conexão com o upstream, consulte Guia completo para usar o Caddy como proxy reverso em uma VPS e Solução de loops de redirecionamento HTTPS em um site de VPS.
Não adicione 5244, 5245, portas de banco de dados e o Docker Socket ao grupo de segurança público. O WebDAV também deve usar HTTPS; não transmita senhas de conta por HTTP em texto simples.
Não use admin, o prefixo do e-mail ou o nome do site como conta de administrador. Use uma string longa aleatória para a senha e defina para a entrada de administração um caminho que não seja fácil de escanear. A entrada segura não é a única proteção; ela deve ser combinada com HTTPS, limitação de tentativas de login e backups.
Ao compartilhar diretórios publicamente, não torne todo o diretório raiz legível de forma anônima. Defina senhas ou exigência de login para diretórios sensíveis e defina tempos de expiração para links públicos. Ao testar, use um diretório dedicado não sensível; não faça experimentos diretamente na raiz de uma nuvem privada.
Se só você usa, você pode restringir o IP de origem do caminho de administração no firewall da nuvem ou na camada de proxy reverso. Quando os endereços de rede móvel mudam com frequência, usar WireGuard ou Tailscale para entrar na rede interna e depois acessar a página de administração do OpenList costuma ser mais confiável do que abrir o painel para todos os IPv4.
Tokens de atualização de nuvens, cookies, segredos de cliente e S3 Secret são credenciais altamente sensíveis. Não os exponha em capturas de tela, logs, tickets ou repositórios Git. Ao trocar senhas de conta, revogar autorizações ou suspeitar de vazamento, revogue o token antigo na plataforma de origem e vincule novamente.
A configuração de armazenamento do OpenList geralmente inclui tipo de driver, caminho de montagem, ordenação, diretório raiz e parâmetros de autorização. Recomenda-se adicioná-los na seguinte ordem:
- Primeiro adicione um diretório de teste local vazio;
- Confirme que a listagem, a pré-visualização, o download e as permissões funcionam;
- Depois adicione um armazenamento S3 ou WebDAV de baixo risco;
- Por último adicione nuvens com muitos arquivos;
- Para cada driver adicionado, teste a leitura de diretórios, o download de um arquivo e o download de arquivos grandes.
O diretório de armazenamento local deve ser um caminho acessível ao contêiner. Se você quiser montar o /srv/files do host, é preciso adicionar no Compose uma montagem explícita somente leitura ou leitura e gravação:
volumes:
- /etc/openlist:/opt/openlist/data
- /srv/files:/srv/files:ro
O modo somente leitura é adequado para exibição e download de arquivos. Se você habilitar upload, exclusão, renomeação ou movimentação pela web, será necessária permissão de leitura e gravação, mas o risco também é maior. Não monte /, /home nem diretórios que contenham chaves SSH.
O armazenamento S3 geralmente exige Endpoint, Region, Bucket, Access Key, Secret Key e caminho raiz. Recomenda-se criar uma Access Key de privilégio mínimo específica para o OpenList, permitindo acesso apenas ao Bucket ou prefixo especificado; não reutilize uma chave mestra com permissões de toda a conta.
O armazenamento de objetos é adequado para imagens, vídeos, backups e arquivos grandes, mas é preciso calcular o tráfego de saída, o número de requisições e os custos de download. O ponto de entrada web do OpenList não elimina os custos do armazenamento de objetos de origem; especialmente quando os links diretos recebem muitos acessos, configure limites de velocidade e alertas de largura de banda.
O WebDAV é adequado para conectar a serviços de arquivos auto-hospedados existentes ou armazenamento de escritório. Ao configurar, confirme a URL HTTPS, o usuário, a senha e o caminho raiz, e teste primeiro a leitura e gravação de arquivos pequenos. O desempenho e os mecanismos de bloqueio do WebDAV dependem do serviço de origem, por isso não convém tratá-lo às cegas como uma camada de distribuição de arquivos de alta concorrência.
Esses drivers exigem concluir a autorização conforme a interface atual do OpenList e a documentação oficial. Login, tokens de atualização, unidades familiares, unidades compartilhadas e políticas regionais podem mudar entre plataformas, então não copie cookies ou parâmetros de tutoriais antigos diretamente para produção.
Após a autorização bem-sucedida, monte primeiro um diretório de teste e depois verifique:
- Se a lista de arquivos está completa;
- Se os nomes de arquivo em chinês são exibidos corretamente;
- Se as pré-visualizações de vídeo e imagem funcionam;
- Se os links diretos funcionam como esperado em um navegador sem login;
- Se os logs vazam informações de autorização quando um download falha.
Monte apenas contas e arquivos aos quais você ou sua equipe têm autorização de acesso, e cumpra os termos de serviço e as regras de direitos autorais das nuvens de origem.
O OpenList pode servir como ponto de entrada WebDAV, permitindo que sistemas ou aplicativos acessem diretórios remotos. Ao usá-lo, observe:
- Não use a conta de administrador como usuário do WebDAV;
- Crie um usuário separado de baixo privilégio para o WebDAV;
- Acesse por HTTPS;
- Defina permissões de diretório mais rígidas para operações de upload e exclusão;
- Teste primeiro arquivos pequenos e depois arquivos grandes e transferências retomáveis;
- Não exponha a porta do WebDAV diretamente à varredura da internet.
Se você quiser fornecer um diretório de mídia ao Jellyfin, a um player ou a uma ferramenta de download, prefira deixar o aplicativo acessar uma montagem local estável ou o S3, em vez de fazer todo o tráfego passar pelo proxy do OpenList. A reprodução via proxy consome largura de banda de saída e conexões da VPS; se houver travamentos em horário de pico, verifique ao mesmo tempo a nuvem de origem, a rota da VPS e a saída pública.
A camada de acesso do OpenList não é uma CDN. Os seguintes tipos de tráfego são os que mais facilmente fazem a fatura disparar:
- Grande volume de reprodução de vídeo online;
- Links diretos públicos rastreados por mecanismos de busca ou scripts;
- Downloads de pastas empacotadas;
- Uploads de visitantes reencaminhados repetidamente;
- Vários usuários baixando ao mesmo tempo da mesma VPS.
Recomenda-se separar por finalidade:
- Coloque imagens públicas e arquivos estáticos no armazenamento de objetos com CDN;
- Acesse arquivos privados por login ou links temporários;
- Permita o painel administrativo apenas de origens fixas;
- Defina limites de velocidade e tempos de expiração para downloads anônimos;
- Configure alertas de tráfego tanto na VPS quanto no armazenamento de objetos.
Você pode cruzar as informações com vnStat, os gráficos de tráfego do provedor de nuvem e os logs do OpenList. O artigo do site Monitoramento de tráfego de VPS e alertas de excesso é útil para continuar investigando anomalias de largura de banda.
No mínimo, faça backup de:
- O diretório de dados
/etc/openlist; compose.yaml;- A configuração do proxy reverso;
- O domínio e os registros DNS;
- A lista de drivers de armazenamento;
- As notas de recuperação de autorizações de nuvens;
- Temas personalizados, scripts e tarefas externas.
Fazer backup apenas do diretório de dados do OpenList não equivale a fazer backup dos arquivos das nuvens. O OpenList armazena principalmente índices, configuração e informações de autorização; os arquivos reais continuam no disco local ou no armazenamento em nuvem de origem.
Antes de atualizar, registre a imagem atual:
docker inspect openlist --format '{{.Config.Image}}'
docker compose config > compose.before-upgrade.yaml
Depois faça backup do diretório de dados:
sudo tar -czf /opt/openlist-data-$(date +%F).tar.gz /etc/openlist
Copie o arquivo para outra máquina ou para o armazenamento de objetos e então baixe a nova versão. Não reconstrua latest em produção sem backup. Após atualizar, verifique primeiro o login, as listas de armazenamento, os links diretos, o WebDAV e os downloads, e só então decida se mantém a nova versão.
Ao reverter, restaure três partes ao mesmo tempo:
- A imagem anterior que funcionava;
- O
/etc/openlistde antes da atualização; - O proxy reverso e as variáveis de ambiente.
Se você reverter apenas a imagem mas mantiver uma estrutura de dados já migrada, pode iniciar com sucesso mas não conseguir ler a configuração. Antes de uma atualização formal, faça um ensaio em uma VPS temporária ou em um diretório de teste.
Verifique o estado do contêiner, a escuta de portas e as requisições locais:
docker compose ps
ss -lntp | rg '5244|5245'
curl -I http://127.0.0.1:5244
Se a porta estiver vinculada apenas à máquina local, o acesso público deve passar pelo proxy reverso. Verifique se o upstream do proxy está escrito como o endereço interno do contêiner, o endereço do host ou uma porta errada.
Verifique primeiro os logs do OpenList e os erros do driver de origem, e depois teste com um arquivo pequeno. Causas comuns incluem tokens expirados, caminho raiz errado, resposta 403 da origem, assinaturas de tempo expiradas, permissões insuficientes no armazenamento de objetos ou conexões de saída restritas.
Confirme primeiro o navegador, o driver de origem e a codificação real do arquivo, e depois verifique a versão e os logs do driver. Não renomeie em lote os arquivos originais de imediato; reproduza o problema em um diretório de teste e preserve os caminhos originais.
Verifique HTTPS, usuário, senha, caminho e se o proxy reverso aceita os métodos WebDAV. Alguns proxies permitem apenas GET/POST por padrão e podem bloquear PROPFIND, PUT, DELETE. Conecte primeiro um cliente de desktop a um diretório de teste e depois abra o diretório de produção.
Teste separadamente o link direto da nuvem de origem, a velocidade da VPS até a origem, a saída pública da VPS e a rota do cliente. Não olhe apenas para a CPU da VPS. Em downloads via proxy, largura de banda, número de conexões, limites da origem e custos de saída do armazenamento de objetos costumam ser mais críticos que a CPU.
O OpenList pode se conectar a muitos serviços de armazenamento, mas "tecnicamente montável" não significa "pode ser compartilhado publicamente sem critério". Antes de publicar, confirme:
- Que as contas e os arquivos estão dentro do escopo autorizado para você ou sua equipe;
- Que o compartilhamento, a reprodução online e os downloads cumprem os termos da plataforma de origem;
- Que os arquivos com direitos autorais têm uso legítimo;
- Que o serviço não é usado para burlar controles de acesso, limites de download ou restrições regionais;
- Que os diretórios públicos têm autenticação, links com expiração e logs de acesso ativados;
- Que cookies, tokens e arquivos privados de contas de terceiros não são entregues a administradores não confiáveis.
Se o objetivo é colaboração de arquivos em equipe, prefira um sistema com membros, auditoria, revogação e controle de versões, em vez de expor diretamente a raiz de uma nuvem.
Usuários individuais podem começar com uma VPS de 2 núcleos, 2 GB e NVMe de 40 GB executando OpenList, Caddy e alguns drivers de armazenamento. Quando o volume de arquivos crescer, a reprodução online começar ou várias pessoas acessarem, amplie memória, disco e largura de banda, e migre os arquivos grandes para o armazenamento de objetos.
A ordem de publicação recomendada é:
- Fixar a versão do OpenList e persistir
/etc/openlist; - Escutar apenas na porta local;
- Acessar por um domínio dedicado e HTTPS;
- Criar um usuário de baixo privilégio e um armazenamento de teste;
- Configurar limites de velocidade, alertas de tráfego e backups externos;
- Validar com arquivos pequenos, arquivos grandes, WebDAV e um simulado de recuperação;
- Só então abrir o compartilhamento de equipe ou público.
O OpenList é mais adequado como "ponto de entrada unificado e camada de acesso". Desde que você planeje com antecedência a autorização, a rede, os backups e os limites de custo, ele pode tornar várias nuvens e o armazenamento auto-hospedado mais fáceis de gerenciar.