Qual leitor RSS usar em um VPS pequeno

Qual leitor RSS auto-hospedado é adequado para um VPS pequeno

Miniflux é o leitor RSS auto-hospedado mais indicado para instalar num VPS pequeno. É um único binário Go acompanhado de PostgreSQL. Suporta as APIs Fever e Google Reader, por isso as aplicações móveis de terceiros conseguem ligar-se. Uma atualização consiste num único docker compose pull. Escolha FreshRSS quando precisar de extensões e de um único contentor com SQLite no seu interior.

Cinco leitores justificam o espaço em disco num VPS: Miniflux, FreshRSS, CommaFeed, yarr e Tiny Tiny RSS. Esta página compara as diferenças práticas entre eles: a memória necessária para cada stack, a base de dados que cada um exige, a API de sincronização necessária para a aplicação móvel e o que acontece no dia da atualização. Todos os valores apresentados foram publicados pelo projeto ou resultam de aritmética simples, e o texto indica qual dos dois casos se aplica. Nada disto é um benchmark do seu hardware. Meça o seu próprio servidor com docker stats.

Os cinco leitores, um parágrafo cada

Miniflux é escrito em Go e é distribuído como um único binário compilado estaticamente. A documentação é clara quanto à única dependência obrigatória: ele "funciona apenas com PostgreSQL". Não existe modo SQLite. Oferece uma API REST, uma API compatível com Fever e uma API compatível com Google Reader, além de importação e exportação de OPML. A pesquisa de texto completo é delegada ao PostgreSQL, o que explica em parte por que a base de dados não é opcional.

FreshRSS é escrito em PHP e é executado num único contentor que inclui o servidor Web e a aplicação. SQLite é a base de dados predefinida e não requer um segundo serviço, enquanto PostgreSQL e MySQL são suportados em instalações maiores. É compatível com a API do Google Reader e com a API do Fever. A instalação já está descrita em o nosso guia do FreshRSS num VPS, por isso esta página faz a comparação sem repetir a instalação.

CommaFeed é uma aplicação Java baseada em Quarkus, com uma estrutura que reproduz a do Google Reader. A base de dados é escolhida no momento da compilação, não durante a execução, por isso o projeto publica uma imagem por base de dados: athou/commafeed:latest-h2 para a base de dados H2 incorporada, athou/commafeed:latest-postgresql para PostgreSQL e outras variantes para MySQL e MariaDB. Essas tags correspondem a compilações nativas, e o sufixo -jvm identifica as variantes executadas numa JVM. Expõe uma API REST e uma API compatível com Fever. Desde a versão 7.3.0 (agosto de 2026), também oferece uma API compatível com Google Reader.

yarr (yet another rss reader) é um único binário Go com SQLite incorporado e não requer nenhum contentor. O ./yarr simples escuta em 127.0.0.1:7070. As opções são curtas: -addr 0.0.0.0:7070 -auth alice:secret permite o acesso pela rede protegido por uma palavra-passe, e -db /data/yarr.db coloca a base de dados no caminho pretendido. Tem uma API compatível com Fever. A versão mais recente identificada por uma tag é v2.9, de setembro de 2026, verificada em outubro de 2026, depois da v2.7 em junho e da v2.8 em julho, o que indica que o desenvolvimento voltou a estar ativo.

Tiny Tiny RSS é o mais antigo dos cinco e o mais pesado de executar. O projeto original em tt-rss.org foi encerrado em 1 de novembro de 2025, e o desenvolvimento continua num fork da comunidade em github.com/tt-rss/tt-rss, cuja documentação é agora o procedimento oficial de configuração. Essa configuração inclui quatro serviços: um contentor PostgreSQL, um contentor de aplicação PHP-FPM, um contentor updater separado que obtém os feeds e um contentor nginx à frente. A documentação afirma claramente que "esta configuração usa PostgreSQL". Tem a sua própria API JSON, utilizada pelo cliente Android e por várias aplicações de terceiros. Fever não faz parte da aplicação.

Quanta memória cada stack precisa

Os valores abaixo são limites, não medições: o teto de memória que cada stack deve respeitar numa pequena VPS. O valor do CommaFeed é o exemplo publicado pelo próprio projeto, que limita o container a 256 MB. Os restantes são limites que deixam margem para o feed fetcher, que é o componente que sofre picos quando começa um ciclo de atualização.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

O yarr é o que precisa de menos memória, com 128 MB, porque consiste num binário e num ficheiro SQLite, sem servidor de base de dados nem runtime de linguagem. O Miniflux precisa de 320 MB distribuídos por 2 containers, e a maior parte desse valor pertence ao PostgreSQL, não ao Miniflux. O Tiny Tiny RSS é a exceção, com 640 MB distribuídos por 4 containers, porque a aplicação, o updater, a base de dados e o servidor web são quatro processos separados, cada um com o seu próprio heap.

Defina estes valores como limites reais, não como expectativas. Limites de memória no Docker Compose explica a sintaxe e o comportamento de um container quando atinge o teto. Um container sem limite não falha de forma controlada quando o sistema fica sem memória: o kernel escolhe um processo e termina-o, e muitas vezes esse processo não pertence ao container que causou a pressão.

Qual base de dados cada leitor lhe impõe

A base de dados é a maior diferença operacional entre estes cinco leitores. É uma decisão mais importante do que qualquer diferença na interface de utilizador, porque determina o procedimento de cópia de segurança e o risco das atualizações.

O PostgreSQL é obrigatório no Miniflux e na configuração oficial do Tiny Tiny RSS. Oferece pesquisa de texto completo verdadeira e escritas concorrentes seguras. Em contrapartida, exige um segundo contentor, um volume e um problema recorrente: as imagens oficiais do PostgreSQL não conseguem migrar dados entre versões principais no local. A documentação do Tiny Tiny RSS afirma-o diretamente e avisa que "os contentores oficiais do PostgreSQL não têm suporte para migrar dados entre versões principais". Num leitor de feeds, as opções realistas são fixar a versão principal antiga ou fazer uma cópia e restaurá-la com pg_dump e pg_restore. O PostgreSQL também documenta pg_upgrade e atualizações baseadas em replicação. Estas opções justificam a configuração adicional em bases de dados grandes, nas quais o tempo de indisponibilidade é importante. A base de dados de um leitor de feeds raramente está nessa situação. Planeie esta operação uma vez a cada um ou dois anos.

O SQLite é a opção predefinida do FreshRSS e do yarr. É um único ficheiro, sem servidor, porta ou palavra-passe. Funciona bem para uma pessoa com algumas centenas de feeds. Fica mais lento quando vários utilizadores escrevem ao mesmo tempo. É nesse ponto que a opção PostgreSQL do FreshRSS começa a compensar. O yarr adicionou suporte opcional para PostgreSQL na v2.7, mas o ficheiro incorporado é a forma normal de o executar.

O H2 é a base de dados incorporada predefinida do CommaFeed. Vale a pena pensar nesta escolha antes de começar, porque o CommaFeed seleciona a base de dados quando a imagem é compilada. Mudar posteriormente de H2 para PostgreSQL não é uma alteração de configuração. É necessária uma imagem diferente e uma migração de dados que terá de executar manualmente. Tome a decisão antes de acumular um ano de histórico de leituras no sistema.

O seu aplicativo móvel funcionará

Esta questão é mais importante do que muitas pessoas esperam, porque a interface web é apenas metade da forma como um leitor de feeds é utilizado.

O Miniflux disponibiliza uma API compatível com Fever e uma API compatível com Google Reader, por isso a maioria dos clientes para iOS e Android consegue ligar-se a ele. O FreshRSS disponibiliza as mesmas duas APIs e a sua documentação estabelece uma ordem de preferência: a API do Google Reader é a "melhor", com suporte completo das funcionalidades, enquanto a API do Fever tem um comportamento com "funcionalidades limitadas e menos eficiente". O FreshRSS também requer dois passos antes de qualquer aplicativo poder iniciar sessão. Ative "Allow API access (required for mobile apps)" em Authentication e crie uma palavra-passe de API no perfil do utilizador. Se não criar a palavra-passe da API, o aplicativo apresenta uma falha de autenticação, enquanto o início de sessão pela web continua a funcionar. Isto é confuso até saber onde procurar.

O CommaFeed também disponibiliza agora as duas APIs: há muito tempo que inclui uma API compatível com Fever, e a versão 7.3.0 adicionou uma API compatível com Google Reader para aplicativos que não suportam Fever. Portanto, utilize a versão 7.3.0 ou posterior se o seu aplicativo só suportar Google Reader. O yarr disponibiliza uma API compatível com Fever e nenhuma outra, por isso funciona com clientes compatíveis com Fever, mas não com aplicativos que suportem apenas Google Reader. O Tiny Tiny RSS tem uma API própria, o que significa que precisa de um cliente desenvolvido para ele. Confirme se o seu aplicativo preferido suporta o leitor antes de importar 300 feeds para ele.

Um ficheiro compose funcional para uma máquina com 1 GB

Esta é a stack do Miniflux, adaptada do exemplo Docker do próprio projeto em outubro de 2026. A porta publicada está associada ao loopback, o endereço de escuta é definido explicitamente e ambos os contentores têm um limite de memória.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

As três linhas que mais frequentemente são configuradas incorretamente estão nesse ficheiro. LISTEN_ADDR=0.0.0.0:8080 repete o que a imagem oficial já define no respetivo Dockerfile. Por isso, juntamente com miniflux/miniflux, funciona como uma salvaguarda inofensiva, e não como uma correção. Esta definição é importante quando cria a sua própria imagem ou executa um binário empacotado, porque o valor predefinido documentado do binário é 127.0.0.1:8080. Um processo associado ao loopback dentro de um contentor não pode ser alcançado através da porta publicada. O resultado é uma ligação reiniciada, embora o contentor pareça estar saudável. O caminho do volume, /var/lib/postgresql, corresponde ao PostgreSQL 18. A versão 17 e anteriores armazenam os dados em /var/lib/postgresql/data. Montar o caminho errado significa que o diretório de dados não está no volume. Assim, todos os dados desaparecem na próxima recriação do contentor. 127.0.0.1:8080:8080 mantém a porta fora da Internet pública, porque publicar uma porta sem indicar um endereço escreve uma regra numa chain que o ufw não gere. As portas Docker ignoram o ufw explica esse mecanismo, e um reverse proxy Traefik é a forma de colocar TLS à frente do serviço.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps deve apresentar ambos os serviços como em execução, com a base de dados marcada como healthy. O primeiro arranque do Miniflux regista no log as migrações do schema. É isso que RUN_MIGRATIONS=1 desencadeia. docker stats --no-stream apresenta a coluna de memória em tempo real. Esse é o valor que deve comparar com os limites do gráfico acima. Se o contentor do Miniflux reiniciar continuamente, consulte o respetivo log. connect: connection refused significa que o serviço arrancou antes de o PostgreSQL estar pronto para aceitar ligações. É exatamente essa situação que a condição service_healthy impede. Por isso, confirme se a condição foi mantida depois das suas alterações. Se o Compose ainda for novo para si, Noções básicas do Docker Compose numa VPS explica primeiro a estrutura do ficheiro.

O que não cabe num servidor de 1 GB

Tiny Tiny RSS é a opção a evitar. A stack oficial com quatro serviços funciona num VPS de 1 GB quando esse VPS não faz mais nada. Não funciona no mesmo VPS que outra aplicação apoiada por uma base de dados e um reverse proxy. Quatro serviços significam quatro conjuntos de overhead. Um deles é o PostgreSQL.

CommaFeed cabe, mas apenas com a imagem H2 e o limite de 256 MB definido pelo exemplo do próprio projeto. A combinação que sobrecarrega um servidor pequeno é o CommaFeed juntamente com um servidor de base de dados separado. As variantes de imagem -jvm tornam a situação pior, porque a documentação do projeto avisa que uma JVM é gananciosa por predefinição e não devolve ao sistema operativo a memória que deixa de usar. As tags latest-h2 e latest-postgresql são compilações nativas. O projeto recomenda-as pelo menor consumo de memória. Por isso, use-as, a menos que tenha uma razão para executar a JVM.

Quando um servidor fica sem memória, o OOM killer do kernel escolhe um processo e termina-o. dmesg -T mostra uma linha como Out of memory: Killed process 1234 (java). O contentor simplesmente desaparece de docker compose ps sem mensagem no log da aplicação, porque a aplicação nunca teve oportunidade de escrever uma.

Como as atualizações funcionam em cada um

• Miniflux: docker compose pull && docker compose up -d, com as migrações do esquema aplicadas no arranque enquanto RUN_MIGRATIONS=1 estiver definido. O risco da atualização não está no Miniflux. Está na versão principal do PostgreSQL subjacente.
• FreshRSS: descarregue a nova imagem. Com SQLite, não há um motor de base de dados para atualizar, por isso os problemas habituais resultam de extensões de terceiros que não foram atualizadas.
• CommaFeed: descarregue a variante da imagem compatível com a sua base de dados. A mudança de latest-h2 para latest-postgresql não transporta os seus dados.
• yarr: substitua o binário e mantenha o ficheiro da base de dados. Foram lançadas versões em junho, julho e setembro de 2026, e a v2.9 era a mais recente em outubro de 2026, por isso consulte periodicamente a página de versões.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. O contentor da aplicação atualiza-se no arranque, e a FAQ do projeto associa os erros de atualização do esquema a um volume ou configuração de override incorretos. Se surgir um erro, verifique primeiro esses elementos. Se o seu ficheiro compose ainda descarregar imagens do projeto descontinuado tt-rss.org, mude-o para as imagens do fork (supahgreg/tt-rss no Docker Hub ou ghcr.io/tt-rss/tt-rss).

Faça um dump da base de dados antes de qualquer uma destas operações, não depois.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

O custo da frequência de atualização em largura de banda

Os números abaixo são cálculos, não medições. Pressupõem 100 feeds, uma solicitação por feed em cada intervalo e 40 KB por resposta. O tráfego real é menor quando um servidor aceita solicitações condicionais e maior quando os feeds incluem o texto integral dos artigos.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

Um intervalo de cinco minutos para 100 feeds corresponde a 864,000 solicitações e aproximadamente 34.6 GB por mês. A consulta a cada hora corresponde a 72,000 solicitações e cerca de 2.9 GB. O Miniflux é distribuído com POLLING_FREQUENCY definido como 60 minutos. Esse é o último valor da tabela, e a predefinição é adequada para quase todos. Um artigo não chega mais cedo porque o pediu com maior frequência.

As solicitações condicionais mantêm o valor real abaixo do cálculo. Um leitor que armazena os cabeçalhos ETag e Last-Modified devolvidos por um feed envia-os novamente como If-None-Match e If-Modified-Since. Um servidor sem novidades responde com 304 Not Modified e sem corpo. A ligação continua a ter o custo do handshake, mas não transfere o payload. Os feeds que ignoram solicitações condicionais enviam o documento completo todas as vezes. Por isso, alguns feeds grandes podem, por si só, dominar os custos de transferência.

Consultar com demasiada frequência também pode fazer com que seja bloqueado. Um servidor que determine que está a enviar demasiadas solicitações responde com 429 Too Many Requests, e alguns sites respondem com 403. O Miniflux regista o último erro no próprio feed. Por isso, a lista de feeds é o primeiro local a consultar quando um feed deixa de ser atualizado, mas os restantes continuam a funcionar.

Os feeds desaparecem, e um ficheiro OPML não é uma cópia de segurança

Os feeds deixam de funcionar mais depressa do que espera. Os domínios expiram, os sites mudam para plataformas sem feed e um URL que antes servia XML começa a servir uma página de erro HTML com um estado 200 OK. Este último caso é o mais problemático: a obtenção é concluída, a análise falha e o leitor regista um erro de análise em vez de um erro de rede. Uma vez por ano, ordene a lista de feeds pela data da última atualização e elimine os que deixaram de responder.

Uma exportação OPML é a sua lista de subscrições. Um ficheiro OPML padrão contém os URLs dos feeds e os nomes das pastas. O FreshRSS acrescenta o seu próprio espaço de nomes XML, que também guarda definições por feed, como o intervalo de atualização, os seletores XPath para extração e os filtros de leitura automática. No entanto, nenhuma exportação OPML guarda o estado de leitura, os artigos marcados ou o texto dos artigos que guardou. Se importar esse OPML para uma instalação nova, recupera os feeds, mas todos os artigos que já leu voltam a ser marcados como não lidos.

A cópia de segurança importante é a base de dados. No PostgreSQL, o comando pg_dump acima faz todo o trabalho. Num leitor SQLite, como o FreshRSS ou o yarr, pare o processo que escreve e copie o ficheiro, ou faça uma cópia consistente enquanto o processo está em execução com sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Um cp simples de uma base de dados que está a ser alterada pode produzir um ficheiro que não abrirá mais tarde, porque a cópia pode capturar uma escrita incompleta. Depois, envie esses ficheiros para fora do servidor segundo um agendamento. É para isso que servem as cópias de segurança restic num VPS. Restaure uma delas num contentor temporário pelo menos uma vez, para confirmar que o procedimento funciona.

Um leitor de feeds é um dos serviços mais baratos de alojar por conta própria. Por isso, aparece em todas as listas de serviços que vale a pena alojar por conta própria em 2026. Coloque ao lado dele uma instância SearXNG alojada por conta própria para manter tanto a leitura como as pesquisas em hardware que controla.

FAQ

Qual leitor RSS self-hosted usa menos memória?

yarr. É um único binário Go com SQLite integrado. Não precisa de um servidor de base de dados nem de outro runtime de linguagem. Por isso, um limite de 128 MB é suficiente. A desvantagem está nas funcionalidades: suporta apenas a Fever API, e a versão mais recente é a v2.9, de setembro de 2026. Se quiser suporte à Google Reader API e pesquisa de texto integral com um consumo semelhante, Miniflux com PostgreSQL a 320 MB é a melhor opção.

Posso executar um leitor RSS self-hosted numa VPS com 1 GB?

Sim. Miniflux com PostgreSQL cabe em cerca de 320 MB quando define mem_limit nos dois contentores, e FreshRSS com SQLite cabe num único contentor. O componente a evitar em 1 GB é a stack oficial do Tiny Tiny RSS, que inclui 4 serviços, incluindo o próprio PostgreSQL. Defina sempre limites de memória. Um contentor sem limite num servidor sem memória disponível pode ter um processo terminado pelo kernel. Muitas vezes, o processo escolhido é o da base de dados, e não o da aplicação com o problema.

Quais destes funcionam com aplicações RSS para iOS e Android?

Miniflux, FreshRSS e CommaFeed 7.3.0 ou posterior suportam uma API compatível com Fever e uma API compatível com Google Reader. Assim, quase qualquer cliente móvel se consegue ligar. yarr suporta apenas a Fever API. Tiny Tiny RSS usa a sua própria API. Por isso, precisa de um cliente criado para esse serviço. No FreshRSS, também tem de ativar o acesso à API em Authentication e definir uma palavra-passe de API separada no perfil. Caso contrário, a aplicação não consegue iniciar sessão, embora o website continue a funcionar.

Uma exportação OPML é uma cópia de segurança do meu leitor RSS?

Não. O OPML reconstrói a lista de subscrições. A exportação estendida do FreshRSS também inclui definições e filtros específicos de cada feed. No entanto, o estado de leitura, os itens marcados e o texto dos artigos ficam todos na base de dados. Faça uma cópia de segurança da própria base de dados com pg_dump para PostgreSQL, ou com um comando .backup para SQLite. Depois, copie o resultado para fora do servidor.

O Miniflux suporta SQLite?

Não. A documentação do projeto diz que "funciona apenas com PostgreSQL". A pesquisa de texto integral é implementada com funcionalidades do PostgreSQL. Por isso, não existe um modo mais leve para ativar. Se quiser um leitor de feeds sem qualquer contentor de base de dados, execute FreshRSS com o backend SQLite predefinido ou yarr com o ficheiro integrado.