FreshRSS zelf hosten in 2026: feedvernieuwing, mobiele API en back-ups

Een mislukte FreshRSS-deployment crasht niet altijd. De applicatie kan een loginpagina tonen terwijl feeds nooit worden vernieuwd, bijvoorbeeld omdat cron is uitgeschakeld of uitgaande DNS-verzoeken mislukken. Begin daarom met een end-to-end-controle: voeg feeds toe, voer een geplande vernieuwing uit, markeer een item als gelezen en synchroniseer die status via de mobiele API.

Die controle sluit aan bij het geregistreerde doel van FreshRSS: een zelfgehoste RSS-reader met een compatibele mobiele API. Bovendien komen ontbrekende dependencies, verkeerde aannames over de proxy en vluchtige data hiermee eerder aan het licht dan met een uptime-probe.

Breng FreshRSS in kaart voordat je Docker aanraakt

Scheid voor FreshRSS vier zaken: ingress, de listener op 80, duurzame state en ondersteunende services of lokale capaciteit. De externe vereiste voor FreshRSS is geplande feedvernieuwing en uitgaande toegang tot feedhosts. Test uitgaande DNS, TLS en het gedrag van providers zonder nog een inbound service te publiceren.

Voer de bekende geslaagde transactie uit — voeg feeds toe, voer een geplande vernieuwing uit, markeer een item als gelezen en synchroniseer die status via de mobiele API — voordat je deze scheiding als voltooid beschouwt. Meet het aantal feeds, het vernieuwingsinterval, trage publishers, databasewrites en gelijktijdige API-clients en bewaar het resultaat bij het deploymentrecord. Zo krijg je zowel een acceptatiecriterium als de eerste capaciteitsbaseline.

Maak een back-up van de state die FreshRSS niet kan reconstrueren

Maak een recoverymanifest voor FreshRSS met data, extensions en de geselecteerde database. Mount /var/www/FreshRSS/data vóór de bootstrap, schrijf onschadelijke voorbeelddata en vervang de container om te bewijzen dat dit pad daadwerkelijk persistent is. Controleer nu de eigenaars en de beschikbare schijfruimte, want een gemount maar niet-beschrijfbaar pad gedraagt zich alsof er helemaal geen persistence is.

Maak back-ups naar een failure domain dat losstaat van de actieve server. Recreate FreshRSS vanuit de gepinde image en controleer of subscriptions, categorieën, leesstatus, filters en extensions terugkeren en of de geplande vernieuwing een nieuw item ophaalt. De handleiding voor persistent volumes helpt om deze oefening te vertalen naar snapshot- en retentiebeleid.

Kies de trust boundary voor FreshRSS

Maak een threat model van de acties die FreshRSS uitvoert, niet alleen van het loginformulier. De grootste fout is hier dat de initiële setup of de standaardgebruiker toegankelijk blijft op een publiek beschikbare host. Implementeer deze grens: voltooi de setup privé, bescherm API-wachtwoorden en configureer trusted proxies voordat je mobiele synchronisatie inschakelt.

CRON_MIN bepaalt gedrag en geen vertrouwelijkheid; valideer het type en de waarde ervan en bewaar echte FreshRSS-inloggegevens afzonderlijk. Los een permissiefout niet op door de container als root te draaien of de host breed te mounten. Resource limits horen ook bij het beveiligingsontwerp wanneer gebruikers het aantal feeds, het vernieuwingsinterval, trage publishers, databasewrites en gelijktijdige API-clients kunnen beïnvloeden.

Wat moet slagen voordat echte FreshRSS-data arriveert

Zet de FreshRSS-smoketest om in een herhaalbaar releasecommando of een korte runbook. De uitvoer moet het volgende aantonen: voeg feeds toe, voer een geplande vernieuwing uit, markeer een item als gelezen en synchroniseer die status via de mobiele API. Leg de applicatieversie, containerdigest, route-hostname en identifier van de testdata samen met het resultaat vast.

Voer dezelfde controle uit na een standaardwissel van de container en na het elders herstellen van data, extensions en de geselecteerde database. De restore is geslaagd wanneer subscriptions, categorieën, leesstatus, filters en extensions terugkeren en de geplande vernieuwing een nieuw item ophaalt. Vergelijk de timing en het verbruik die samenhangen met het aantal feeds, het vernieuwingsinterval, trage publishers, databasewrites en gelijktijdige API-clients; een grote verandering verdient onderzoek, zelfs wanneer de eindactie nog steeds slaagt.

Test daarna een veilige fout: blokkeer tijdelijk het testpad dat wordt gebruikt voor geplande feedvernieuwing en uitgaande toegang tot feedhosts. Controleer of FreshRSS de fout zichtbaar maakt en zonder destructieve handmatige wijzigingen terugkeert naar de normale toestand. Bewaar alleen het noodzakelijke, geanonimiseerde logfragment. Deze vierdelige controle dekt startup, persistence, recovery en foutafhandeling.

Een Docker-baseline voor FreshRSS

Een productiegerichte start is bewust saai: benoemde state, een expliciete poort en geen secret in de image.

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

Het voorbeeld is een baseline en geen complete ondersteunende stack. Sta het outbound- of client-side pad toe dat nodig is voor geplande feedvernieuwing en uitgaande toegang tot feedhosts en controleer dit. Controleer de effectieve mounts en listener en probeer vervolgens feeds toe te voegen, een geplande vernieuwing uit te voeren, een item als gelezen te markeren en die status via de mobiele API te synchroniseren. Pin de werkende image vóór de volgende restart.

Voorkom dat proxy-succes applicatiefouten verbergt

De browser, API-client en FreshRSS moeten het eens zijn over één origin. Om dat te bereiken, declareer je trusted proxies en de canonieke HTTPS-basis-URL. Behoud de oorspronkelijke host en het oorspronkelijke protocol en houd poort 80 onbeschikbaar als concurrerend publiek adres.

De handleiding voor problemen met een onbereikbare site helpt onderscheid te maken tussen een onbereikbare route en een applicatie die wel antwoordt. Dat onderscheid is hier belangrijk: feeds worden nooit vernieuwd omdat cron is uitgeschakeld of uitgaande DNS-verzoeken mislukken. Alleen het eerste probleem los je op met wijzigingen aan ingress; voor het tweede heb je FreshRSS-logs, state- of workloadinspectie nodig.

Monitor de workload, niet alleen de container

Observeer het werk dat FreshRSS uitvoert: het aantal feeds, het vernieuwingsinterval, trage publishers, databasewrites en gelijktijdige API-clients. Stel limieten in met voldoende marge voor dit werk en vermijd een liveness-probe die ermee concurreert. De operatorcontrole moet nog steeds volgens een schema proberen feeds toe te voegen, een geplande vernieuwing uit te voeren, een item als gelezen te markeren en die status via de mobiele API te synchroniseren.

Houd er bij updates rekening mee dat extensions, databasemigraties en wijzigingen in de feed-parser invloed kunnen hebben op vernieuwingen, zelfs wanneer inloggen nog werkt. Deploy de kandidaatversie tegen een herstelde kopie en herhaal de bekende test. Als feeds nooit worden vernieuwd omdat cron is uitgeschakeld of uitgaande DNS-verzoeken mislukken, gebruik dan runtime-logs en het daadwerkelijke netwerkverzoek om te achterhalen welke aanname is veranderd.

Verplaats herhaalbaar infrastructuurwerk naar Dockup

De one-click FreshRSS-deployment van Dockup moet vervanging veilig maken: de route blijft naar 80 verwijzen, secrets worden niet in de image ingebakken en persistente paden keren terug in de nieuwe container. Dezelfde deployment kan op Dockup-compute of op een gekoppelde machine draaien.

Rond het applicatiespecifieke werk af door geplande feedvernieuwing en uitgaande toegang tot feedhosts toe te staan en te controleren, het canonieke publieke adres toe te passen en deze acceptatiecontrole uit te voeren: voeg feeds toe, voer een geplande vernieuwing uit, markeer een item als gelezen en synchroniseer die status via de mobiele API. Voeg het restore-resultaat aan de runbook toe voordat echte gebruikers arriveren.

Veelgestelde vragen

Wat heeft FreshRSS nodig voor een productie-deployment?

Routeer de FreshRSS-container op poort 80 via één HTTPS-origin. De externe leveringsvereiste is geplande feedvernieuwing en uitgaande toegang tot feedhosts. Beschouw FreshRSS pas als klaar wanneer je feeds kunt toevoegen, een geplande vernieuwing kunt uitvoeren, een item als gelezen kunt markeren en die status via de mobiele API kunt synchroniseren.

Welke FreshRSS-data hoort in een back-up?

Maak /var/www/FreshRSS/data persistent en neem data, extensions en de geselecteerde database op in hetzelfde recoverymanifest. Een schone FreshRSS-restore is pas geslaagd wanneer subscriptions, categorieën, leesstatus, filters en extensions terugkeren en de geplande vernieuwing een nieuw item ophaalt.

Heeft FreshRSS HTTPS nodig achter een reverse proxy?

Gebruik HTTPS voor de publieke FreshRSS-origin en houd poort 80 op de interne route. Pas de FreshRSS-instelling correct toe: declareer trusted proxies en de canonieke HTTPS-basis-URL. Voor FreshRSS beschermt HTTPS inloggegevens of gebruikerscontent tijdens transport en zorgt het voor consistent gedrag van clients die afhankelijk zijn van de origin.

Hoe moet een FreshRSS-upgrade worden getest?

Herstel de huidige FreshRSS-state in een geïsoleerde deployment, pas de kandidaatversie toe en herhaal de acceptatietransactie. Let hier extra op, omdat extensions, databasemigraties en wijzigingen in de feed-parser invloed kunnen hebben op vernieuwingen, zelfs wanneer inloggen nog werkt. Bewaar de vorige FreshRSS-image totdat de grenzen van datamigratie en rollback duidelijk zijn.