Migliori lettori RSS self-hosted per un piccolo VPS

Quale lettore RSS self-hosted è adatto a un piccolo VPS

Miniflux è il lettore RSS self-hosted più adatto a un piccolo VPS. È composto da un singolo binario Go e da PostgreSQL. Supporta le API Fever e Google Reader, quindi le app per telefoni di terze parti possono connettersi. Un aggiornamento richiede un solo docker compose pull. Scegli FreshRSS se ti servono le estensioni e vuoi un unico container con SQLite al suo interno.

Su un VPS vale la pena considerare cinque lettori: Miniflux, FreshRSS, CommaFeed, yarr e Tiny Tiny RSS. Questa pagina confronta le differenze effettive: la memoria richiesta da ogni stack, il database imposto da ciascuno, l'API di sincronizzazione richiesta dall'app per telefono e cosa accade durante un aggiornamento. Ogni dato riportato proviene dal progetto oppure è il risultato di un semplice calcolo; il testo specifica quale dei due casi si applica. Nessun dato costituisce un benchmark del tuo hardware, quindi misura il tuo server con docker stats.

I cinque lettori, un paragrafo ciascuno

Miniflux è scritto in Go e viene distribuito come un singolo binario compilato staticamente. La documentazione è chiara sull'unica dipendenza obbligatoria: "funziona solo con PostgreSQL". Non esiste una modalità SQLite. Offre una REST API, una API compatibile con Fever e una API compatibile con Google Reader, oltre all'importazione e all'esportazione OPML. La ricerca nel testo completo è affidata a PostgreSQL. Anche per questo il database non è opzionale.

FreshRSS è scritto in PHP e viene eseguito in un unico container che contiene sia il web server sia l'applicazione. SQLite è il database predefinito e non richiede un secondo servizio. Per installazioni più grandi sono supportati PostgreSQL e MySQL. Supporta la Google Reader API e la Fever API. L'installazione è già descritta in questa guida a FreshRSS su un VPS, quindi questa pagina lo confronta senza ripetere la procedura di installazione.

CommaFeed è scritto in Java e viene eseguito su Quarkus, con un'interfaccia che riprende quella di Google Reader. Il database viene scelto in fase di build, non a runtime. Per questo il progetto pubblica un'immagine per ogni database: athou/commafeed:latest-h2 per il database H2 integrato, athou/commafeed:latest-postgresql per PostgreSQL e altre varianti per MySQL e MariaDB. Espone una REST API e una API compatibile con Fever.

yarr (yet another rss reader) è un singolo binario Go con SQLite integrato e non richiede alcun container. Il comando ./yarr, senza opzioni, resta in ascolto su 127.0.0.1:7070. Le opzioni sono brevi: -addr 0.0.0.0:7070 -auth alice:secret lo espone sulla rete protetta da una password, mentre -db /data/yarr.db consente di specificare il percorso del database. Dispone di una API compatibile con Fever. La versione più recente contrassegnata come release è la v2.8, di luglio 2024, verificata ad agosto 2026. Consideralo quindi un software completo, non un progetto in sviluppo attivo.

Tiny Tiny RSS è il più vecchio dei cinque e anche il più complesso da eseguire. La configurazione Docker ufficiale comprende quattro servizi: un container PostgreSQL, un container applicativo PHP-FPM, un container updater separato che recupera i feed e un container nginx davanti all'applicazione. La documentazione dichiara esplicitamente che "questa configurazione usa PostgreSQL". Dispone di una propria JSON API, utilizzata dal client Android e da diverse applicazioni di terze parti. Fever non è supportato.

Quanta memoria richiede ogni stack

I valori riportati di seguito sono budget, non misurazioni: indicano il limite di memoria che ogni stack dovrebbe rispettare su un piccolo VPS. Il valore di CommaFeed corrisponde all'esempio pubblicato dal progetto, che limita il container a 256 MB. Gli altri valori sono limiti che lasciano margine al fetcher dei feed, cioè al componente che può aumentare bruscamente il consumo quando inizia un ciclo di aggiornamento.

[
  {
    "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
  }
]

yarr richiede meno memoria, con 128 MB, perché è composto da un solo binario e da un file SQLite, senza un server database né un runtime linguistico sottostante. Miniflux richiede 320 MB distribuiti su 2 container; la maggior parte è utilizzata da PostgreSQL, non da Miniflux. Tiny Tiny RSS è l'eccezione, con 640 MB distribuiti su 4 container, perché l'applicazione, l'updater, il database e il web server sono quattro processi distinti con quattro heap distinti.

Impostate questi valori come limiti effettivi, non come semplici obiettivi. Limiti di memoria in Docker Compose illustra la sintassi e il comportamento di un container quando raggiunge il limite. Un container senza limite non si arresta in modo controllato quando il sistema esaurisce la memoria: il kernel seleziona un processo e lo termina, e spesso il processo terminato non appartiene al container che ha causato la pressione sulla memoria.

Quale database impone ciascuna applicazione

Il database è la principale differenza operativa tra queste cinque applicazioni. È una decisione più importante di qualsiasi differenza nell'interfaccia utente, perché determina la procedura di backup e il rischio associato agli aggiornamenti.

Miniflux e la configurazione ufficiale di Tiny Tiny RSS richiedono PostgreSQL. Offre una ricerca full-text completa e scritture concorrenti sicure. Richiede però un secondo container, un volume e introduce un problema ricorrente: le immagini ufficiali di PostgreSQL non possono eseguire sul posto la migrazione dei dati tra versioni principali. La documentazione di Tiny Tiny RSS lo afferma esplicitamente e avverte che "i container ufficiali di PostgreSQL non supportano la migrazione dei dati tra versioni principali". Le opzioni realistiche sono mantenere bloccata la versione principale precedente oppure eseguire un dump e un ripristino con pg_dump e pg_restore. Pianifica questa operazione una volta ogni uno o due anni.

SQLite è il database predefinito di FreshRSS e yarr. Un solo file, nessun server, nessuna porta e nessuna password. Funziona bene per una singola persona con alcune centinaia di feed, ma rallenta quando più utenti eseguono scritture contemporaneamente. È in questo scenario che l'opzione PostgreSQL di FreshRSS diventa utile. yarr ha aggiunto il supporto opzionale a PostgreSQL nella versione v2.7, ma il file incorporato è il modo normale per eseguirlo.

H2 è il database incorporato predefinito di CommaFeed. Conviene valutarlo prima di iniziare, perché CommaFeed seleziona il database durante la compilazione dell'immagine. Passare in seguito da H2 a PostgreSQL non consiste nel modificare una configurazione. Richiede un'immagine diversa e una migrazione dei dati da eseguire autonomamente. Decidi quindi prima di accumulare un anno di cronologia delle letture nel sistema.

Funzionerà l'app sul telefono

Questa domanda è più importante di quanto molti pensino, perché l'interfaccia web rappresenta solo metà del modo in cui si utilizza un lettore di feed.

Miniflux espone un'API compatibile con Fever e un'API compatibile con Google Reader, quindi la maggior parte dei client per iOS e Android riesce a connettersi. FreshRSS espone le stesse due API e la relativa documentazione ne indica la priorità: l'API di Google Reader è la "best", con supporto completo delle funzionalità, mentre l'API di Fever offre "limited features and less efficient" behaviour. Prima che un'app possa autenticarsi, FreshRSS richiede inoltre due passaggi. In Authentication, abilita "Allow API access (required for mobile apps)", quindi crea una password API nel profilo dell'utente. Se non crei la password API, l'app restituisce un errore di autenticazione, mentre l'accesso web continua a funzionare. Il comportamento è confuso finché non sai dove cercare.

CommaFeed e yarr espongono soltanto un'API compatibile con Fever, quindi funzionano con i client compatibili con Fever, ma non con le app che supportano solo Google Reader. Tiny Tiny RSS dispone invece di una propria API, quindi devi usare un client sviluppato per questo prodotto. Verifica che l'app che preferisci supporti il lettore prima di importarvi 300 feed.

Un file Compose funzionante per un server con 1 GB di RAM

Questo è lo stack Miniflux, adattato dall'esempio Docker del progetto aggiornato ad agosto 2026. La porta pubblicata è associata all'interfaccia di loopback, l'indirizzo di ascolto è impostato in modo esplicito ed entrambi i container hanno un limite di memoria.

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:

Tre righe di questo file causano più spesso errori. LISTEN_ADDR=0.0.0.0:8080 è impostato perché il valore predefinito documentato del binario è 127.0.0.1:8080. Un processo associato all'interfaccia di loopback all'interno di un container non può essere raggiunto tramite la porta pubblicata. Il risultato è una reimpostazione della connessione, anche se il container risulta operativo. Il percorso del volume /var/lib/postgresql corrisponde a PostgreSQL 18. La versione 17 e le precedenti memorizzano i dati in /var/lib/postgresql/data. Se si monta il percorso errato, la directory dei dati non si trova affatto sul volume. Di conseguenza, tutti i dati scompaiono quando il container viene ricreato. 127.0.0.1:8080:8080 mantiene la porta non esposta a Internet, perché la pubblicazione di una porta senza specificare un indirizzo inserisce una regola in una catena che ufw non gestisce. Le porte Docker bypassano ufw spiega questo meccanismo, mentre un reverse proxy Traefik consente di anteporre TLS al servizio.

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

docker compose ps dovrebbe elencare entrambi i servizi come in esecuzione, con il database contrassegnato come healthy. Il primo avvio di Miniflux registra nel log le migrazioni dello schema. È questo il controllo attivato da RUN_MIGRATIONS=1. docker stats --no-stream mostra la colonna della memoria utilizzata in tempo reale. Questo è il valore da confrontare con i limiti riportati nella tabella precedente. Se il container Miniflux si riavvia continuamente, leggere il relativo log: connect: connection refused indica che il servizio è stato avviato prima che PostgreSQL fosse pronto ad accettare connessioni. È esattamente ciò che impedisce la condizione service_healthy. Verificare quindi che la condizione sia rimasta invariata dopo le modifiche. Se Compose è una novità, Nozioni di base su Docker Compose su un VPS illustra innanzitutto la struttura del file.

Cosa non entra in un server da 1 GB

Tiny Tiny RSS è il servizio da evitare. Il suo stack ufficiale di quattro servizi funziona su un VPS da 1 GB quando il VPS non esegue altro, ma non funziona insieme a un'altra applicazione che usa un database e a un reverse proxy. Quattro servizi significano quattro insiemi di overhead, e uno di questi è PostgreSQL.

CommaFeed entra, ma solo con l'immagine H2 e il limite di 256 MB impostato dall'esempio ufficiale del progetto. La combinazione che mette in difficoltà un server di piccole dimensioni è una JVM insieme a un server di database separato, perché una JVM utilizza tutta la memoria disponibile che le viene lasciata. La documentazione di CommaFeed indica -Xmx256m come limite rigido e descrive OpenJ9 come "un'alternativa più efficiente in termini di memoria alla JVM HotSpot": questo indica dove viene utilizzata la memoria.

Quando un server esaurisce la memoria, l'out of memory killer del kernel seleziona un processo e lo termina. dmesg -T mostra una riga come Out of memory: Killed process 1234 (java) e il container scompare semplicemente da docker compose ps senza alcun messaggio nel log dell'applicazione, perché l'applicazione non ha mai avuto la possibilità di scriverne uno.

Come si comportano gli aggiornamenti in ciascun caso

• Miniflux: docker compose pull && docker compose up -d, con le migrazioni dello schema applicate all’avvio quando RUN_MIGRATIONS=1 è impostato. Il rischio dell’aggiornamento non riguarda Miniflux. Riguarda la versione principale di PostgreSQL sottostante.
• FreshRSS: scarica la nuova immagine. Con SQLite non c’è alcun motore di database da aggiornare, quindi i problemi più comuni derivano da estensioni di terze parti non aggiornate.
• CommaFeed: scarica la variante dell’immagine compatibile con il tuo database. Il passaggio da latest-h2 a latest-postgresql non trasferisce i dati.
• yarr: sostituisci il binario e conserva il file del database. Poiché non è stata pubblicata alcuna release dopo la v2.8 di luglio 2024, verifica effettuata ad agosto 2026, in genere non c’è nulla da aggiornare.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Le migrazioni dello schema vengono eseguite automaticamente e l’interfaccia reindirizza a una schermata di migrazione quando è necessaria una conferma.

Esegui un dump del database prima di queste operazioni, non dopo.

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

Quanto costa in banda un intervallo di aggiornamento

I numeri riportati di seguito sono calcoli aritmetici, non misurazioni. Presuppongono 100 feed, una richiesta per feed a ogni intervallo e 40 KB per risposta. Il traffico reale è inferiore quando un server gestisce le richieste condizionali e superiore quando i feed contengono il testo completo degli articoli.

[
  {
    "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
  }
]

Un intervallo di cinque minuti su 100 feed genera 864,000 richieste e circa 34.6 GB al mese. Il polling ogni ora genera 72,000 richieste e circa 2.9 GB. Miniflux viene distribuito con POLLING_FREQUENCY impostato su 60 minuti, che corrisponde all'ultima riga del grafico. Questa impostazione predefinita è corretta per quasi tutti. Un articolo non arriva prima perché lo si richiede più spesso.

Le richieste condizionali mantengono il valore reale al di sotto del calcolo aritmetico. Un lettore che memorizza gli header ETag e Last-Modified restituiti da un feed li invia nuovamente come If-None-Match e If-Modified-Since. Un server che non ha nuovi contenuti risponde con 304 Not Modified senza corpo. La connessione comporta comunque il costo di un handshake, ma non quello del payload. I feed che ignorano le richieste condizionali inviano l'intero documento a ogni richiesta. Di conseguenza, pochi feed di grandi dimensioni possono incidere da soli in modo rilevante sul traffico trasferito.

Anche un polling troppo frequente può causare un blocco. Un server che rileva richieste eccessive risponde con 429 Too Many Requests, mentre alcuni siti rispondono invece con 403. Miniflux registra l'ultimo errore associato al feed. Per questo, l'elenco dei feed è il primo punto da controllare quando un feed smette di aggiornarsi mentre gli altri continuano a funzionare.

I feed scadono e un file OPML non è un backup

I feed scadono più rapidamente di quanto ci si aspetti. I domini possono scadere, i siti possono migrare verso piattaforme che non offrono feed e un URL che prima restituiva XML può iniziare a restituire una pagina di errore HTML con stato 200 OK. Quest'ultimo caso è il più problematico: il recupero ha esito positivo, l'analisi fallisce e il reader registra un errore di parsing anziché un errore di rete. Una volta all'anno, ordina l'elenco dei feed in base alla data dell'ultimo aggiornamento ed elimina quelli che non danno più segni di attività.

Un'esportazione OPML contiene l'elenco delle sottoscrizioni. Include gli URL dei feed e i nomi delle cartelle. Non include lo stato di lettura, gli articoli contrassegnati, le impostazioni per singolo feed, le regole di filtro né il testo degli articoli salvato. Se importi questo file OPML in una nuova installazione, recuperi i feed, ma tutti gli articoli già letti risultano nuovamente non letti.

Il backup importante è quello del database. Per PostgreSQL, il comando pg_dump riportato sopra esegue l'intera operazione. Per un reader basato su SQLite, come FreshRSS o yarr, arresta il processo che scrive nel database e copia il file oppure crea una copia coerente mentre il servizio è in esecuzione con sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Un semplice cp di un database in fase di scrittura può produrre un file che in seguito non si apre, perché la copia può includere una scrittura non completata. Poi trasferisci questi file fuori dal server secondo una pianificazione. È questo lo scopo dei backup restic su un VPS. Ripristinane almeno uno in un container temporaneo, così verifichi che la procedura funzioni.

Un feed reader è uno dei servizi più economici da gestire in autonomia. Per questo compare in ogni elenco delle soluzioni che vale la pena gestire in autonomia nel 2026. Affiancagli un'istanza SearXNG gestita in autonomia: sia la lettura sia le ricerche resteranno su hardware sotto il tuo controllo.

FAQ

Quale lettore RSS self-hosted usa meno memoria?

yarr. È un singolo binario Go con SQLite integrato, quindi non richiede un server di database né un runtime di linguaggio aggiuntivo; un limite di 128 MB è sufficiente. Il compromesso riguarda manutenzione e funzionalità: la versione più recente è la v2.8 di luglio 2024 e supporta soltanto l'API Fever. Se cerchi un progetto sviluppato attivamente con un consumo simile, Miniflux con PostgreSQL a 320 MB è la scelta migliore.

Posso eseguire un lettore RSS self-hosted su un VPS da 1 GB?

Sì. Miniflux con PostgreSQL rientra in circa 320 MB se imposti mem_limit su entrambi i container, mentre FreshRSS con SQLite rientra in un solo container. Su un VPS da 1 GB va evitato lo stack ufficiale di Tiny Tiny RSS, che comprende 4 servizi, incluso il proprio PostgreSQL. Imposta sempre i limiti di memoria, perché un container senza limiti su un host con la memoria esaurita può causare l'uccisione di un processo da parte del kernel; spesso il processo scelto è il database, non l'applicazione che ha causato il problema.

Quali di questi funzionano con le app RSS per iOS e Android?

Miniflux e FreshRSS supportano sia un'API compatibile con Fever sia un'API compatibile con Google Reader, quindi quasi tutti i client mobili possono connettersi. CommaFeed e yarr offrono soltanto l'API Fever. Tiny Tiny RSS usa una propria API, quindi serve un client progettato per questo software. In FreshRSS devi inoltre abilitare l'accesso all'API nella sezione Authentication e impostare una password API separata nel profilo; in caso contrario l'app non riesce ad autenticarsi, mentre il sito web continua a funzionare.

Un'esportazione OPML è un backup del mio lettore RSS?

No. OPML contiene gli URL dei feed e le cartelle, quindi ricostruisce l'elenco delle sottoscrizioni, ma nient'altro. Lo stato di lettura, gli elementi contrassegnati, le regole di filtro e il testo degli articoli sono memorizzati nel database. Esegui il backup del database con pg_dump per PostgreSQL oppure con un comando .backup per SQLite, quindi copia il risultato fuori dal server.

Miniflux supporta SQLite?

No. La documentazione del progetto afferma che "funziona solo con PostgreSQL" e la ricerca nel testo completo è implementata con funzionalità di PostgreSQL; non esiste quindi una modalità più leggera da attivare. Se vuoi un lettore di feed che non richieda alcun container per il database, esegui FreshRSS con il backend SQLite predefinito oppure yarr con il file incorporato.