Como hospedar o FreshRSS por conta própria em 2026: atualização de feeds, API móvel e backups

Uma implantação do FreshRSS com falha nem sempre apresenta um crash. Ela pode exibir uma página de login enquanto os feeds nunca são atualizados porque o cron está desativado ou o DNS de saída falha. Em vez disso, comece com uma verificação de ponta a ponta: adicione feeds, execute uma atualização agendada, marque um item como lido e sincronize esse estado por meio da API móvel.

Essa verificação corresponde ao propósito catalogado do FreshRSS: um leitor de RSS self-hosted com uma API móvel compatível. Ela também revela mais cedo dependências ausentes, suposições incorretas sobre o proxy e dados efêmeros do que uma verificação de uptime conseguiria.

Mapeie o FreshRSS antes de tocar no Docker

Separe quatro aspectos do FreshRSS: ingress, o listener na porta 80, o estado persistente e os serviços de suporte ou a capacidade local. O requisito externo do FreshRSS é a atualização agendada de feeds e o acesso de saída aos hosts dos feeds. Teste o DNS de saída, o TLS e o comportamento do provedor sem publicar outro serviço de entrada.

Execute a transação conhecida como válida — adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel — antes de considerar essa separação concluída. Meça a quantidade de feeds, o intervalo de atualização, os publishers lentos, as gravações no banco de dados e os clientes de API simultâneos, e mantenha o resultado junto ao registro da implantação. Isso fornece um critério de aceitação e a primeira referência de capacidade.

Faça backup do estado que o FreshRSS não consegue recriar

Crie um manifesto de recuperação para o FreshRSS: dados, extensões e o banco de dados selecionado. Monte /var/www/FreshRSS/data antes do bootstrap, grave dados de exemplo inofensivos e substitua o container para provar que esse caminho é realmente persistente. Verifique agora as permissões e o espaço livre, porque um caminho montado, mas sem permissão de escrita, na prática se comporta como se não houvesse persistência.

Faça backup em um domínio de falha separado do servidor em execução. Recrie o FreshRSS a partir da imagem fixada e verifique se as assinaturas, categorias, estado de leitura, filtros e extensões retornam e se a atualização agendada recupera um novo item. O guia de volumes persistentes ajuda a transformar esse exercício em uma política de snapshots e retenção.

Escolha o limite de confiança do FreshRSS

Modele as ameaças da ação executada pelo FreshRSS, não apenas do formulário de login. Nesse caso, o erro de maior risco é deixar a configuração inicial ou o usuário padrão acessível em um host público. Implemente este limite: conclua a configuração em ambiente privado, proteja as senhas da API e configure os trusted proxies antes de habilitar a sincronização móvel.

CRON_MIN controla o comportamento, não a confidencialidade; valide seu tipo e valor e armazene as credenciais reais do FreshRSS separadamente. Não resolva um erro de permissão executando o container como root ou montando o host de forma ampla. Os limites de recursos também fazem parte do design de segurança quando a quantidade de feeds, o intervalo de atualização, os publishers lentos, as gravações no banco de dados e os clientes de API simultâneos podem ser acionados pelos usuários.

O que deve passar antes que os dados reais do FreshRSS cheguem

Transforme o smoke test do FreshRSS em um comando de release repetível ou em um runbook curto. A saída deve demonstrar este resultado: adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel. Registre a versão da aplicação, o digest do container, o hostname da rota e o identificador dos dados de teste junto ao resultado.

Execute a mesma verificação depois de uma troca rotineira de container e após restaurar dados, extensões e o banco de dados selecionado em outro local. A restauração foi bem-sucedida quando as assinaturas, categorias, estado de leitura, filtros e extensões retornam e a atualização agendada recupera um novo item. Compare o tempo e o consumo relacionados à quantidade de feeds, ao intervalo de atualização, aos publishers lentos, às gravações no banco de dados e aos clientes de API simultâneos; uma grande alteração merece investigação mesmo quando a ação final ainda passa.

Em seguida, simule uma falha segura: negue temporariamente o caminho de teste usado pela atualização agendada de feeds e pelo acesso de saída aos hosts dos feeds. Confirme que o FreshRSS sinaliza a falha e retorna ao normal sem edições manuais destrutivas. Preserve apenas o trecho de log necessário e com os dados sensíveis removidos. Esse gate em quatro partes cobre inicialização, persistência, recuperação e tratamento de falhas.

Uma referência Docker para o FreshRSS

Uma inicialização com formato de produção é intencionalmente simples: estado nomeado, porta explícita e nenhum segredo dentro da imagem.

docker run -d \
  --name freshrss \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v freshrss-data:/var/www/FreshRSS/data \
  -e CRON_MIN=15 \
  freshrss/freshrss:latest

O exemplo é uma referência, não uma stack de suporte completa. Permita e verifique o caminho de saída ou do lado do cliente necessário para a atualização agendada de feeds e o acesso de saída aos hosts dos feeds. Verifique os mounts efetivos e o listener e, em seguida, tente adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel. Fixe a imagem que está funcionando antes da próxima reinicialização.

Evite que o sucesso do proxy mascare uma falha da aplicação

O navegador, o cliente de API e o FreshRSS devem concordar com uma única origem. Para que isso aconteça, declare os trusted proxies e a base HTTPS canônica. Preserve o host e o protocolo originais, mantendo a porta 80 indisponível como endereço público concorrente.

O guia de troubleshooting de site fora do ar ajuda a distinguir uma rota inacessível de uma aplicação que está respondendo. Essa distinção é importante aqui: os feeds nunca são atualizados porque o cron está desativado ou o DNS de saída falha. Apenas o primeiro caso é corrigido por alterações no ingress; o segundo exige a inspeção dos logs, do estado ou da carga de trabalho do FreshRSS.

Monitore a carga de trabalho, não apenas o container

Observe o trabalho executado pelo FreshRSS: quantidade de feeds, intervalo de atualização, publishers lentos, gravações no banco de dados e clientes de API simultâneos. Defina limites com margem para esse trabalho e evite uma liveness probe que concorra com ele. A verificação do operador ainda deve tentar adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel em um cronograma definido.

Para atualizações, lembre-se de que extensões, migrações do banco de dados e alterações no parser de feeds podem afetar as atualizações mesmo quando o login continua funcionando. Faça o deploy do candidato sobre uma cópia restaurada e repita o teste conhecido. Se os feeds nunca são atualizados porque o cron está desativado ou o DNS de saída falha, use os logs de runtime e a requisição de rede real para descobrir qual suposição mudou.

Transfira o trabalho de infraestrutura repetível para o Dockup

A implantação do FreshRSS em um clique do Dockup deve tornar a substituição segura: a rota continua apontando para a porta 80, os segredos não são incorporados à imagem e os caminhos persistentes retornam no novo container. A mesma implantação pode ser executada no compute do Dockup ou em uma máquina conectada.

Conclua o trabalho específico da aplicação permitindo e verificando a atualização agendada de feeds e o acesso de saída aos hosts dos feeds, aplicando o endereço público canônico e executando esta verificação de aceitação: adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel. Adicione o resultado da restauração ao runbook antes da chegada dos usuários reais.

Perguntas frequentes

O que o FreshRSS precisa para uma implantação em produção?

Encaminhe o container do FreshRSS na porta 80 por meio de uma única origem HTTPS. O requisito externo de entrega é a atualização agendada de feeds e o acesso de saída aos hosts dos feeds. Não considere o FreshRSS pronto até conseguir adicionar feeds, executar uma atualização agendada, marcar um item como lido e sincronizar esse estado por meio da API móvel.

Quais dados do FreshRSS devem fazer parte de um backup?

Mantenha /var/www/FreshRSS/data persistente e inclua dados, extensões e o banco de dados selecionado no mesmo manifesto de recuperação. Uma restauração limpa do FreshRSS só é bem-sucedida quando as assinaturas, categorias, estado de leitura, filtros e extensões retornam e a atualização agendada recupera um novo item.

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

Use HTTPS para a origem pública do FreshRSS e mantenha a porta 80 na rota interna. Aplique corretamente a configuração do FreshRSS: declare os trusted proxies e a base HTTPS canônica. No FreshRSS, 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 uma atualização do FreshRSS?

Restaure o estado atual do FreshRSS em uma implantação isolada, aplique a versão candidata e repita sua transação de aceitação. Dê atenção especial ao fato de que extensões, migrações do banco de dados e alterações no parser de feeds podem afetar as atualizações mesmo quando o login continua funcionando. Mantenha a imagem anterior do FreshRSS até entender os limites da migração de dados e do rollback.