Как да хоствате FreshRSS самостоятелно през 2026 г.: обновяване на емисиите, Mobile API и резервни копия
Практическо ръководство за самостоятелно хостване на FreshRSS с Docker, портове, постоянни данни, TLS, сигурност, резервни копия и проблемите, които пречат на използването в production среда. С проверки.
Неуспешното внедряване на FreshRSS невинаги води до срив. Възможно е да се показва страница за вход, докато емисиите никога не се обновяват, защото cron е деактивиран или изходящият DNS не работи. Вместо това започнете с проверка от край до край: добавете емисии, стартирайте планирано обновяване, маркирайте елемент като прочетен и синхронизирайте това състояние чрез mobile API.
Тази проверка съответства на каталогизираната цел на FreshRSS: self-hosted RSS reader със съвместим mobile API. Тя също така разкрива липсващи зависимости, неправилни предположения за proxy конфигурацията и ефимерни данни по-рано, отколкото може да го направи uptime probe.
Картирайте FreshRSS, преди да докосвате Docker
Разделете четири аспекта на FreshRSS: ingress, listener-а на 80, постоянните данни и поддържащите услуги или локалния капацитет. Външното изискване за FreshRSS е планирано обновяване на емисиите и изходящ достъп до хостовете на емисиите. Тествайте изходящия DNS, TLS и поведението на provider-ите, без да публикувате друга inbound услуга.
Изпълнете познатата успешна транзакция — добавете емисии, стартирайте планирано обновяване, маркирайте елемент като прочетен и синхронизирайте това състояние чрез mobile API — преди да приемете, че разделянето е завършено. Измерете броя на емисиите, интервала на обновяване, бавните publisher-и, записите в базата данни и едновременните API clients и запазете резултата със записа за deployment-а. Така получавате както критерий за приемане, така и първоначална baseline стойност за капацитета.
Архивирайте състоянието, което FreshRSS не може да възстанови самостоятелно
Създайте recovery manifest за FreshRSS: данни, extensions и избраната база данни. Монтирайте /var/www/FreshRSS/data преди bootstrap, запишете безвредни примерни данни и заменете container-а, за да докажете, че този path действително е persistent. Проверете ownership-а и свободното пространство сега, защото монтиран path без права за запис се държи така, сякаш изобщо няма persistence.
Съхранявайте backup-ите във failure domain, отделен от работещия server. Възстановете FreshRSS от pinned image и проверете дали subscriptions, categories, read state, filters и extensions се връщат и дали планираното обновяване извлича нов елемент. Ръководството за persistent volumes помага да превърнете това упражнение в политика за snapshots и retention.
Изберете trust boundary за FreshRSS
Направете threat model на действието, което FreshRSS изпълнява, а не само на login формата му. Тук високорисковата грешка е началната настройка или default user да останат достъпни през публичен host. Реализирайте тази граница: завършете setup-а насаме, защитете API password-ите и конфигурирайте trusted proxies, преди да разрешите mobile synchronization.
CRON_MIN контролира поведението, а не поверителността; валидирайте неговия type и value и съхранявайте реалните FreshRSS credentials отделно. Не решавайте permission error, като стартирате container-а като root или монтирате host-а с прекалено широк достъп. Resource limits също са част от security design-а, когато броят на емисиите, интервалът на обновяване, бавните publisher-и, записите в базата данни и едновременните API clients могат да бъдат задействани от потребители.
Какво трябва да премине успешно, преди да пристигнат реални данни от FreshRSS
Превърнете smoke test-а на FreshRSS в повторяема release команда или кратък runbook. Резултатът му трябва да демонстрира следното: добавете емисии, стартирайте планирано обновяване, маркирайте елемент като прочетен и синхронизирайте това състояние чрез mobile API. Запишете application version-а, container digest-а, route hostname-а и identifier-а на тестовите данни заедно с резултата.
Изпълнете същата проверка след стандартна подмяна на container-а и след възстановяване на данните, extensions и избраната база данни на друго място. Възстановяването е успешно, когато subscriptions, categories, read state, filters и extensions се върнат и планираното обновяване извлече нов елемент. Сравнете timing-а и consumption-а, свързани с броя на емисиите, интервала на обновяване, бавните publisher-и, записите в базата данни и едновременните API clients; голяма промяна заслужава разследване, дори когато финалното действие все още преминава успешно.
След това упражнете безопасен failure сценарий: временно откажете достъпа до test path-а, използван за планираното обновяване на емисиите и изходящия достъп до хостовете на емисиите. Потвърдете, че FreshRSS показва проблема и се връща към нормална работа без разрушителни ръчни промени. Запазете само необходимия, редактиран откъс от log-а. Този gate от четири части обхваща стартирането, persistence-а, recovery-то и обработката на failure-и.
Docker baseline за FreshRSS
Launch-ът с форма, близка до production, умишлено е скучен: named state, изрично зададен port и без secret в 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
Примерът е baseline, а не завършен supporting stack. Разрешете и проверете outbound или client-side path-а, необходим за планираното обновяване на емисиите и изходящия достъп до хостовете на емисиите. Проверете effective mounts и listener-а, след което опитайте да добавите емисии, да стартирате планирано обновяване, да маркирате елемент като прочетен и да синхронизирате това състояние чрез mobile API. Pin-нете работещия image преди следващия restart.
Не позволявайте успехът на proxy-то да прикрива проблем в приложението
Browser-ът, API client-ът и FreshRSS трябва да са съгласувани за един origin. За да постигнете това, декларирайте trusted proxies и canonical HTTPS base. Запазете оригиналните host и protocol, като същевременно оставите port 80 недостъпен като конкуриращ публичен address.
Ръководството за отстраняване на проблеми със сайт, който не работи помага да разграничите недостъпен route от приложение, което отговаря. Това разграничение е важно тук: емисиите никога не се обновяват, защото cron е деактивиран или изходящият DNS не работи. Само първият проблем се отстранява с промени в ingress-а; вторият изисква проверка на FreshRSS logs, state или workload-а.
Наблюдавайте workload-а, а не само container-а
Наблюдавайте работата, която FreshRSS извършва: броя на емисиите, интервала на обновяване, бавните publisher-и, записите в базата данни и едновременните API clients. Задайте limits с headroom за тази работа и избягвайте liveness probe, която се конкурира с нея. Operator check-ът все пак трябва периодично да се опитва да добави емисии, да стартира планирано обновяване, да маркира елемент като прочетен и да синхронизира това състояние чрез mobile API.
При updates помнете, че extensions, database migrations и промените във feed parser-а могат да повлияят на refresh-ите, дори когато login-ът все още работи. Deploy-нете candidate-а срещу възстановено копие и повторете познатия test. Ако емисиите никога не се обновяват, защото cron е деактивиран или изходящият DNS не работи, използвайте runtime logs и реалната network request, за да откриете кое предположение се е променило.
Преместете повторяемата infrastructure работа в Dockup
One-click deployment-ът на FreshRSS в Dockup трябва да направи replacement-а безопасен: route-ът продължава да сочи към 80, secrets не са baked в image-а, а persistent paths се връщат в новия container. Същият deployment може да работи върху Dockup compute или върху attached machine.
Завършете специфичната за приложението работа, като разрешите и проверите планираното обновяване на емисиите и изходящия достъп до хостовете на емисиите, приложите canonical public address и изпълните тази acceptance check: добавете емисии, стартирайте планирано обновяване, маркирайте елемент като прочетен и синхронизирайте това състояние чрез mobile API. Добавете резултата от restore-а към runbook-а, преди да се появят реални потребители.
Често задавани въпроси
Какво е необходимо на FreshRSS за production deployment?
Насочете FreshRSS container-а през port 80 към един HTTPS origin. Външното изискване за delivery е планирано обновяване на емисиите и изходящ достъп до хостовете на емисиите. Не обявявайте FreshRSS за готов, докато не можете да добавите емисии, да стартирате планирано обновяване, да маркирате елемент като прочетен и да синхронизирате това състояние чрез mobile API.
Кои данни на FreshRSS трябва да бъдат включени в backup?
Направете /var/www/FreshRSS/data persistent и включете данните, extensions и избраната база данни в един и същ recovery manifest. Чистият restore на FreshRSS е успешен само когато subscriptions, categories, read state, filters и extensions се върнат и планираното обновяване извлече нов елемент.
Необходим ли е HTTPS за FreshRSS зад reverse proxy?
Използвайте HTTPS за публичния FreshRSS origin и оставете port 80 във вътрешния route. Приложете правилно настройката на FreshRSS: декларирайте trusted proxies и canonical HTTPS base. При FreshRSS HTTPS защитава credentials или user content при пренос и поддържа consistent поведение на client-а, чувствително към origin-а.
Как трябва да се тества upgrade на FreshRSS?
Възстановете текущия state на FreshRSS в изолиран deployment, приложете candidate version-а и повторете acceptance transaction-а. Обърнете специално внимание, защото extensions, database migrations и промените във feed parser-а могат да повлияят на refresh-ите, дори когато login-ът все още работи. Запазете предишния FreshRSS image, докато не изясните границите на data migration-а и rollback-а.