Slik drifter du FreshRSS selv i 2026: Oppdatering av feeder, mobil-API og sikkerhetskopier
En praktisk guide til selvhosting av FreshRSS med Docker, porter, persistent data, TLS, sikkerhet, sikkerhetskopier og feilene som hindrer produksjonsbruk. Inkluderer kontroller.
En mislykket FreshRSS-distribusjon krasjer ikke alltid. Den kan vise en innloggingsside mens feeder aldri oppdateres fordi cron er deaktivert eller utgående DNS feiler. Start heller med en ende-til-ende-kontroll: Legg til feeder, kjør en planlagt oppdatering, marker et element som lest og synkroniser denne statusen via mobil-API-et.
Denne kontrollen samsvarer med det registrerte bruksområdet til FreshRSS: en RSS-leser du drifter selv, med et kompatibelt mobil-API. Den avdekker også manglende avhengigheter, feil antakelser om proxyen og flyktige data tidligere enn en enkel oppetidstest kan.
Kartlegg FreshRSS før du tar i bruk Docker
Skill mellom fire områder i FreshRSS: inngående trafikk, lytteren på port 80, varig tilstand og støttetjenester eller lokal kapasitet. Det eksterne kravet for FreshRSS er planlagt oppdatering av feeder og utgående tilgang til feed-verter. Test utgående DNS, TLS og leverandørens virkemåte uten å publisere enda en inngående tjeneste.
Kjør den kjente transaksjonen — legg til feeder, kjør en planlagt oppdatering, marker et element som lest og synkroniser denne statusen via mobil-API-et — før du anser denne separasjonen som fullført. Mål antall feeder, oppdateringsintervall, trege utgivere, databaseskrivinger og samtidige API-klienter, og lagre resultatet sammen med distribusjonsinformasjonen. Det gir både et akseptansekriterium og det første kapasitetsgrunnlaget.
Sikkerhetskopier tilstanden FreshRSS ikke kan gjenskape
Lag et gjenopprettingsmanifest for FreshRSS med data, utvidelser og den valgte databasen. Monter /var/www/FreshRSS/data før oppstart, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Kontroller eierskap og ledig plass nå, fordi en montert, men ikke skrivbar bane i praksis oppfører seg som om det ikke finnes persistent lagring.
Sikkerhetskopier til et separat feildomene, adskilt fra serveren som kjører. Gjenopprett FreshRSS fra det låste imaget og bekreft at abonnementer, kategorier, lest-status, filtre og utvidelser kommer tilbake, og at en planlagt oppdatering henter et nytt element. Guiden for persistent volumes hjelper deg med å omsette denne øvelsen til en policy for snapshots og oppbevaring.
Velg tillitsgrensen for FreshRSS
Lag en trusselmodell for handlingene FreshRSS utfører, ikke bare for innloggingsskjemaet. Den største risikoen her er å la det første oppsettet eller standardbrukeren være tilgjengelig på en offentlig vert. Implementer denne grensen: Fullfør oppsettet privat, beskytt API-passordene og konfigurer betrodde proxyer før du aktiverer mobilsynkronisering.
CRON_MIN styrer virkemåten, ikke konfidensialiteten. Valider typen og verdien, og lagre ekte FreshRSS-legitimasjon separat. Ikke løs et tillatelsesproblem ved å kjøre containeren som root eller montere vertens filsystem bredt. Ressursbegrensninger hører også hjemme i sikkerhetsdesignet når antall feeder, oppdateringsintervall, trege utgivere, databaseskrivinger og samtidige API-klienter kan utløses av brukere.
Dette må være godkjent før ekte FreshRSS-data kommer inn
Gjør FreshRSS-røyktesten om til en repeterbar release-kommando eller en kort runbook. Resultatet må vise dette utfallet: Legg til feeder, kjør en planlagt oppdatering, marker et element som lest og synkroniser denne statusen via mobil-API-et. Registrer applikasjonsversjon, container-digest, rutevertsnavn og identifikator for testdata sammen med resultatet.
Kjør den samme kontrollen etter et planlagt containerskifte og etter at data, utvidelser og den valgte databasen er gjenopprettet et annet sted. Gjenopprettingen er vellykket når abonnementer, kategorier, lest-status, filtre og utvidelser kommer tilbake, og en planlagt oppdatering henter et nytt element. Sammenlign tidsbruk og forbruk knyttet til antall feeder, oppdateringsintervall, trege utgivere, databaseskrivinger og samtidige API-klienter. En stor endring bør undersøkes selv når den siste handlingen fortsatt lykkes.
Test deretter en trygg feil: Blokker midlertidig testbanen som brukes av planlagt feed-oppdatering og utgående tilgang til feed-verter. Bekreft at FreshRSS synliggjør feilen og går tilbake til normal drift uten destruktive manuelle endringer. Bevar bare det nødvendige, redigerte utdraget fra loggen. Denne kontrollen i fire deler dekker oppstart, persistent lagring, gjenoppretting og feilhåndtering.
Et Docker-grunnlag for FreshRSS
En produksjonslignende oppstart er bevisst kjedelig: navngitt tilstand, eksplisitt port og ingen hemmeligheter 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
Eksempelet er et grunnlag, ikke en komplett støttestack. Tillat og verifiser den utgående banen eller klientbanen som kreves for planlagt feed-oppdatering og utgående tilgang til feed-verter. Kontroller de aktive mountene og lytteren, og prøv deretter å legge til feeder, kjøre en planlagt oppdatering, markere et element som lest og synkronisere denne statusen via mobil-API-et. Lås det fungerende imaget før neste omstart.
Hindre at en vellykket proxy skjuler applikasjonsfeil
Nettleseren, API-klienten og FreshRSS må være enige om én origin. For å sikre dette må du deklarere betrodde proxyer og den kanoniske HTTPS-basisen. Bevar den opprinnelige verten og protokollen, samtidig som port 80 ikke er tilgjengelig som en konkurrerende offentlig adresse.
Guiden for feilsøking av utilgjengelige nettsteder hjelper deg med å skille en utilgjengelig rute fra en applikasjon som svarer. Dette skillet er viktig her: Feeder oppdateres aldri fordi cron er deaktivert eller utgående DNS feiler. Bare det første løses med endringer i inngående trafikk; det siste krever inspeksjon av FreshRSS-logger, tilstand eller arbeidsbelastning.
Følg med på arbeidsbelastningen, ikke bare containeren
Følg med på arbeidet FreshRSS utfører: antall feeder, oppdateringsintervall, trege utgivere, databaseskrivinger og samtidige API-klienter. Sett grenser med tilstrekkelig margin for dette arbeidet, og unngå en liveness-probe som konkurrerer med det. Operatørkontrollen bør fortsatt forsøke å legge til feeder, kjøre en planlagt oppdatering, markere et element som lest og synkronisere denne statusen via mobil-API-et etter en fast plan.
Ved oppdateringer må du huske at utvidelser, databasemigreringer og endringer i feed-parseren kan påvirke oppdateringer selv om innloggingen fortsatt fungerer. Distribuer kandidaten mot en gjenopprettet kopi og gjenta den kjente testen. Hvis feeder aldri oppdateres fordi cron er deaktivert eller utgående DNS feiler, bruker du runtime-logger og den faktiske nettverksforespørselen til å finne ut hvilken antakelse som er endret.
Flytt det repeterbare infrastrukturarbeidet til Dockup
Dockups FreshRSS-distribusjon med ett klikk bør gjøre utskifting trygg: Ruten fortsetter å peke mot port 80, hemmeligheter bygges ikke inn i imaget, og persistente baner kommer tilbake i den nye containeren. Den samme distribusjonen kan kjøre på Dockup compute eller en tilkoblet maskin.
Fullfør det applikasjonsspesifikke arbeidet ved å tillate og verifisere planlagt feed-oppdatering og utgående tilgang til feed-verter, bruke den kanoniske offentlige adressen og kjøre denne akseptansetesten: Legg til feeder, kjør en planlagt oppdatering, marker et element som lest og synkroniser denne statusen via mobil-API-et. Legg resultatet av gjenopprettingen til i runbooken før ekte brukere tar løsningen i bruk.
Vanlige spørsmål
Hva trenger FreshRSS for en produksjonsdistribusjon?
Rout FreshRSS-containeren på port 80 gjennom én HTTPS-origin. Det eksterne leveringskravet er planlagt feed-oppdatering og utgående tilgang til feed-verter. Ikke erklær FreshRSS klar før du kan legge til feeder, kjøre en planlagt oppdatering, markere et element som lest og synkronisere denne statusen via mobil-API-et.
Hvilke FreshRSS-data skal inngå i en sikkerhetskopi?
Gjør /var/www/FreshRSS/data persistent, og inkluder data, utvidelser og den valgte databasen i det samme gjenopprettingsmanifestet. En ren FreshRSS-gjenoppretting er bare vellykket når abonnementer, kategorier, lest-status, filtre og utvidelser kommer tilbake, og en planlagt oppdatering henter et nytt element.
Krever FreshRSS HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige FreshRSS-origin-en, og behold port 80 på den interne ruten. Bruk FreshRSS-innstillingen riktig: Deklarer betrodde proxyer og den kanoniske HTTPS-basisen. For FreshRSS beskytter HTTPS legitimasjon eller brukerinnhold under overføring og sørger for at origin-avhengig klientvirkemåte er konsistent.
Hvordan bør en FreshRSS-oppgradering testes?
Gjenopprett gjeldende FreshRSS-tilstand i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom, fordi utvidelser, databasemigreringer og endringer i feed-parseren kan påvirke oppdateringer selv om innloggingen fortsatt fungerer. Behold det forrige FreshRSS-imaget til grensene for datamigrering og tilbakerulling er forstått.