Як розгорнути FreshRSS на власному сервері у 2026 році: оновлення стрічок, Mobile API та резервні копії
Практичний посібник із self-hosting FreshRSS: Docker, порти, постійні дані, TLS, безпека, резервні копії та проблеми, які перешкоджають використанню в production. Із перевірками.
Невдале розгортання FreshRSS не завжди завершується падінням. Сторінка входу може відкриватися, але стрічки не оновлюватимуться, якщо cron вимкнено або не працює вихідний DNS. Натомість одразу виконайте наскрізну перевірку: додайте стрічки, запустіть заплановане оновлення, позначте елемент як прочитаний і синхронізуйте цей стан через Mobile API.
Ця перевірка відповідає задекларованому призначенню FreshRSS: self-hosted RSS-рідер із сумісним Mobile API. Вона також раніше виявляє відсутні залежності, неправильні припущення щодо proxy та ефемерні дані, ніж це може зробити uptime probe.
Вивчіть структуру FreshRSS перед роботою з Docker
Розділіть чотири аспекти FreshRSS: ingress, listener на порту 80, постійний стан і допоміжні сервіси або локальні ресурси. Зовнішня вимога для FreshRSS — заплановане оновлення стрічок і вихідний доступ до хостів стрічок. Перевірте вихідний DNS, TLS і поведінку провайдера, не публікуючи ще один вхідний сервіс.
Виконайте перевірену транзакцію — додайте стрічки, запустіть заплановане оновлення, позначте елемент як прочитаний і синхронізуйте цей стан через Mobile API, — перш ніж вважати цей поділ завершеним. Виміряйте кількість стрічок, інтервал оновлення, повільних видавців, записи до бази даних і кількість одночасних API-клієнтів та збережіть результат разом із записом про розгортання. Це дає і критерій приймання, і перший базовий показник продуктивності.
Створіть резервну копію стану, який FreshRSS не може відновити самостійно
Підготуйте маніфест відновлення FreshRSS: дані, extensions і вибрану базу даних. Підключіть /var/www/FreshRSS/data до початкового запуску, запишіть нешкідливі тестові дані та замініть контейнер, щоб переконатися, що цей шлях справді зберігає дані. Перевірте права власника й вільне місце вже зараз, адже підключений, але недоступний для запису шлях практично нічим не відрізняється від повної відсутності persistence.
Зберігайте резервні копії в окремому домені відмови, а не на тому самому сервері, що працює. Відтворіть FreshRSS із зафіксованого image і перевірте, що підписки, категорії, стан прочитаності, фільтри та extensions повернулися, а заплановане оновлення отримує новий елемент. Посібник із persistent volumes допоможе перетворити цю перевірку на політику snapshot і retention.
Визначте межу довіри FreshRSS
Моделюйте загрози для дій, які виконує FreshRSS, а не лише для його форми входу. У цьому випадку найнебезпечніша помилка — залишити початкове налаштування або користувача за замовчуванням доступними на публічному хості. Реалізуйте таку межу: завершіть налаштування приватно, захистіть API-паролі та налаштуйте trusted proxies перед увімкненням мобільної синхронізації.
CRON_MIN керує поведінкою, а не конфіденційністю; перевірте його тип і значення та зберігайте справжні облікові дані FreshRSS окремо. Не усувайте помилку доступу, запускаючи контейнер від root або широко підключаючи host. Обмеження ресурсів також є частиною дизайну безпеки, якщо користувачі можуть впливати на кількість стрічок, інтервал оновлення, повільних видавців, записи до бази даних і кількість одночасних API-клієнтів.
Що має пройти до надходження реальних даних FreshRSS
Перетворіть smoke test FreshRSS на повторювану release-команду або короткий runbook. Результат має продемонструвати такий сценарій: додайте стрічки, запустіть заплановане оновлення, позначте елемент як прочитаний і синхронізуйте цей стан через Mobile API. Збережіть разом із результатом версію застосунку, digest контейнера, hostname маршруту та ідентифікатор тестових даних.
Виконуйте ту саму перевірку після звичайної заміни контейнера та після відновлення даних, extensions і вибраної бази даних в іншому місці. Відновлення успішне, якщо підписки, категорії, стан прочитаності, фільтри та extensions повернулися, а заплановане оновлення отримує новий елемент. Порівнюйте час виконання та споживання ресурсів залежно від кількості стрічок, інтервалу оновлення, повільних видавців, записів до бази даних і кількості одночасних API-клієнтів; значна зміна потребує перевірки, навіть якщо фінальна дія все ще проходить.
Потім виконайте безпечну перевірку відмови: тимчасово забороніть тестовий шлях, який використовується для запланованого оновлення стрічок і вихідного доступу до хостів стрічок. Переконайтеся, що FreshRSS показує помилку та повертається до нормальної роботи без деструктивних ручних змін. Збережіть лише необхідний, відредагований фрагмент журналу. Цей чотириетапний gate охоплює запуск, persistence, відновлення та обробку відмов.
Базова конфігурація Docker для FreshRSS
Запуск, наближений до production, навмисно залишається простим: іменований стан, явно заданий порт і жодних секретів усередині 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
Цей приклад є базовою конфігурацією, а не повним стеком допоміжних сервісів. Дозвольте та перевірте вихідний або клієнтський шлях, потрібний для запланованого оновлення стрічок і вихідного доступу до хостів стрічок. Перевірте фактично підключені volumes і listener, а потім спробуйте додати стрічки, запустити заплановане оновлення, позначити елемент як прочитаний і синхронізувати цей стан через Mobile API. Зафіксуйте робочий image до наступного перезапуску.
Не дозволяйте успішному proxy приховати помилку застосунку
Браузер, API-клієнт і FreshRSS мають узгоджено використовувати один origin. Щоб забезпечити це, оголосіть trusted proxies і canonical HTTPS base. Зберігайте оригінальні host і protocol, водночас не залишаючи порт 80 доступним як конкуруючу публічну адресу.
Посібник із діагностики недоступного сайту допомагає відрізнити недоступний маршрут від застосунку, який відповідає. У цьому випадку така відмінність важлива: стрічки не оновлюються, тому що cron вимкнено або не працює вихідний DNS. Зміни ingress виправляють лише першу проблему; друга потребує перевірки журналів FreshRSS, стану або навантаження.
Контролюйте навантаження, а не лише контейнер
Спостерігайте за роботою FreshRSS: кількістю стрічок, інтервалом оновлення, повільними видавцями, записами до бази даних і кількістю одночасних API-клієнтів. Встановлюйте ліміти із запасом для цього навантаження та не допускайте, щоб liveness probe конкурував із ним. Операторська перевірка все одно має за розкладом додавати стрічки, запускати заплановане оновлення, позначати елемент як прочитаний і синхронізувати цей стан через Mobile API.
Під час оновлень пам’ятайте, що extensions, міграції бази даних і зміни feed parser можуть впливати на оновлення, навіть якщо вхід усе ще працює. Розгорніть candidate-версію на відновленій копії та повторіть відомий тест. Якщо стрічки не оновлюються, тому що cron вимкнено або не працює вихідний DNS, використовуйте runtime logs і фактичний network request, щоб з’ясувати, яке припущення змінилося.
Перенесіть повторювану інфраструктурну роботу до Dockup
One-click розгортання FreshRSS у Dockup має робити заміну безпечною: маршрут і надалі спрямований на порт 80, секрети не вбудовані в image, а постійні шляхи повертаються в новому контейнері. Те саме розгортання може працювати на обчислювальних ресурсах Dockup або на підключеній машині.
Завершіть специфічну для застосунку роботу, дозволивши та перевіривши заплановане оновлення стрічок і вихідний доступ до хостів стрічок, застосувавши canonical public address і виконавши цю перевірку приймання: додайте стрічки, запустіть заплановане оновлення, позначте елемент як прочитаний і синхронізуйте цей стан через Mobile API. Додайте результат відновлення до runbook до появи реальних користувачів.
Поширені запитання
Що потрібно FreshRSS для розгортання в production?
Спрямуйте контейнер FreshRSS на порту 80 через один HTTPS origin. Зовнішня вимога для доставки даних — заплановане оновлення стрічок і вихідний доступ до хостів стрічок. Не вважайте FreshRSS готовим, доки не зможете додати стрічки, запустити заплановане оновлення, позначити елемент як прочитаний і синхронізувати цей стан через Mobile API.
Які дані FreshRSS потрібно включити до резервної копії?
Зберігайте /var/www/FreshRSS/data і включіть data, extensions та вибрану базу даних до одного маніфесту відновлення. Чисте відновлення FreshRSS успішне лише тоді, коли повертаються підписки, категорії, стан прочитаності, фільтри та extensions, а заплановане оновлення отримує новий елемент.
Чи потрібен FreshRSS HTTPS за reverse proxy?
Використовуйте HTTPS для публічного origin FreshRSS, а порт 80 залиште у внутрішньому маршруті. Правильно застосуйте налаштування FreshRSS: оголосіть trusted proxies і canonical HTTPS base. Для FreshRSS HTTPS захищає облікові дані або користувацький контент під час передавання та забезпечує узгоджену поведінку клієнта, чутливу до origin.
Як тестувати оновлення FreshRSS?
Відновіть поточний стан FreshRSS в ізольованому розгортанні, застосуйте candidate-версію та повторіть транзакцію приймання. Будьте особливо уважні, оскільки extensions, міграції бази даних і зміни feed parser можуть впливати на оновлення, навіть якщо вхід усе ще працює. Зберігайте попередній image FreshRSS, доки не буде зрозумілою межа міграції даних і rollback.