Cum să găzduiești FreshRSS pe cont propriu în 2026: actualizarea fluxurilor, API mobil și backupuri

O implementare FreshRSS eșuată nu se blochează întotdeauna. Poate afișa pagina de autentificare, în timp ce fluxurile nu se actualizează niciodată deoarece cron este dezactivat sau DNS-ul outbound nu funcționează. Începe mai degrabă cu o verificare end-to-end: adaugă fluxuri, execută o actualizare programată, marchează un articol ca citit și sincronizează această stare prin API-ul mobil.

Această verificare corespunde scopului documentat al FreshRSS: cititor RSS găzduit pe propriul server, cu un API mobil compatibil. De asemenea, scoate mai devreme la iveală dependențele lipsă, presupunerile greșite despre proxy și datele efemere decât o verificare de uptime.

Cartografiază FreshRSS înainte să atingi Docker

Separă patru aspecte pentru FreshRSS: ingress, listenerul de pe 80, starea persistentă și serviciile auxiliare sau capacitatea locală. Cerința externă pentru FreshRSS este actualizarea programată a fluxurilor și accesul outbound la hosturile fluxurilor. Testează DNS-ul outbound, TLS-ul și comportamentul furnizorului fără să publici un alt serviciu inbound.

Rulează tranzacția verificată — adaugă fluxuri, execută o actualizare programată, marchează un articol ca citit și sincronizează această stare prin API-ul mobil — înainte de a considera separarea finalizată. Măsoară numărul de fluxuri, intervalul de actualizare, publisherii lenți, scrierile în baza de date și clienții API concurenți și păstrează rezultatul împreună cu înregistrarea implementării. Acesta oferă atât un criteriu de acceptanță, cât și primul baseline de capacitate.

Fă backup pentru starea pe care FreshRSS nu o poate recrea

Creează un manifest de recuperare pentru FreshRSS: date, extensii și baza de date selectată. Montează /var/www/FreshRSS/data înainte de bootstrap, scrie date de test inofensive și înlocuiește containerul pentru a demonstra că acea cale este într-adevăr persistentă. Verifică acum proprietarul și spațiul liber, deoarece o cale montată, dar fără drept de scriere, se comportă ca și cum nu ar exista deloc persistență.

Salvează backupurile într-un failure domain separat de serverul în execuție. Recreează FreshRSS din imaginea fixată și verifică dacă abonamentele, categoriile, starea articolelor citite, filtrele și extensiile reapar și dacă actualizarea programată preia un articol nou. Ghidul volumelor persistente te ajută să transformi acest exercițiu într-o politică de snapshoturi și retenție.

Alege granița de încredere pentru FreshRSS

Modelează amenințările asociate acțiunilor efectuate de FreshRSS, nu doar formularului de autentificare. În acest caz, greșeala cu cel mai mare risc este să lași configurarea inițială sau utilizatorul implicit accesibile pe un host public. Implementează această graniță: finalizează configurarea în mod privat, protejează parolele API și configurează proxy-urile de încredere înainte de a activa sincronizarea mobilă.

CRON_MIN controlează comportamentul, nu confidențialitatea; validează tipul și valoarea acestuia și stochează separat credențialele reale FreshRSS. Nu rezolva o eroare de permisiuni rulând containerul ca root sau montând pe scară largă sistemul host. Limitele de resurse fac și ele parte din proiectarea securității atunci când numărul de fluxuri, intervalul de actualizare, publisherii lenți, scrierile în baza de date și clienții API concurenți pot fi declanșate de utilizatori.

Ce trebuie să treacă înainte ca datele reale FreshRSS să ajungă în sistem

Transformă smoke test-ul FreshRSS într-o comandă de release repetabilă sau într-un runbook scurt. Rezultatul trebuie să demonstreze următoarea stare: adaugă fluxuri, execută o actualizare programată, marchează un articol ca citit și sincronizează această stare prin API-ul mobil. Înregistrează versiunea aplicației, digestul containerului, hostname-ul rutei și identificatorul datelor de test împreună cu rezultatul.

Rulează aceeași verificare după înlocuirea de rutină a containerului și după restaurarea datelor, extensiilor și bazei de date selectate într-un alt loc. Restaurarea a reușit atunci când abonamentele, categoriile, starea articolelor citite, filtrele și extensiile reapar, iar actualizarea programată preia un articol nou. Compară timpul de execuție și consumul asociate numărului de fluxuri, intervalului de actualizare, publisherilor lenți, scrierilor în baza de date și clienților API concurenți; o schimbare semnificativă merită investigată chiar și atunci când acțiunea finală trece în continuare.

Apoi testează o defecțiune sigură: blochează temporar calea de test utilizată pentru actualizarea programată a fluxurilor și accesul outbound la hosturile fluxurilor. Confirmă că FreshRSS semnalează problema și revine la normal fără modificări manuale distructive. Păstrează doar fragmentul de log necesar și anonimizat. Această verificare în patru pași acoperă pornirea, persistența, recuperarea și gestionarea defecțiunilor.

Un baseline Docker pentru FreshRSS

O lansare apropiată de producție este intenționat banală: stare denumită, port explicit și niciun secret în imagine.

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

Exemplul este un baseline, nu un stack auxiliar complet. Permite și verifică ruta outbound sau din partea clientului necesară pentru actualizarea programată a fluxurilor și accesul outbound la hosturile fluxurilor. Verifică mount-urile efective și listenerul, apoi încearcă să adaugi fluxuri, să execuți o actualizare programată, să marchezi un articol ca citit și să sincronizezi această stare prin API-ul mobil. Fixează imaginea funcțională înainte de următoarea repornire.

Împiedică succesul proxy-ului să ascundă o defecțiune a aplicației

Browserul, clientul API și FreshRSS trebuie să fie de acord asupra unei singure origini. Pentru ca acest lucru să fie posibil, declară proxy-urile de încredere și baza HTTPS canonică. Păstrează hostul și protocolul originale, menținând în același timp portul 80 indisponibil ca adresă publică concurentă.

Ghidul de depanare a site-urilor indisponibile te ajută să diferențiezi o rută inaccesibilă de o aplicație care răspunde. Această distincție este importantă aici: fluxurile nu se actualizează niciodată deoarece cron este dezactivat sau DNS-ul outbound nu funcționează. Doar primul caz se rezolvă prin modificări de ingress; al doilea necesită inspectarea logurilor FreshRSS, a stării sau a workloadului.

Monitorizează workloadul, nu doar containerul

Observă activitatea desfășurată de FreshRSS: numărul de fluxuri, intervalul de actualizare, publisherii lenți, scrierile în baza de date și clienții API concurenți. Setează limite cu suficient headroom pentru această activitate și evită un liveness probe care concurează cu ea. Verificarea operatorului ar trebui să încerce în continuare să adauge fluxuri, să execute o actualizare programată, să marcheze un articol ca citit și să sincronizeze această stare prin API-ul mobil, conform unui program.

Pentru update-uri, reține că extensiile, migrările bazei de date și modificările parserului de fluxuri pot afecta actualizările chiar și atunci când autentificarea încă funcționează. Implementează versiunea candidată pe o copie recuperată și repetă testul verificat. Dacă fluxurile nu se actualizează deoarece cron este dezactivat sau DNS-ul outbound nu funcționează, folosește logurile runtime și cererea de rețea efectivă pentru a identifica presupunerea care s-a schimbat.

Mută activitatea repetabilă de infrastructură în Dockup

Implementarea FreshRSS cu un singur click de la Dockup ar trebui să facă înlocuirea sigură: ruta continuă să trimită către 80, secretele nu sunt incluse în imagine, iar căile persistente reapar pe noul container. Aceeași implementare poate rula pe compute Dockup sau pe o mașină atașată.

Finalizează activitatea specifică aplicației permițând și verificând actualizarea programată a fluxurilor și accesul outbound la hosturile fluxurilor, aplicând adresa publică canonică și rulând această verificare de acceptanță: adaugă fluxuri, execută o actualizare programată, marchează un articol ca citit și sincronizează această stare prin API-ul mobil. Adaugă rezultatul restaurării în runbook înainte de sosirea utilizatorilor reali.

Întrebări frecvente

De ce are nevoie FreshRSS pentru o implementare în producție?

Direcționează containerul FreshRSS de pe portul 80 printr-o singură origine HTTPS. Cerința externă de livrare este actualizarea programată a fluxurilor și accesul outbound la hosturile fluxurilor. Nu considera FreshRSS pregătit până când nu poți adăuga fluxuri, executa o actualizare programată, marca un articol ca citit și sincroniza această stare prin API-ul mobil.

Ce date FreshRSS trebuie incluse într-un backup?

Păstrează /var/www/FreshRSS/data și include datele, extensiile și baza de date selectată în același manifest de recuperare. O restaurare FreshRSS curată este reușită doar atunci când abonamentele, categoriile, starea articolelor citite, filtrele și extensiile reapar, iar actualizarea programată preia un articol nou.

Are FreshRSS nevoie de HTTPS în spatele unui reverse proxy?

Folosește HTTPS pentru originea publică FreshRSS și păstrează portul 80 pe ruta internă. Aplică corect setarea FreshRSS: declară proxy-urile de încredere și baza HTTPS canonică. Pentru FreshRSS, HTTPS protejează credențialele sau conținutul utilizatorilor în tranzit și menține coerent comportamentul clientului dependent de origine.

Cum trebuie testat un upgrade FreshRSS?

Restaurează starea curentă FreshRSS într-o implementare izolată, aplică versiunea candidată și repetă tranzacția de acceptanță. Acordă o atenție deosebită acestui aspect, deoarece extensiile, migrările bazei de date și modificările parserului de fluxuri pot afecta actualizările chiar și atunci când autentificarea încă funcționează. Păstrează imaginea FreshRSS anterioară până când limitele migrării datelor și ale rollbackului sunt clare.