FreshRSS или Miniflux: что выгоднее и когда

MAATRIX

Когда решаешь наконец уйти от Feedly или Inoreader на свой сервер, выбор быстро сужается до двух имён — FreshRSS и Miniflux. Оба open-source, оба бесплатны, оба поддерживают Google Reader API и Fever API для мобильных клиентов, и по скриншотам они даже похожи. Но под капотом это разные архитектурные философии, и от выбора зависит не только внешний вид, а сколько памяти съест сервер, что будет с расширениями через год и насколько больно будет мигрировать, если что-то не устроит.

Что это вообще такое

FreshRSS — PHP-приложение старой школы в хорошем смысле: классический веб-стек, который можно развернуть буквально на чём угодно, вплоть до общего хостинга с PHP и без root-доступа. Хранилище гибкое — SQLite прямо в файле, MySQL/MariaDB или PostgreSQL, на выбор при установке. Есть система расширений (extensions) на PHP — правила автотегирования, интеграции с read-later сервисами, кастомные фильтры контента, тёмные темы. Проект живёт с 2013 года как форк-переосмысление ныне заброшенного Tiny Tiny RSS, сообщество большое, документация на русском тоже встречается.

Miniflux — противоположный полюс: один статический бинарник на Go, минимум зависимостей, единственная поддерживаемая СУБД — PostgreSQL (SQLite и MySQL сознательно не поддерживаются, это решение авторов, а не недоработка). Нет системы расширений и тем — вместо этого встроенный движок правил (rewrite/block/keep по regex) и вебхуки. Интерфейс сознательно спартанский, заточен под клавиатурную навигацию (j/k/o как в Vim или Gmail) и на удивление быстро читается на телефоне через мобильный веб без отдельного приложения.

Разница примерно как между «швейцарским ножом с двадцатью лезвиями» и «одним очень острым лезвием» — оба режут, но обслуживание и ожидания разные.

Стек и требования к серверу

Ключевое отличие — что вообще нужно поднять на VPS, чтобы сервис заработал.

С SQLite FreshRSS разворачивается буквально одним контейнером — это самый простой вариант из двух, если не хочется поднимать отдельную базу. Готовый минимальный docker-compose.yml для этого случая разобран в статье FreshRSS в Docker Compose: готовый файл — там же вариант с вынесенным PostgreSQL для более серьёзной нагрузки.

Miniflux такой роскоши не оставляет — PostgreSQL обязателен с первого дня, даже для одного читателя с десятком лент. Это осознанный компромисс авторов: меньше кода для поддержки трёх типов СУБД, зато Postgres нужен всегда. Подробная установка на голый VPS есть в статье Как установить и настроить Miniflux на VPS.

По факту это значит: если на сервере уже крутится PostgreSQL под другие сервисы (тот же Immich, Vaultwarden или собственное приложение), Miniflux почти ничего не добавляет к инфраструктуре. Если PostgreSQL на сервере нет и заводить его ради одного RSS-ридера не хочется — FreshRSS с SQLite выигрывает по простоте однозначно.

Аппетит к ресурсам

Здесь важно разделять «сам процесс» и «связку целиком».

Процесс Miniflux в состоянии покоя занимает около 20–40 МБ — это статический Go-бинарник без интерпретатора и без разогрева JIT. Но реальная нижняя граница для всей связки — это память, которую забирает PostgreSQL: даже с настройками по умолчанию это ориентировочно 60–150 МБ, плюс место под ОС и запас на пиковое обновление всех лент разом. В сумме комфортный минимум — VPS с 512 МБ–1 ГБ RAM, подробный разбор с цифрами по сценариям — в статье Сколько RAM нужно для Miniflux.

FreshRSS с SQLite сравнивать напрямую сложнее — PHP-FPM + встроенный веб-сервер в контейнере плюс файловая база вместо отдельного процесса СУБД. По ощущениям от эксплуатации на младших тарифах, связка на SQLite укладывается в похожий диапазон 512 МБ–1 ГБ для личного использования, но точных официальных цифр разработчики FreshRSS не публикуют — это ориентир, а не гарантия, и зависит от числа лент и активности PHP-FPM воркеров. Если переходить на PostgreSQL для многопользовательского режима, аппетит выравнивается с Miniflux — разница между ними на этом уровне становится не принципиальной.

Практический вывод: на самом дешёвом VPS (256–512 МБ) FreshRSS с SQLite чувствует себя увереннее просто потому, что не тащит обязательный Postgres. На 1 ГБ и выше разница почти стирается.

Функциональность и интерфейс

FreshRSS выигрывает по гибкости представления: несколько встроенных тем, режим чтения с разной плотностью карточек, поддержка полнотекстового поиска (с MySQL/PostgreSQL — через встроенный полнотекстовый индекс, с SQLite — ограниченно), возможность подключить внешние правила скрапинга полного текста для лент, которые отдают только огрызок статьи. Расширения на PHP — это реальная экосистема: можно добавить автоматические теги по ключевым словам, интеграцию с Wallabag/Shaarli, кастомные CSS-темы.

Miniflux делает ставку на то, что называется «distraction-free»: минималистичный ридер без картинок-превью по умолчанию (можно включить), без тем оформления (одна светлая + одна тёмная, и всё), зато с очень сильным встроенным движком правил фильтрации — можно на уровне regex вырезать рекламные блоки, блокировать статьи по заголовку, переписывать URL перед сохранением. Из коробки есть интеграции с десятком read-later и заметочных сервисов (Wallabag, Shaarli, Instapaper, Pocket, Telegram-бот, Nunux Keeper и другие) — их настройка не требует поднимать отдельные расширения, всё уже вшито в бинарник.

Если задача — «читать быстро и без визуального шума, с сильной фильтрацией мусора» — это про Miniflux. Если хочется настраивать внешний вид под себя и наращивать функциональность расширениями — это про FreshRSS.

API и мобильные клиенты

Оба сервиса поддерживают Google Reader API и Fever API — это значит, что подключаются одни и те же мобильные и десктопные клиенты: Reeder, NetNewsWire, FeedMe, Fluent Reader и десятки других. С этой стороны разницы для пользователя фактически нет — приложение просто указывает на URL вашего сервера с логином и паролем (или API-ключом).

Разница в собственном API: у Miniflux есть чистый REST/JSON API с хорошей документацией, которым удобно пользоваться для автоматизации — например, забирать непрочитанные статьи скриптом и пересылать в Telegram или строить свой дашборд. У FreshRSS API менее выпячен наружу, хотя тоже доступен (через расширение API или Google Reader-совместимый эндпоинт) — для типовых сценариев с готовыми клиентами разницы нет, но для собственных интеграций Miniflux обычно удобнее.

Обслуживание и обновления

FreshRSS обновляется пересозданием контейнера с новым тегом образа — миграции схемы БД накатываются автоматически при первом запуске новой версии. Расширения на PHP иногда ломаются между мажорными версиями, если авторы расширений не успевают адаптировать код — для активно используемых расширений стоит проверять changelog перед апгрейдом.

Miniflux обновляется так же просто (новый тег образа miniflux/miniflux), миграции БД тоже применяются автоматически через переменную RUN_MIGRATIONS. Поскольку внешних расширений нет в принципе, риск «что-то отвалилось после апдейта» ниже — ломаться может либо сам Miniflux, либо совместимость с версией PostgreSQL, и то и другое разработчики тестируют заранее.

Если на сервере уже стоит обратный прокси с автоматическим SSL для других сервисов, оба контейнера встают за него без сюрпризов — базовая настройка разобрана в статье Caddy или Nginx: что выбрать для сервера.

Миграция между ними

Оба поддерживают OPML — стандартный формат экспорта/импорта списка подписок с RSS-читалок. Переход в любую сторону занимает пару минут: экспортируете OPML из одного сервиса, импортируете в другой, ленты подтягиваются со своими категориями (структура папок обычно сохраняется, хотя это стоит перепроверить после импорта — иногда вложенные категории сплющиваются в один уровень).

Что OPML не переносит — это историю прочитанного, сохранённые статьи и настроенные правила фильтрации. Если это критично, миграцию стоит планировать заранее и первое время держать оба сервиса параллельно, пока не убедитесь, что новый инстанс полностью устраивает.

Частые вопросы