Come fare il self-hosting di FreshRSS nel 2026: aggiornamento dei feed, API mobile e backup
Una guida pratica al self-hosting di FreshRSS che illustra Docker, porte, dati persistenti, TLS, sicurezza, backup e i problemi che ne impediscono l'uso in produzione. Con verifiche.
Un deployment di FreshRSS che non funziona non va necessariamente in crash. Potrebbe mostrare una pagina di accesso mentre i feed non vengono mai aggiornati perché cron è disabilitato o il DNS in uscita non funziona. Inizia invece con una verifica end-to-end: aggiungi i feed, esegui un aggiornamento pianificato, contrassegna un elemento come letto e sincronizza quello stato tramite l'API mobile.
Questa verifica rispecchia lo scopo catalogato di FreshRSS: un lettore RSS self-hosted con un'API mobile compatibile. Inoltre evidenzia prima di un semplice controllo di uptime le dipendenze mancanti, le ipotesi errate sul proxy e i dati effimeri.
Mappa FreshRSS prima di intervenire su Docker
Separa quattro aspetti di FreshRSS: l'ingress, il listener sulla porta 80, lo stato persistente e i servizi di supporto o la capacità locale. Il requisito esterno di FreshRSS è l'aggiornamento pianificato dei feed e l'accesso in uscita agli host dei feed. Verifica il DNS in uscita, il TLS e il comportamento del provider senza pubblicare un altro servizio in ingresso.
Esegui la transazione verificata — aggiungi i feed, esegui un aggiornamento pianificato, contrassegna un elemento come letto e sincronizza quello stato tramite l'API mobile — prima di considerare completata questa separazione. Misura il numero di feed, l'intervallo di aggiornamento, i publisher lenti, le scritture sul database e i client API simultanei e conserva il risultato insieme al record del deployment. Fornisce sia un criterio di accettazione sia la prima baseline di capacità.
Esegui il backup dello stato che FreshRSS non può ricreare
Crea un manifest di ripristino per FreshRSS: dati, estensioni e database selezionato. Monta /var/www/FreshRSS/data prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che quel percorso è effettivamente persistente. Verifica subito proprietario e spazio libero, perché un percorso montato ma non scrivibile equivale, di fatto, a nessuna persistenza.
Esegui il backup in un failure domain separato dal server in esecuzione. Ricrea FreshRSS dalla sua immagine fissata a una versione specifica e verifica che abbonamenti, categorie, stato di lettura, filtri ed estensioni vengano ripristinati e che l'aggiornamento pianificato recuperi un nuovo elemento. La guida ai volumi persistenti aiuta a tradurre questa esercitazione in una policy per snapshot e conservazione.
Scegli il trust boundary di FreshRSS
Analizza le minacce relative alle azioni eseguite da FreshRSS, non solo al suo modulo di accesso. In questo caso, il rischio principale è lasciare accessibili su un host pubblico la configurazione iniziale o l'utente predefinito. Implementa questo confine: completa la configurazione in privato, proteggi le password API e configura i proxy trusted prima di abilitare la sincronizzazione mobile.
CRON_MIN controlla il comportamento, non la riservatezza; convalidane tipo e valore e conserva separatamente le credenziali reali di FreshRSS. Non risolvere un errore di autorizzazione eseguendo il container come root o montando indiscriminatamente il sistema host. I limiti delle risorse fanno parte del design della sicurezza quando il numero di feed, l'intervallo di aggiornamento, i publisher lenti, le scritture sul database e i client API simultanei possono essere determinati dagli utenti.
Cosa deve superare FreshRSS prima dell'arrivo dei dati reali
Trasforma lo smoke test di FreshRSS in un comando di release ripetibile o in una breve runbook. Il suo output deve dimostrare questo risultato: aggiungere i feed, eseguire un aggiornamento pianificato, contrassegnare un elemento come letto e sincronizzare quello stato tramite l'API mobile. Registra insieme al risultato la versione dell'applicazione, il digest del container, l'hostname della route e l'identificatore dei dati di test.
Esegui lo stesso controllo dopo una normale sostituzione del container e dopo aver ripristinato altrove dati, estensioni e database selezionato. Il ripristino è riuscito quando abbonamenti, categorie, stato di lettura, filtri ed estensioni vengono ripristinati e l'aggiornamento pianificato recupera un nuovo elemento. Confronta i tempi e il consumo associati al numero di feed, all'intervallo di aggiornamento, ai publisher lenti, alle scritture sul database e ai client API simultanei; una variazione significativa merita un'indagine anche quando l'azione finale continua ad avere esito positivo.
Esegui quindi un errore controllato: nega temporaneamente il percorso di test utilizzato dall'aggiornamento pianificato dei feed e dall'accesso in uscita agli host dei feed. Conferma che FreshRSS segnali il problema e torni alla normalità senza modifiche manuali distruttive. Conserva solo l'estratto di log necessario e anonimizzato. Questo gate in quattro parti copre avvio, persistenza, ripristino e gestione degli errori.
Una baseline Docker per FreshRSS
Un avvio adatto alla produzione è volutamente semplice: stato denominato, porta esplicita e nessun segreto all'interno dell'immagine.
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
L'esempio è una baseline, non uno stack di supporto completo. Consenti e verifica il percorso in uscita o lato client richiesto per l'aggiornamento pianificato dei feed e per l'accesso in uscita agli host dei feed. Controlla i mount effettivi e il listener, quindi prova ad aggiungere i feed, eseguire un aggiornamento pianificato, contrassegnare un elemento come letto e sincronizzare quello stato tramite l'API mobile. Fissa l'immagine funzionante a una versione specifica prima del riavvio successivo.
Impedisci che il successo del proxy nasconda un errore dell'applicazione
Browser, client API e FreshRSS devono concordare su un'unica origine. Per ottenere questo risultato, dichiara i proxy trusted e la base URL HTTPS canonica. Conserva host e protocollo originali, mantenendo però la porta 80 non disponibile come indirizzo pubblico alternativo.
La guida alla risoluzione dei problemi quando il sito è irraggiungibile aiuta a distinguere una route non raggiungibile da un'applicazione che risponde. Questa distinzione è importante: i feed non vengono mai aggiornati perché cron è disabilitato o il DNS in uscita non funziona. Solo il primo problema si risolve modificando l'ingress; il secondo richiede un'analisi dei log, dello stato o del carico di lavoro di FreshRSS.
Monitora il carico di lavoro, non solo il container
Osserva il lavoro eseguito da FreshRSS: numero di feed, intervallo di aggiornamento, publisher lenti, scritture sul database e client API simultanei. Imposta i limiti lasciando margine per questo lavoro ed evita un liveness probe che entri in competizione con esso. Il controllo dell'operatore dovrebbe comunque tentare di aggiungere i feed, eseguire un aggiornamento pianificato, contrassegnare un elemento come letto e sincronizzare quello stato tramite l'API mobile secondo una pianificazione.
Per gli aggiornamenti, ricorda che estensioni, migrazioni del database e modifiche al feed parser possono influire sugli aggiornamenti anche quando l'accesso continua a funzionare. Esegui il deployment della versione candidata su una copia ripristinata e ripeti il test noto. Se i feed non vengono mai aggiornati perché cron è disabilitato o il DNS in uscita non funziona, usa i log runtime e la richiesta di rete effettiva per individuare quale ipotesi è cambiata.
Sposta il lavoro infrastrutturale ripetibile su Dockup
Il deployment FreshRSS one-click di Dockup dovrebbe rendere sicura la sostituzione: la route continua a puntare alla porta 80, i segreti non sono incorporati nell'immagine e i percorsi persistenti vengono ripristinati nel nuovo container. Lo stesso deployment può essere eseguito sul compute di Dockup o su una macchina collegata.
Completa il lavoro specifico dell'applicazione consentendo e verificando l'aggiornamento pianificato dei feed e l'accesso in uscita agli host dei feed, applicando l'indirizzo pubblico canonico ed eseguendo questo controllo di accettazione: aggiungi i feed, esegui un aggiornamento pianificato, contrassegna un elemento come letto e sincronizza quello stato tramite l'API mobile. Aggiungi il risultato del ripristino alla runbook prima dell'arrivo degli utenti reali.
Domande frequenti
Di cosa ha bisogno FreshRSS per un deployment in produzione?
Instrada il container FreshRSS sulla porta 80 attraverso un'unica origine HTTPS. Il requisito esterno per la distribuzione è l'aggiornamento pianificato dei feed e l'accesso in uscita agli host dei feed. Non considerare FreshRSS pronto finché non puoi aggiungere i feed, eseguire un aggiornamento pianificato, contrassegnare un elemento come letto e sincronizzare quello stato tramite l'API mobile.
Quali dati di FreshRSS devono essere inclusi in un backup?
Rendi persistente /var/www/FreshRSS/data e includi dati, estensioni e database selezionato nello stesso manifest di ripristino. Un ripristino pulito di FreshRSS ha esito positivo solo quando abbonamenti, categorie, stato di lettura, filtri ed estensioni vengono ripristinati e l'aggiornamento pianificato recupera un nuovo elemento.
FreshRSS richiede HTTPS dietro un reverse proxy?
Usa HTTPS per l'origine pubblica di FreshRSS e mantieni la porta 80 nella route interna. Applica correttamente l'impostazione di FreshRSS: dichiara i proxy trusted e la base URL HTTPS canonica. Per FreshRSS, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento del client sensibile all'origine.
Come si deve testare un aggiornamento di FreshRSS?
Ripristina lo stato attuale di FreshRSS in un deployment isolato, applica la versione candidata e ripeti la relativa transazione di accettazione. Presta particolare attenzione, perché estensioni, migrazioni del database e modifiche al feed parser possono influire sugli aggiornamenti anche quando l'accesso continua a funzionare. Conserva l'immagine precedente di FreshRSS finché non sono chiari i limiti della migrazione dei dati e del rollback.