Как разместить FreshRSS на собственном сервере в 2026 году: обновление лент, Mobile API и резервные копии
Практическое руководство по самостоятельному размещению FreshRSS: Docker, порты, постоянное хранение данных, TLS, безопасность, резервное копирование и проблемы, которые мешают использовать сервис в production. С проверками.
Неудачное развертывание FreshRSS не всегда приводит к падению сервиса. Сервис может показывать страницу входа, но ленты при этом не обновляются из-за отключенного cron или ошибок исходящего DNS. Вместо этого начните с комплексной проверки: добавьте ленты, запустите обновление по расписанию, отметьте запись прочитанной и синхронизируйте это состояние через Mobile API.
Такая проверка соответствует заявленному назначению FreshRSS: self-hosted RSS reader с совместимым Mobile API. Она также раньше, чем проверка доступности, выявляет отсутствующие зависимости, неправильные предположения о proxy и эфемерные данные.
Изучите устройство FreshRSS до работы с Docker
Разделите FreshRSS на четыре зоны ответственности: ingress, listener на порту 80, постоянное состояние и вспомогательные сервисы или локальные ресурсы. Внешние требования FreshRSS — обновление лент по расписанию и исходящий доступ к хостам лент. Проверьте исходящий DNS, TLS и поведение провайдера, не публикуя еще один входящий сервис.
Выполните заведомо рабочую транзакцию — добавьте ленты, запустите обновление по расписанию, отметьте запись прочитанной и синхронизируйте это состояние через Mobile API, — прежде чем считать разделение завершенным. Измерьте количество лент, интервал обновления, медленных издателей, записи в базу данных и число одновременных API-клиентов и сохраните результат вместе с записью о развертывании. Это даст одновременно критерий приемки и первую базовую оценку емкости.
Резервируйте состояние, которое FreshRSS не может восстановить самостоятельно
Подготовьте recovery manifest для FreshRSS: данные, extensions и выбранную базу данных. Подключите /var/www/FreshRSS/data до bootstrap, запишите безопасные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняет данные. Проверьте владельца и свободное место сейчас, поскольку подключенный, но недоступный для записи путь фактически означает отсутствие persistence.
Храните резервные копии в failure domain, отдельном от работающего сервера. Восстановите FreshRSS из закрепленного image и убедитесь, что subscriptions, категории, состояние прочтения, filters и extensions вернулись, а обновление по расписанию получило новую запись. Руководство по persistent volumes поможет перенести эту процедуру в политику snapshot и хранения.
Определите границу доверия FreshRSS
Моделируйте угрозы для действий, которые выполняет FreshRSS, а не только для его формы входа. В данном случае самая опасная ошибка — оставить первоначальную настройку или пользователя по умолчанию доступными на публичном хосте. Реализуйте следующую границу: завершите настройку в закрытой среде, защитите API-пароли и настройте trusted proxies до включения мобильной синхронизации.
CRON_MIN управляет поведением, а не конфиденциальностью; проверьте его тип и значение, а настоящие учетные данные FreshRSS храните отдельно. Не устраняйте ошибку прав, запуская контейнер от root или широко монтируя файловую систему хоста. Resource limits также относятся к проектированию безопасности, если пользователи могут влиять на количество лент, интервал обновления, медленных издателей, записи в базу данных и число одновременных API-клиентов.
Что должно пройти до появления настоящих данных FreshRSS
Превратите smoke test FreshRSS в повторяемую release-команду или короткий runbook. Ее результат должен подтверждать следующее: добавьте ленты, запустите обновление по расписанию, отметьте запись прочитанной и синхронизируйте это состояние через Mobile API. Сохраните вместе с результатом версию приложения, container digest, hostname маршрута и идентификатор тестовых данных.
Выполняйте ту же проверку после обычной замены контейнера и после восстановления данных, extensions и выбранной базы данных в другом месте. Восстановление прошло успешно, если subscriptions, категории, состояние прочтения, filters и extensions вернулись, а обновление по расписанию получило новую запись. Сравнивайте время выполнения и потребление ресурсов с учетом количества лент, интервала обновления, медленных издателей, записей в базу данных и числа одновременных API-клиентов; существенное изменение требует проверки, даже если итоговая операция по-прежнему проходит.
Затем выполните безопасную проверку отказа: временно запретите тестовый путь, используемый для обновления лент по расписанию, и исходящий доступ к хостам лент. Убедитесь, что FreshRSS отображает ошибку и возвращается к нормальной работе без разрушительных ручных изменений. Сохраните только необходимый, очищенный от чувствительных данных фрагмент лога. Эти четыре проверки охватывают запуск, persistence, восстановление и обработку отказов.
Базовая конфигурация FreshRSS в Docker
Запуск, ориентированный на 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
Этот пример — базовая конфигурация, а не полный supporting stack. Разрешите и проверьте исходящий или клиентский путь, необходимый для обновления лент по расписанию и исходящего доступа к хостам лент. Проверьте фактически подключенные volumes и listener, затем попробуйте добавить ленты, запустить обновление по расписанию, отметить запись прочитанной и синхронизировать это состояние через Mobile API. До следующего перезапуска закрепите рабочий image.
Не позволяйте успешной работе proxy скрывать сбой приложения
Браузер, API-клиент и FreshRSS должны использовать один origin. Чтобы обеспечить это, объявите trusted proxies и канонический HTTPS base. Сохраняйте исходные host и protocol, одновременно оставляя порт 80 недоступным как конкурирующий публичный адрес.
Руководство по устранению проблем с недоступным сайтом помогает отличить недоступный маршрут от отвечающего приложения. Это различие здесь важно: ленты не обновляются из-за отключенного cron или ошибки исходящего DNS. Изменения ingress исправляют только первую проблему; для второй нужны логи FreshRSS, проверка состояния или анализ нагрузки.
Наблюдайте за нагрузкой, а не только за контейнером
Наблюдайте за работой FreshRSS: количеством лент, интервалом обновления, медленными издателями, записями в базу данных и числом одновременных API-клиентов. Задавайте limits с запасом под эту нагрузку и не используйте liveness probe, конкурирующий с ней. Проверка оператора по-прежнему должна по расписанию пытаться добавить ленты, запустить обновление, отметить запись прочитанной и синхронизировать это состояние через Mobile API.
При обновлении помните, что extensions, миграции базы данных и изменения feed parser могут повлиять на обновление лент, даже если вход по-прежнему работает. Разверните candidate-версию на восстановленной копии и повторите известный тест. Если ленты не обновляются из-за отключенного cron или ошибки исходящего DNS, используйте runtime logs и фактический сетевой запрос, чтобы выяснить, какое предположение изменилось.
Перенесите повторяемую инфраструктурную работу в Dockup
Однокликовое развертывание FreshRSS в Dockup должно сделать замену безопасной: маршрут продолжает указывать на 80, секреты не встраиваются в image, а persistent paths возвращаются в новом контейнере. То же развертывание можно запускать на вычислительных ресурсах Dockup или на подключенной машине.
Завершите работу, специфичную для приложения: разрешите и проверьте обновление лент по расписанию и исходящий доступ к хостам лент, задайте канонический публичный адрес и выполните эту проверку приемки: добавьте ленты, запустите обновление по расписанию, отметьте запись прочитанной и синхронизируйте это состояние через Mobile API. До появления реальных пользователей добавьте результат восстановления в runbook.
Часто задаваемые вопросы
Что нужно FreshRSS для production-развертывания?
Направьте контейнер FreshRSS на порту 80 через один HTTPS origin. Внешние требования к доставке — обновление лент по расписанию и исходящий доступ к хостам лент. Не объявляйте FreshRSS готовым, пока не сможете добавить ленты, запустить обновление по расписанию, отметить запись прочитанной и синхронизировать это состояние через Mobile API.
Какие данные FreshRSS нужно включать в резервную копию?
Сохраняйте /var/www/FreshRSS/data и включайте данные, extensions и выбранную базу данных в один recovery manifest. Чистое восстановление FreshRSS считается успешным только после того, как subscriptions, категории, состояние прочтения, filters и extensions вернулись, а обновление по расписанию получило новую запись.
Требуется ли FreshRSS HTTPS за reverse proxy?
Используйте HTTPS для публичного origin FreshRSS и оставьте порт 80 во внутреннем маршруте. Корректно примените настройку FreshRSS: объявите trusted proxies и канонический HTTPS base. Для FreshRSS HTTPS защищает учетные данные или пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.
Как тестировать обновление FreshRSS?
Восстановите текущее состояние FreshRSS в изолированном развертывании, примените candidate-версию и повторите транзакцию приемки. Уделите этому особое внимание, поскольку extensions, миграции базы данных и изменения feed parser могут повлиять на обновление лент, даже если вход по-прежнему работает. Сохраняйте предыдущий image FreshRSS, пока не будут понятны границы миграции данных и rollback.