Sådan hoster du FreshRSS selv i 2026: Opdatering af feeds, mobil-API og sikkerhedskopier

En fejlslagen FreshRSS-deployment går ikke altid ned. Den kan godt vise en login-side, selvom feeds aldrig opdateres, fordi cron er deaktiveret, eller fordi outbound DNS fejler. Start i stedet med en end-to-end-kontrol: Tilføj feeds, kør en planlagt opdatering, markér et element som læst, og synkronisér denne status via mobil-API'et.

Denne kontrol stemmer overens med det katalogiserede formål med FreshRSS: en selvhostet RSS-læser med et kompatibelt mobil-API. Den afslører også manglende afhængigheder, forkerte antagelser om proxyen og ephemeral data tidligere, end en uptime-probe kan.

Kortlæg FreshRSS, før du rører ved Docker

Adskil fire områder i FreshRSS: ingress, lytteren på port 80, persistent state samt understøttende services eller lokal kapacitet. Det eksterne krav til FreshRSS er planlagte feed-opdateringer og outbound-adgang til feed-værter. Test outbound DNS, TLS og udbyderens adfærd uden at publicere endnu en inbound-service.

Kør den kendte, fungerende transaktion — tilføj feeds, kør en planlagt opdatering, markér et element som læst, og synkronisér denne status via mobil-API'et — før du betragter denne adskillelse som færdig. Mål antallet af feeds, opdateringsintervallet, langsomme udgivere, databasewrites og samtidige API-klienter, og gem resultatet sammen med deployment-recorden. Det giver både et acceptkriterium og den første kapacitetsbaseline.

Tag backup af den state, FreshRSS ikke kan genskabe

Lav et recovery-manifest for FreshRSS: data, extensions og den valgte database. Mount /var/www/FreshRSS/data før bootstrap, skriv harmløse testdata, og udskift containeren for at bevise, at stien faktisk er persistent. Kontrollér ejerskab og ledig plads nu, for en mountet, men skrivebeskyttet sti opfører sig som om der slet ikke var persistence.

Tag backup til et failure domain, der er adskilt fra den kørende server. Genskab FreshRSS fra det pinnede image, og kontrollér, at abonnementer, kategorier, læsestatus, filtre og extensions kommer tilbage, og at en planlagt opdatering henter et nyt element. Guiden til persistent volumes hjælper med at omsætte denne øvelse til en politik for snapshots og retention.

Vælg FreshRSS' trust boundary

Lav en threat model for den handling, FreshRSS udfører — ikke kun for loginformularen. Den største risiko her er at lade den indledende opsætning eller standardbrugeren være tilgængelig på en offentlig host. Implementér denne grænse: Gennemfør opsætningen privat, beskyt API-adgangskoder, og konfigurér trusted proxies, før du aktiverer mobilsynkronisering.

CRON_MIN styrer adfærd, ikke fortrolighed; validér dens type og værdi, og opbevar ægte FreshRSS-legitimationsoplysninger separat. Løs ikke en permission-fejl ved at køre containeren som root eller mounte hosten bredt. Resource limits hører også til i sikkerhedsdesignet, når brugere kan udløse antal feeds, opdateringsinterval, langsomme udgivere, databasewrites og samtidige API-klienter.

Det skal være godkendt, før rigtige FreshRSS-data ankommer

Gør FreshRSS' smoke test til en gentagelig release-kommando eller en kort runbook. Resultatet skal demonstrere dette: Tilføj feeds, kør en planlagt opdatering, markér et element som læst, og synkronisér denne status via mobil-API'et. Registrér applikationsversionen, container-digesten, route-hostnavnet og testdataenes identifier sammen med resultatet.

Kør den samme kontrol efter en almindelig udskiftning af containeren og efter gendannelse af data, extensions og den valgte database et andet sted. Gendannelsen er lykkedes, når abonnementer, kategorier, læsestatus, filtre og extensions kommer tilbage, og en planlagt opdatering henter et nyt element. Sammenlign tid og forbrug relateret til antal feeds, opdateringsinterval, langsomme udgivere, databasewrites og samtidige API-klienter; en stor ændring bør undersøges, selv når den afsluttende handling stadig består.

Udfør derefter en sikker fejlsituation: Afvis midlertidigt den teststi, der bruges af planlagte feed-opdateringer, samt outbound-adgangen til feed-værter. Bekræft, at FreshRSS viser fejlen og vender tilbage til normal drift uden destruktive manuelle ændringer. Gem kun det nødvendige, redigerede udsnit af loggen. Denne gate i fire dele dækker opstart, persistence, recovery og fejlhåndtering.

En Docker-baseline til FreshRSS

En produktionslignende lancering er med vilje kedelig: navngiven state, eksplicit port og ingen secrets i imaget.

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

Eksemplet er en baseline, ikke en komplet supporting stack. Tillad og verificér den outbound- eller klientsidesti, der kræves til planlagte feed-opdateringer og outbound-adgang til feed-værter. Kontrollér de effektive mounts og lytteren, og prøv derefter at tilføje feeds, køre en planlagt opdatering, markere et element som læst og synkronisere denne status via mobil-API'et. Pin det fungerende image før næste genstart.

Undgå, at proxy-succes skjuler applikationsfejl

Browseren, API-klienten og FreshRSS skal være enige om én origin. For at sikre det skal du deklarere trusted proxies og den kanoniske HTTPS-base. Bevar den oprindelige host og protokol, samtidig med at port 80 holdes utilgængelig som en konkurrerende offentlig adresse.

Guiden til fejlfinding af et site, der er nede hjælper med at skelne mellem en utilgængelig route og en applikation, der svarer. Denne forskel er vigtig her: Feeds opdateres aldrig, fordi cron er deaktiveret, eller fordi outbound DNS fejler. Kun den første situation løses med ingress-ændringer; den anden kræver inspektion af FreshRSS-logs, state eller workload.

Overvåg workloaden, ikke kun containeren

Overvåg det arbejde, FreshRSS udfører: antal feeds, opdateringsinterval, langsomme udgivere, databasewrites og samtidige API-klienter. Sæt limits med plads til dette arbejde, og undgå en liveness-probe, der konkurrerer med det. Operator-kontrollen skal stadig forsøge at tilføje feeds, køre en planlagt opdatering, markere et element som læst og synkronisere denne status via mobil-API'et efter en fast plan.

Ved opdateringer skal du huske, at extensions, databasemigreringer og ændringer i feed-parseren kan påvirke opdateringer, selv når login stadig fungerer. Deploy kandidaten mod en gendannet kopi, og gentag den kendte test. Hvis feeds aldrig opdateres, fordi cron er deaktiveret, eller fordi outbound DNS fejler, skal du bruge runtime-logs og den faktiske netværksforespørgsel til at finde ud af, hvilken antagelse der er ændret.

Flyt det gentagelige infrastrukturarbejde til Dockup

Dockups one-click-deployment af FreshRSS skal gøre udskiftning sikker: Routen fortsætter med at pege på port 80, secrets er ikke baked ind i imaget, og persistente stier kommer tilbage på den nye container. Den samme deployment kan køre på Dockup compute eller på en tilknyttet maskine.

Gennemfør det applikationsspecifikke arbejde ved at tillade og verificere planlagte feed-opdateringer og outbound-adgang til feed-værter, anvende den kanoniske offentlige adresse og køre denne acceptkontrol: Tilføj feeds, kør en planlagt opdatering, markér et element som læst, og synkronisér denne status via mobil-API'et. Tilføj resultatet af gendannelsen til runbooken, før de rigtige brugere ankommer.

Ofte stillede spørgsmål

Hvad kræver FreshRSS til en produktionsdeployment?

Route FreshRSS-containeren på port 80 gennem én HTTPS-origin. Det eksterne leveringskrav er planlagte feed-opdateringer og outbound-adgang til feed-værter. Kald ikke FreshRSS klar, før du kan tilføje feeds, køre en planlagt opdatering, markere et element som læst og synkronisere denne status via mobil-API'et.

Hvilke FreshRSS-data hører hjemme i en backup?

Persistér /var/www/FreshRSS/data, og inkludér data, extensions og den valgte database i det samme recovery-manifest. En ren FreshRSS-gendannelse er kun godkendt, når abonnementer, kategorier, læsestatus, filtre og extensions kommer tilbage, og en planlagt opdatering henter et nyt element.

Kræver FreshRSS HTTPS bag en reverse proxy?

Brug HTTPS til den offentlige FreshRSS-origin, og behold port 80 på den interne route. Anvend FreshRSS-indstillingen korrekt: Deklarér trusted proxies og den kanoniske HTTPS-base. For FreshRSS beskytter HTTPS legitimationsoplysninger eller brugerindhold under transport og sikrer ensartet origin-følsom klientadfærd.

Hvordan bør en FreshRSS-opgradering testes?

Gendan den aktuelle FreshRSS-state i en isoleret deployment, anvend kandidatversionen, og gentag dens accepttransaktion. Vær særligt opmærksom, fordi extensions, databasemigreringer og ændringer i feed-parseren kan påvirke opdateringer, selv når login stadig fungerer. Behold det tidligere FreshRSS-image, indtil grænsen for datamigrering og rollback er forstået.