Så självhostar du FreshRSS 2026: feeduppdatering, mobil-API och säkerhetskopior

En misslyckad FreshRSS-installation kraschar inte alltid. Den kan visa en inloggningssida samtidigt som feeds aldrig uppdateras eftersom cron är inaktiverat eller utgående DNS misslyckas. Börja i stället med en kontroll från början till slut: lägg till feeds, kör en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t.

Den kontrollen motsvarar FreshRSS dokumenterade syfte: en självhostad RSS-läsare med kompatibelt mobil-API. Den avslöjar också saknade beroenden, felaktiga antaganden om proxyn och temporär data tidigare än vad en uptime-kontroll kan göra.

Kartlägg FreshRSS innan du rör Docker

Dela upp FreshRSS i fyra områden: inkommande trafik, lyssnaren på port 80, beständig state och stödjande tjänster eller lokal kapacitet. Det externa kravet för FreshRSS är schemalagd feeduppdatering och utgående åtkomst till feedvärdar. Testa utgående DNS, TLS och leverantörens beteende utan att publicera ytterligare en inkommande tjänst.

Kör den kända fungerande transaktionen — lägg till feeds, kör en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t — innan du anser att uppdelningen är klar. Mät antal feeds, uppdateringsintervall, långsamma publicister, databasskrivningar och samtidiga API-klienter och spara resultatet tillsammans med deployment-posten. Det ger både ett acceptanskriterium och den första kapacitetsbaslinjen.

Säkerhetskopiera det tillstånd FreshRSS inte kan återskapa

Skapa ett återställningsmanifest för FreshRSS: data, tillägg och den valda databasen. Montera /var/www/FreshRSS/data före bootstrap, skriv ofarliga exempeldata och ersätt containern för att bevisa att sökvägen faktiskt är persistent. Kontrollera ägarskap och ledigt utrymme nu, eftersom en monterad men skrivskyddad sökväg i praktiken inte ger någon persistence alls.

Säkerhetskopiera till en felzon som är separat från den körande servern. Återskapa FreshRSS från dess pinnade image och verifiera att prenumerationer, kategorier, lässtatus, filter och tillägg kommer tillbaka och att en schemalagd uppdatering hämtar ett nytt objekt. Guiden om persistent volumes hjälper dig att omsätta övningen i en policy för snapshots och retention.

Välj FreshRSS säkerhetsgräns

Gör en threat model av de åtgärder FreshRSS utför, inte bara av inloggningsformuläret. Det största riskfyllda misstaget här är att lämna den första installationen eller standardanvändaren åtkomlig på en publik värd. Implementera denna gräns: slutför installationen privat, skydda API-lösenord och konfigurera trusted proxies innan du aktiverar mobil synkronisering.

CRON_MIN styr beteende, inte konfidentialitet. Validera dess typ och värde och lagra riktiga FreshRSS-uppgifter separat. Lös inte ett behörighetsfel genom att köra containern som root eller montera värden brett. Resursbegränsningar hör också hemma i säkerhetsdesignen när antal feeds, uppdateringsintervall, långsamma publicister, databasskrivningar och samtidiga API-klienter kan utlösas av användare.

Det här måste fungera innan riktiga FreshRSS-data anländer

Gör om FreshRSS smoke test till ett repeterbart release-kommando eller en kort runbook. Resultatet måste visa följande: lägg till feeds, kör en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t. Registrera applikationsversion, container-digest, route hostname och identifierare för testdata tillsammans med resultatet.

Kör samma kontroll efter ett rutinmässigt containerbyte och efter att data, tillägg och den valda databasen har återställts någon annanstans. Återställningen har lyckats när prenumerationer, kategorier, lässtatus, filter och tillägg kommer tillbaka och en schemalagd uppdatering hämtar ett nytt objekt. Jämför tidsåtgång och förbrukning kopplad till antal feeds, uppdateringsintervall, långsamma publicister, databasskrivningar och samtidiga API-klienter. En stor förändring är värd att undersöka även när den slutliga åtgärden fortfarande lyckas.

Testa sedan ett säkert fel: neka tillfälligt testsökvägen som används för schemalagd feeduppdatering och utgående åtkomst till feedvärdar. Bekräfta att FreshRSS visar felet och återgår till normalt läge utan destruktiva manuella ändringar. Spara endast det nödvändiga, avidentifierade loggutdraget. Den här fyrdelade kontrollen täcker uppstart, persistence, återställning och felhantering.

En Docker-baslinje för FreshRSS

En produktionslik start är medvetet odramatisk: namngiven state, explicit port och inga hemligheter i imagen.

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

Exemplet är en baslinje, inte en komplett stödjande stack. Tillåt och verifiera den utgående eller klientsidiga sökväg som krävs för schemalagd feeduppdatering och utgående åtkomst till feedvärdar. Kontrollera de aktiva mountningarna och lyssnaren och försök sedan lägga till feeds, köra en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t. Pinna den fungerande imagen före nästa omstart.

Förhindra att en lyckad proxy döljer fel i applikationen

Webbläsaren, API-klienten och FreshRSS måste vara överens om samma origin. För att säkerställa det deklarerar du trusted proxies och den kanoniska HTTPS-basen. Bevara det ursprungliga värdnamnet och protokollet samtidigt som du håller port 80 otillgänglig som en konkurrerande publik adress.

Guiden för felsökning när webbplatsen ligger nere hjälper dig att skilja en oåtkomlig route från en applikation som svarar. Den skillnaden är viktig här: feeds uppdateras aldrig eftersom cron är inaktiverat eller utgående DNS misslyckas. Endast det förstnämnda löses genom ändringar i ingressen; det sistnämnda kräver granskning av FreshRSS-loggar, state eller workload.

Övervaka workloaden, inte bara containern

Observera det arbete FreshRSS utför: antal feeds, uppdateringsintervall, långsamma publicister, databasskrivningar och samtidiga API-klienter. Sätt gränser med marginal för det arbetet och undvik en liveness probe som konkurrerar om resurserna. Operatörskontrollen ska fortfarande regelbundet försöka lägga till feeds, köra en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t.

Vid uppdateringar bör du komma ihåg att tillägg, databasmigreringar och förändringar i feed-parsern kan påverka uppdateringar även när inloggningen fortfarande fungerar. Distribuera kandidaten mot en återställd kopia och upprepa det kända testet. Om feeds aldrig uppdateras eftersom cron är inaktiverat eller utgående DNS misslyckas använder du runtime-loggar och den faktiska nätverksbegäran för att hitta vilket antagande som har förändrats.

Flytta det repeterbara infrastrukturarbetet till Dockup

Dockups FreshRSS-deployment med ett klick bör göra det säkert att ersätta containern: routen fortsätter att rikta sig mot port 80, hemligheter byggs inte in i imagen och persistenta sökvägar kommer tillbaka i den nya containern. Samma deployment kan köras på Dockup compute eller en ansluten maskin.

Slutför det appspecifika arbetet genom att tillåta och verifiera schemalagd feeduppdatering och utgående åtkomst till feedvärdar, ange den kanoniska publika adressen och köra denna acceptanskontroll: lägg till feeds, kör en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t. Lägg till återställningsresultatet i runbooken innan riktiga användare ansluter.

Vanliga frågor

Vad behöver FreshRSS för en produktionsdeployment?

Routa FreshRSS-containern på port 80 via en enda HTTPS-origin. Det externa leveranskravet är schemalagd feeduppdatering och utgående åtkomst till feedvärdar. Förklara inte FreshRSS som redo förrän du kan lägga till feeds, köra en schemalagd uppdatering, markera ett objekt som läst och synkronisera det tillståndet via mobil-API:t.

Vilka FreshRSS-data ska ingå i en säkerhetskopia?

Gör /var/www/FreshRSS/data persistent och inkludera data, tillägg och den valda databasen i samma återställningsmanifest. En ren FreshRSS-återställning är godkänd först när prenumerationer, kategorier, lässtatus, filter och tillägg kommer tillbaka och en schemalagd uppdatering hämtar ett nytt objekt.

Kräver FreshRSS HTTPS bakom en reverse proxy?

Använd HTTPS för den publika FreshRSS-originen och behåll port 80 på den interna routen. Tillämpa FreshRSS-inställningen korrekt: deklarera trusted proxies och den kanoniska HTTPS-basen. För FreshRSS skyddar HTTPS uppgifter eller användarinnehåll under överföring och gör klientbeteendet som beror på origin konsekvent.

Hur bör en FreshRSS-uppgradering testas?

Återställ aktuell FreshRSS-state till en isolerad deployment, tillämpa kandidatversionen och upprepa dess acceptanstransaktion. Var särskilt uppmärksam eftersom tillägg, databasmigreringar och förändringar i feed-parsern kan påverka uppdateringar även när inloggningen fortfarande fungerar. Behåll den tidigare FreshRSS-imagen tills gränserna för datamigrering och rollback är klarlagda.