Como fazer self-hosting do Wallabag em 2026: importações, banco de dados e tarefas em segundo plano

A demonstração mais simples do Wallabag comprova apenas que um processo está escutando na porta 80. Em produção, são necessárias evidências mais robustas. O serviço precisa passar por este cenário mesmo depois que o container for substituído: salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado.

O Wallabag é implantado com um objetivo claro: funcionar como um arquivo de leitura posterior que elimina o excesso de elementos das páginas. A armadilha mais comum em sua implantação é fazer com que assets ou redirecionamentos de login usem HTTP porque a variável de domínio está incorreta. Por isso, o tratamento da URL pública e do estado persistente deve receber a mesma atenção que a inicialização da imagem.

Transforme o comando local em um serviço inspecionável

O comando a seguir torna visível o limite do container sem fingir provisionar todos os serviços externos.

docker run -d \
  --name wallabag \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallabag-data:/var/www/wallabag/data \
  -e SYMFONY__ENV__DOMAIN_NAME=https://app.example.com \
  wallabag/wallabag:latest

Antes de abrir o ingress, inspecione o ambiente resolvido, os mounts e o listener. Adicione as configurações de conexão revisadas para Postgres ou MariaDB, Redis e workers de importação agendados; use nomes privados para serviços privados. Uma inicialização bem-sucedida só termina quando você consegue salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado — não quando docker ps exibe Up.

Do que o Wallabag depende

Delimite três fronteiras ao redor do Wallabag: ingress na porta 80, estado persistente e requisitos de suporte. O container pode ser substituído, mas os outros dois elementos precisam de responsáveis explícitos. O contrato de rede do Wallabag inclui Postgres ou MariaDB, Redis e workers de importação agendados. Mantenha endpoints privados no DNS interno, permita apenas as chamadas de saída necessárias e forneça ao Wallabag uma credencial de serviço com escopo limitado.

O diagrama está completo quando um cliente limpo consegue salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado. Colete dados de tempo e recursos relacionados à busca de páginas, ao trabalho do parser, aos downloads de imagens, às filas e ao crescimento do banco de dados. Se a transação falhar, a primeira fronteira que não se comportar conforme documentado indicará se a investigação deve se concentrar no roteamento, na capacidade local ou em um serviço de suporte.

Reforce a segurança do Wallabag após o bootstrap

Não herde as premissas de segurança de um tutorial local. A preocupação específica do Wallabag é manter credenciais padrão ou ignorar a configuração do trusted proxy. Em produção, portanto, remova as credenciais padrão, proteja os tokens de importação e configure os trusted proxies antes de expor o leitor.

SYMFONY__ENV__DOMAIN_NAME é uma configuração, não um secret; mantenha seu valor explícito e proteja as credenciais separadas usadas pelo Wallabag. Restrinja o acesso ao sistema de arquivos e à rede, proteja os endpoints de configuração e defina limites de upload, requisições ou execução para a busca de páginas, o trabalho do parser, os downloads de imagens, as filas e o crescimento do banco de dados.

Torne a origem pública inequívoca

Exponha um único hostname HTTPS para o Wallabag e mantenha a porta 80 bruta privada. Defina o nome do domínio como a URL HTTPS final. Isso impede que browsers e clientes de API descubram dois endereços concorrentes.

Em um cliente limpo, execute a transação conhecida como válida e inspecione a primeira requisição que falhar. Use o guia de domínio personalizado quando houver problemas de DNS ou TLS. Trate o caso “assets ou redirecionamentos de login usam HTTP porque a variável de domínio está incorreta” como um diagnóstico separado da aplicação, depois que a rota estiver comprovada.

Separe containers substituíveis dos dados permanentes

O conjunto de recuperação persistente é composto por banco de dados, imagens, conteúdo importado e configuração. Monte /var/www/wallabag/data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para comprovar que esse caminho é realmente persistente. Um volume protege os dados contra a substituição do container, mas não contra a perda do host, a exclusão acidental ou a corrupção no nível da aplicação.

Faça backups que entendam a origem dos dados: use logical dumps para bancos de dados ativos quando necessário e copie arquivos somente a partir de um estado consistente. Mantenha uma cópia criptografada fora do host do Wallabag. O critério de aceitação de uma restauração é específico: artigos, tags, anotações, usuários e tokens de API devem retornar, e o cliente mobile deve sincronizar. O guia de backups testados com restauração explica por que o sucesso isolado de um job não é suficiente.

Evidências a coletar antes de colocar o Wallabag em produção

Para o Wallabag, defina uma transação conhecida como válida antes do lançamento: salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado. Mantenha seus pré-requisitos, a resposta esperada e as etapas de limpeza sob controle de versão, sem valores secretos. Fixe a imagem usada para estabelecer essa referência.

Use a transação para validar uma substituição e uma restauração independente. O serviço restaurado só será considerado aceitável quando artigos, tags, anotações, usuários e tokens de API retornarem e o cliente mobile sincronizar. Ao mesmo tempo, monitore a busca de páginas, o trabalho do parser, os downloads de imagens, as filas e o crescimento do banco de dados; transforme a parte mais lenta ou mais limitada em um alerta de nível de serviço.

O gate também precisa de um caso negativo: negue temporariamente à identidade de teste o acesso ao Postgres ou MariaDB, ao Redis e aos workers de importação agendados. Confirme que o Wallabag produz um erro acionável sem perder dados, restaure a condição válida e repita a transação conhecida como válida. Manter os dois resultados impede que um endpoint de health superficial se torne a única evidência de produção.

Opere o Wallabag em torno do gargalo real

Crie dashboards para a busca de páginas, o trabalho do parser, os downloads de imagens, as filas e o crescimento do banco de dados. Um gráfico de CPU sem o contexto dessa carga não consegue explicar por que o Wallabag está lento. Adicione uma verificação sintética ou agendada que tente salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado usando dados de teste inofensivos.

Antes de fazer um upgrade, considere este risco específico da aplicação: as migrations do Wallabag, o comportamento do parser e a configuração dos workers devem ser testados com páginas salvas representativas. Restaure um backup recente em uma implantação isolada, execute as migrations nesse ambiente e compare o comportamento. Se assets ou redirecionamentos de login usarem HTTP porque a variável de domínio está incorreta, inspecione a fronteira envolvida — origem pública, armazenamento ou dependência — antes de alterar configurações não relacionadas.

Use o Dockup para a camada de plataforma

Para o Wallabag, o Dockup pode criar a rota e o certificado TLS, preservar mounts, entregar secrets e colocar Postgres ou MariaDB, Redis e workers de importação agendados em uma rede privada, implantando no próprio Dockup ou em servidores anexados.

O gate de release continua sendo a transação concreta do Wallabag: salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado. Verifique também a condição de restauração: artigos, tags, anotações, usuários e tokens de API devem retornar, e o cliente mobile deve sincronizar. Essas duas verificações mostram se a implantação funciona e se pode ser recuperada.

Perguntas frequentes

Do que o Wallabag precisa para uma implantação em produção?

Encaminhe o container do Wallabag na porta 80 por meio de uma única origem HTTPS. O requisito de rede de suporte inclui Postgres ou MariaDB, Redis e workers de importação agendados. Não considere o Wallabag pronto até conseguir salvar um artigo comum e uma página difícil, executar a recuperação em segundo plano, sincronizar um cliente mobile e pesquisar o conteúdo arquivado.

Quais dados do Wallabag devem fazer parte de um backup?

Persista /var/www/wallabag/data e inclua o banco de dados, as imagens, o conteúdo importado e a configuração no mesmo manifesto de recuperação. Uma restauração limpa do Wallabag só será aprovada quando artigos, tags, anotações, usuários e tokens de API retornarem e o cliente mobile sincronizar.

O Wallabag precisa de HTTPS atrás de um reverse proxy?

Use HTTPS para a origem pública do Wallabag e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do Wallabag: defina o nome do domínio como a URL HTTPS final. No Wallabag, o HTTPS protege credenciais ou conteúdo de usuários durante o trânsito e mantém consistente o comportamento dos clientes sensível à origem.

Como testar um upgrade do Wallabag?

Restaure o estado atual do Wallabag em uma implantação isolada, aplique a versão candidata e repita sua transação de aceitação. Preste atenção especial, pois as migrations do Wallabag, o comportamento do parser e a configuração dos workers devem ser testados com páginas salvas representativas. Mantenha a imagem anterior do Wallabag até entender os limites da migração de dados e do rollback.