Jak hostować FreshRSS samodzielnie w 2026 roku: odświeżanie kanałów, API mobilne i backupy

Nieudane wdrożenie FreshRSS nie zawsze kończy się awarią. Aplikacja może wyświetlać stronę logowania, podczas gdy kanały nigdy się nie odświeżają, ponieważ cron jest wyłączony albo nie działa zewnętrzny DNS. Zamiast tego zacznij od testu end-to-end: dodaj kanały, uruchom zaplanowane odświeżanie, oznacz element jako przeczytany i zsynchronizuj ten stan przez API mobilne.

Ten test odpowiada katalogowemu przeznaczeniu FreshRSS: self-hostowanemu czytnikowi RSS ze zgodnym API mobilnym. Wcześniej ujawnia też brakujące zależności, błędne założenia dotyczące proxy oraz nietrwałe dane niż test uptime.

Zmapuj FreshRSS przed uruchomieniem Dockera

Rozdziel cztery obszary FreshRSS: ingress, listener na porcie 80, trwały stan oraz usługi pomocnicze lub lokalne zasoby. Zewnętrznym wymaganiem FreshRSS jest zaplanowane odświeżanie kanałów i dostęp wychodzący do hostów kanałów. Przetestuj zewnętrzny DNS, TLS i zachowanie dostawcy bez publikowania kolejnej usługi przychodzącej.

Wykonaj sprawdzoną transakcję — dodaj kanały, uruchom zaplanowane odświeżanie, oznacz element jako przeczytany i zsynchronizuj ten stan przez API mobilne — zanim uznasz ten podział za kompletny. Zmierz liczbę kanałów, interwał odświeżania, wolno odpowiadających wydawców, operacje zapisu do bazy danych i liczbę równoczesnych klientów API, a następnie zachowaj wynik wraz z rekordem wdrożenia. Zapewni to zarówno kryterium akceptacji, jak i pierwszą bazową miarę wydajności.

Wykonaj backup stanu, którego FreshRSS nie odtworzy samodzielnie

Przygotuj manifest odtwarzania FreshRSS obejmujący dane, rozszerzenia i wybraną bazę danych. Zamontuj /var/www/FreshRSS/data przed bootstrapem, zapisz nieszkodliwe przykładowe dane i wymień kontener, aby potwierdzić, że ta ścieżka jest rzeczywiście trwała. Już teraz sprawdź właściciela i wolne miejsce, ponieważ zamontowana ścieżka bez praw zapisu działa tak, jakby trwałości danych w ogóle nie było.

Wykonuj backup do failure domain oddzielnego od działającego serwera. Odtwórz FreshRSS z przypiętego obrazu i sprawdź, czy wracają subskrypcje, kategorie, stan przeczytania, filtry i rozszerzenia oraz czy zaplanowane odświeżanie pobiera nowy element. Przewodnik po persistent volumes pomoże przełożyć to ćwiczenie na zasady snapshotów i retencji.

Wybierz granicę zaufania FreshRSS

Przeprowadź threat modeling działania wykonywanego przez FreshRSS, a nie tylko jego formularza logowania. W tym przypadku największym ryzykiem jest pozostawienie początkowej konfiguracji lub domyślnego użytkownika dostępnego na publicznym hoście. Ustal następującą granicę: dokończ konfigurację prywatnie, chroń hasła API i skonfiguruj trusted proxies przed włączeniem synchronizacji mobilnej.

CRON_MIN steruje zachowaniem, a nie poufnością; sprawdź jego typ i wartość, a prawdziwe dane uwierzytelniające FreshRSS przechowuj osobno. Nie rozwiązuj problemu z uprawnieniami, uruchamiając kontener jako root ani montując szeroko zasoby hosta. Limity zasobów również należą do projektu bezpieczeństwa, gdy użytkownicy mogą wpływać na liczbę kanałów, interwał odświeżania, wolno odpowiadających wydawców, operacje zapisu do bazy danych i liczbę równoczesnych klientów API.

Co musi przejść, zanim pojawią się prawdziwe dane FreshRSS

Przekształć smoke test FreshRSS w powtarzalne polecenie release albo krótką runbook. Jego wynik musi potwierdzać następujący rezultat: dodanie kanałów, uruchomienie zaplanowanego odświeżania, oznaczenie elementu jako przeczytanego i zsynchronizowanie tego stanu przez API mobilne. Zapisz wraz z wynikiem wersję aplikacji, digest kontenera, hostname trasy i identyfikator danych testowych.

Uruchom ten sam test po rutynowej wymianie kontenera oraz po odtworzeniu danych, rozszerzeń i wybranej bazy danych w innym miejscu. Odtwarzanie zakończyło się powodzeniem, gdy wracają subskrypcje, kategorie, stan przeczytania, filtry i rozszerzenia, a zaplanowane odświeżanie pobiera nowy element. Porównaj czasy i zużycie związane z liczbą kanałów, interwałem odświeżania, wolno odpowiadającymi wydawcami, operacjami zapisu do bazy danych i liczbą równoczesnych klientów API; duża zmiana zasługuje na zbadanie, nawet jeśli końcowa akcja nadal się powiedzie.

Następnie wykonaj bezpieczny test awarii: tymczasowo zablokuj ścieżkę testową używaną przez zaplanowane odświeżanie kanałów i dostęp wychodzący do hostów kanałów. Potwierdź, że FreshRSS sygnalizuje błąd i wraca do normalnego działania bez destrukcyjnych ręcznych zmian. Zachowaj tylko niezbędny, zanonimizowany fragment logu. Ten czteroczęściowy gate obejmuje uruchamianie, trwałość danych, odtwarzanie i obsługę awarii.

Bazowa konfiguracja Dockera dla FreshRSS

Uruchomienie zbliżone do produkcyjnego jest celowo proste: nazwany stan, jawnie określony port i brak sekretów w obrazie.

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

Przykład stanowi punkt wyjścia, a nie kompletny stack usług pomocniczych. Zezwól na wymaganą ścieżkę wychodzącą lub po stronie klienta i zweryfikuj ją dla zaplanowanego odświeżania kanałów oraz dostępu wychodzącego do hostów kanałów. Sprawdź aktywne mounty i listener, a następnie spróbuj dodać kanały, uruchomić zaplanowane odświeżanie, oznaczyć element jako przeczytany i zsynchronizować ten stan przez API mobilne. Przypnij działający obraz przed kolejnym restartem.

Nie pozwól, aby poprawne działanie proxy maskowało awarię aplikacji

Przeglądarka, klient API i FreshRSS muszą korzystać z jednego originu. Aby tak było, zadeklaruj trusted proxies i kanoniczny adres bazowy HTTPS. Zachowaj oryginalny host i protokół, jednocześnie pozostawiając port 80 niedostępny jako konkurencyjny publiczny adres.

Przewodnik po diagnozowaniu niedostępnej witryny pomaga odróżnić niedostępną trasę od odpowiadającej aplikacji. To rozróżnienie ma tutaj znaczenie: kanały nigdy się nie odświeżają, ponieważ cron jest wyłączony albo nie działa zewnętrzny DNS. Tylko pierwszy problem można naprawić zmianami w ingressie; drugi wymaga sprawdzenia logów FreshRSS, stanu lub obciążenia.

Obserwuj obciążenie, a nie tylko kontener

Obserwuj pracę wykonywaną przez FreshRSS: liczbę kanałów, interwał odświeżania, wolno odpowiadających wydawców, operacje zapisu do bazy danych i liczbę równoczesnych klientów API. Ustal limity z zapasem odpowiednim do tego obciążenia i unikaj liveness probe, który konkuruje z właściwą pracą. Kontrola operatorska nadal powinna cyklicznie próbować dodać kanały, uruchomić zaplanowane odświeżanie, oznaczyć element jako przeczytany i zsynchronizować ten stan przez API mobilne.

Przy aktualizacjach pamiętaj, że rozszerzenia, migracje bazy danych i zmiany parsera kanałów mogą wpływać na odświeżanie, nawet gdy logowanie nadal działa. Wdróż wersję kandydującą na odtworzonej kopii i powtórz znany test. Jeśli kanały nigdy się nie odświeżają, ponieważ cron jest wyłączony albo nie działa zewnętrzny DNS, użyj logów runtime i rzeczywistego żądania sieciowego, aby ustalić, które założenie uległo zmianie.

Przenieś powtarzalne zadania infrastrukturalne do Dockup

Jednoklikowe wdrożenie FreshRSS w Dockup powinno zapewniać bezpieczną wymianę: trasa nadal kieruje na port 80, sekrety nie są wbudowane w obraz, a trwałe ścieżki wracają w nowym kontenerze. To samo wdrożenie może działać na infrastrukturze obliczeniowej Dockup lub na podłączonej maszynie.

Dokończ zadania właściwe dla aplikacji, zezwalając na zaplanowane odświeżanie kanałów i dostęp wychodzący do hostów kanałów oraz weryfikując te ścieżki, ustawiając kanoniczny publiczny adres i uruchamiając ten test akceptacyjny: dodaj kanały, uruchom zaplanowane odświeżanie, oznacz element jako przeczytany i zsynchronizuj ten stan przez API mobilne. Dodaj wynik odtwarzania do runbooka, zanim pojawią się prawdziwi użytkownicy.

Najczęściej zadawane pytania

Czego FreshRSS potrzebuje do wdrożenia produkcyjnego?

Skieruj kontener FreshRSS na port 80 przez jeden origin HTTPS. Zewnętrznym wymaganiem dostarczania jest zaplanowane odświeżanie kanałów i dostęp wychodzący do hostów kanałów. Nie uznawaj FreshRSS za gotowy, dopóki nie możesz dodać kanałów, uruchomić zaplanowanego odświeżania, oznaczyć elementu jako przeczytanego i zsynchronizować tego stanu przez API mobilne.

Które dane FreshRSS powinny znaleźć się w backupie?

Utrwal /var/www/FreshRSS/data i uwzględnij dane, rozszerzenia oraz wybraną bazę danych w tym samym manifeście odtwarzania. Czyste odtworzenie FreshRSS kończy się powodzeniem tylko wtedy, gdy wracają subskrypcje, kategorie, stan przeczytania, filtry i rozszerzenia, a zaplanowane odświeżanie pobiera nowy element.

Czy FreshRSS wymaga HTTPS za reverse proxy?

Używaj HTTPS dla publicznego originu FreshRSS, a port 80 pozostaw na trasie wewnętrznej. Zastosuj poprawnie ustawienie FreshRSS: zadeklaruj trusted proxies i kanoniczny adres bazowy HTTPS. W przypadku FreshRSS HTTPS chroni dane uwierzytelniające lub treści użytkowników podczas transmisji i zapewnia spójne zachowanie klienta zależne od originu.

Jak testować aktualizację FreshRSS?

Odtwórz bieżący stan FreshRSS w odizolowanym wdrożeniu, zastosuj wersję kandydującą i powtórz transakcję akceptacyjną. Zwróć szczególną uwagę na rozszerzenia, migracje bazy danych i zmiany parsera kanałów, ponieważ mogą wpływać na odświeżanie, nawet gdy logowanie nadal działa. Zachowaj poprzedni obraz FreshRSS do czasu zrozumienia granic migracji danych i rollbacku.