Melhor leitor RSS para um VPS pequeno: comparação

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 sobre a ú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 funciona como um ú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á coberta no nosso guia do FreshRSS num VPS, por isso esta página faz a comparação sem repetir a instalação.

CommaFeed é escrito em Java sobre Quarkus, com uma interface baseada no Google Reader. A base de dados é escolhida no momento da compilação, não em tempo de 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. Expõe uma API REST e uma API compatível com Fever.

yarr (yet another rss reader) é um único binário Go com SQLite incorporado e não requer qualquer 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 expõe o serviço à rede protegido por 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 marcada mais recente é a v2.8, de julho de 2024, verificada em agosto de 2026; trate-o, portanto, como software concluído e não como um projeto em desenvolvimento ativo.

Tiny Tiny RSS é o mais antigo dos cinco e o mais pesado de executar. A configuração oficial para Docker tem 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 do projeto.

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 banco de dados cada leitor obriga você a usar

O banco de dados é a maior diferença operacional entre estes cinco leitores. Essa decisão é mais importante do que qualquer diferença na interface de utilizador, porque define o seu procedimento de backup e o risco das atualizações.

O PostgreSQL é necessário para o Miniflux e para a configuração oficial do Tiny Tiny RSS. Ele oferece pesquisa de texto completo e gravações concorrentes seguras. Em contrapartida, exige um segundo contentor, um volume e cria 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 isso diretamente e avisa que "os contentores oficiais do PostgreSQL não têm suporte para migrar dados entre versões principais". As opções realistas são fixar a versão principal antiga ou fazer dump e restore com pg_dump e pg_restore. Planeie fazer isso uma vez a cada um ou dois anos.

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

H2 é o padrão incorporado do CommaFeed. Vale a pena pensar nisso antes de começar, porque o CommaFeed escolhe o banco de dados quando a imagem é criada. Mudar de H2 para PostgreSQL mais tarde não é uma alteração de configuração. É necessário usar outra imagem e fazer manualmente uma migração dos dados. Por isso, tome essa decisão antes de ter um ano de histórico de leitura no servidor.

O aplicativo do seu telemóvel funcionará

Esta pergunta é 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 documentação própria classifica-as: a API do Google Reader é a "melhor", com suporte completo de funcionalidades, enquanto a API do Fever tem comportamento com "funcionalidades limitadas e menos eficiente". O FreshRSS também requer dois passos antes de qualquer aplicação poder iniciar sessão. Ative "Allow API access (required for mobile apps)" em Authentication e, depois, crie uma palavra-passe da API no perfil do utilizador. Se não criar a palavra-passe da API, a aplicação apresenta uma falha de autenticação, enquanto o início de sessão na interface web continua a funcionar. Isto é confuso até saber onde procurar.

O CommaFeed e o yarr disponibilizam ambos uma API compatível com Fever e nenhuma outra, por isso funcionam com clientes compatíveis com Fever, mas não com aplicações que suportem apenas Google Reader. O Tiny Tiny RSS tem a sua própria API, o que significa que precisa de um cliente desenvolvido para ele. Confirme se a sua aplicação preferida suporta o leitor antes de importar 300 feeds para o serviço.

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 agosto de 2026. A porta publicada está associada à interface de loopback, o endereço de escuta está 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 costumam ser configuradas incorretamente nesse ficheiro são estas. LISTEN_ADDR=0.0.0.0:8080 é definido porque o valor predefinido documentado do binário é 127.0.0.1:8080. Um processo associado à interface de loopback dentro de um contentor não pode ser acedido através da porta publicada. O resultado é uma ligação terminada, embora o contentor pareça estar saudável. O caminho do volume, /var/lib/postgresql, corresponde ao PostgreSQL 18. A versão 17 e as anteriores armazenam os dados em /var/lib/postgresql/data. Montar o caminho incorreto significa que o diretório de dados não está no volume. Assim, todos os dados desaparecem quando o contentor é recriado. 127.0.0.1:8080:8080 mantém a porta fora da Internet pública, porque publicar uma porta sem indicar um endereço adiciona uma regra a uma cadeia que o ufw não gere. As portas do 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 esquema. É isso que RUN_MIGRATIONS=1 inicia. 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, leia o respetivo log. connect: connection refused significa que arrancou antes de o PostgreSQL estar pronto para aceitar ligações. É precisamente isso que a condição service_healthy impede. Por isso, confirme se a condição foi preservada nas suas edições. Se o Compose ainda for novo para si, Noções básicas do Docker Compose numa VPS apresenta primeiro a estrutura do ficheiro.

O que não cabe num servidor de 1 GB

Tiny Tiny RSS é a opção a evitar. A sua stack oficial de quatro serviços funciona num VPS de 1 GB quando esse VPS não executa mais nada. Não funciona no mesmo servidor que outra aplicação com 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 próprio exemplo do projeto. O que sobrecarrega um servidor pequeno é executar uma JVM juntamente com um servidor de base de dados separado, porque a JVM utiliza toda a memória disponível que lhe for deixada. A documentação do CommaFeed aponta -Xmx256m como um limite rígido e descreve o OpenJ9 como "a more memory-efficient alternative to the HotSpot JVM". Isto indica onde a memória é consumida.

Quando um servidor fica sem memória, o out of memory killer do kernel escolhe um processo e termina-o. dmesg -T apresenta uma linha como Out of memory: Killed process 1234 (java), e o contentor simplesmente desaparece de docker compose ps sem qualquer 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 na inicialização 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 mecanismo de base de dados para atualizar. Por isso, as falhas 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. Mudar de latest-h2 para latest-postgresql não transfere os seus dados.
• yarr: substitua o binário e mantenha o ficheiro da base de dados. Sem uma versão lançada desde a v2.8 em julho de 2024, verificado em agosto de 2026, normalmente não há nada para atualizar.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. As migrações do esquema são executadas automaticamente, e a interface redireciona-o para um ecrã de migração quando é necessária confirmação.

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 é um backup

Os feeds ficam obsoletos 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 devolver uma página de erro HTML com um estado 200 OK. Este último caso é o mais difícil: a obtenção é bem-sucedida, 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. Contém os URLs dos feeds e os nomes das pastas. Não contém o estado de leitura, os artigos destacados, as definições por feed, as regras de filtragem nem 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 aparecer como não lidos.

O backup importante é o da base de dados. No PostgreSQL, o comando pg_dump acima executa todo o processo. 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 ele 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 escrita pode produzir um ficheiro que não abrirá mais tarde, porque a cópia captura uma operação de escrita incompleta. Depois, envie esses ficheiros para fora do servidor segundo um agendamento. É para isso que servem os backups restic num VPS. Restaure pelo menos um deles num contentor temporário para confirmar que o procedimento funciona.

Um leitor de feeds é um dos serviços mais baratos de alojar por conta própria, razão pela qual aparece em todas as listas de serviços que vale a pena alojar por conta própria em 2026. Coloque uma instância SearXNG alojada por conta própria junto dele 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, portanto não existe um servidor de base de dados nem um runtime de linguagem adicional, e um limite de 128 MB é suficiente. A contrapartida está na manutenção e nas funcionalidades: a versão mais recente é a v2.8, de julho de 2024, e suporta apenas a API Fever. Se quiser um projeto desenvolvido ativamente com uma utilização de recursos semelhante, Miniflux com PostgreSQL a 320 MB é a melhor opção.

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

Sim. O Miniflux com PostgreSQL cabe em cerca de 320 MB quando define mem_limit em ambos os contentores, e o FreshRSS com SQLite cabe num único contentor. O que deve evitar numa VPS com 1 GB é a stack oficial do Tiny Tiny RSS, que tem 4 serviços, incluindo o seu próprio PostgreSQL. Defina sempre limites de memória, porque um contentor sem limite num servidor com a memória esgotada faz com que o kernel termine um processo, e o processo escolhido é muitas vezes a base de dados, não a aplicação responsável pelo problema.

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

Miniflux e FreshRSS suportam uma API compatível com Fever e uma API compatível com Google Reader, por isso quase qualquer cliente móvel consegue ligar-se. CommaFeed e yarr oferecem apenas a API Fever. Tiny Tiny RSS usa a sua própria API, portanto precisa de um cliente criado para esse sistema. 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 site continue a funcionar.

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

Não. O OPML contém URLs de feeds e pastas, portanto reconstrói a lista de subscrições, mas não inclui mais nada. O estado de leitura, os itens marcados, as regras de filtragem e o texto dos artigos ficam 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, e copie o resultado para fora do servidor.

O Miniflux suporta SQLite?

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