Tiny Tiny RSS в 2026 всё ещё удобнее новых читалок — вот чем именно

MAATRIX

Если вы искали self-hosted RSS-читалку в последние пару лет, вам почти наверняка советовали FreshRSS или Miniflux — они моложе, легче ставятся и выглядят современнее. Tiny Tiny RSS (TT-RSS) на их фоне смотрится как ветеран: интерфейс без ресайзов и анимаций, документация местами суховатая, а разработчик известен резкими комментариями в багтрекере. И всё же часть опытных self-hosters, попробовав альтернативы, возвращается именно к TT-RSS — потому что у него есть три вещи, которые новые читалки либо не реализовали вовсе, либо сделали заметно проще: система плагинов, движок фильтров с булевой логикой и полноценный API, вокруг которого выросла экосистема сторонних клиентов.

Что такое Tiny Tiny RSS и почему он не умер

TT-RSS — это PHP-приложение с базой данных, которое разворачивается на своём сервере и не имеет официальной облачной версии. Проект стартовал ещё в середине 2000-х и с тех пор живёт в собственном темпе: без венчурных денег, без редизайнов ради редизайна, с разработкой, которая держится на одном основном мейнтейнере и сообществе. Именно из этой родословной выросли и FreshRSS (изначально позиционировался как переосмысление TT-RSS на понятном PHP-стеке), и отчасти Miniflux, который решил пойти в обратную сторону — к максимальному упрощению.

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

Стоит сразу закрыть вопрос сравнения: если вам нужен максимально простой сервис «поставил и забыл» с минимальным потреблением ресурсов — почти наверняка удобнее окажется FreshRSS или Miniflux, про выбор между ними у нас есть отдельный разбор. TT-RSS имеет смысл тогда, когда вам нужна гибкость, которую эти два проекта сознательно не дают.

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

TT-RSS — классический LAMP/LEMP-стек: PHP (проекту важны актуальные расширения — curl, gd, mbstring, intl, pdo, xml, json, opcache), веб-сервер (nginx или Apache с PHP-FPM) и база данных. Официально поддерживаемая и рекомендуемая СУБД — PostgreSQL; поддержка MySQL/MariaDB в проекте держится скорее по инерции и сообществом, поэтому для новой установки разумнее сразу брать Postgres, а не переносить привычку из других проектов.

Минимальная установка выглядит так:

sudo apt update && sudo apt install -y nginx postgresql php-fpm php-pgsql \
  php-curl php-gd php-mbstring php-intl php-xml php-json php-opcache git

sudo -u postgres createuser ttrss
sudo -u postgres createdb -O ttrss ttrss_db

cd /var/www
sudo git clone https://git.tt-rss.org/fox/tt-rss.git
sudo chown -R www-data:www-data tt-rss

Дальше конфигурация — через файл config.php (в старых версиях) либо переменные окружения TTRSS_* при более новой схеме развёртывания: адрес базы, SELF_URL_PATH (критично важный параметр — многие проблемы с логином и API упираются именно в неверный SELF_URL_PATH), пути к плагинам, включённые плагины через список TTRSS_PLUGINS.

Отдельный нюанс, которого нет во FreshRSS: обновление ленты не крутится через обычный cron-запуск разового скрипта, а идёт через демон — update_daemon2.php, который держит пул воркеров и сам управляет очередью обновлений. Его нужно поднять как systemd-сервис:

[Unit]
Description=Tiny Tiny RSS update daemon
After=network.target postgresql.service

[Service]
Type=simple
User=www-data
WorkingDirectory=/var/www/tt-rss
ExecStart=/usr/bin/php /var/www/tt-rss/update_daemon2.php
Restart=on-failure

[Install]
WantedBy=multi-user.target

Если демон не запущен или упал — ленты просто перестают обновляться без явной ошибки в интерфейсе, это первое, что стоит проверить, если статьи «зависли». Готового официального Docker-образа от автора проекта нет, но сообщество поддерживает рабочие docker-compose-сборки (например, репозиторий cthulhoo/ttrss-docker-compose, на который ссылается и вики самого проекта) — если предпочитаете контейнеры, это рабочий вариант, но именно официальным его считать нельзя, и при проблемах разбираться придётся по документации самой сборки, а не TT-RSS.

Публиковать наружу стоит только через HTTPS — логин идёт через обычную форму, и без TLS пароль улетит открытым текстом. Ставится это так же, как для любого другого self-hosted сервиса — через Let's Encrypt и обратный прокси; если пока не до конца понятно, как устроена эта связка nginx-приложение, у нас есть объяснение пути запроса через reverse proxy.

Плагины — главное преимущество TT-RSS

Вот где разница с молодыми читалками ощущается сильнее всего. У FreshRSS есть расширения, но их набор и API скромнее; у Miniflux системы плагинов нет вообще — только встроенные rewrite/block-правила и вебхуки. TT-RSS с самого начала спроектирован как ядро плюс плагины, и часть функциональности, которую в других читалках приходится ждать годами, здесь давно закрыта сторонним или официальным плагином.

Из того, что реально используется на практике:

• af_readability — на лету вытаскивает полный текст статьи по ссылке, если в RSS пришёл только огрызок с превью (частая проблема многих новостных лент).
• auth_ldap / auth_internal — авторизация через внешний LDAP/AD-каталог, актуально, если TT-RSS ставится не для себя одного, а для команды или семьи с общим сервером.
• note, mail, share — быстрые действия над статьёй: личная заметка, отправка по почте, генерация публичной ссылки на конкретную статью или подборку.
• af_redditimgur, af_comics — узкоспециализированные фильтры под конкретные источники контента, разворачивают галереи и медиа-вложения там, где обычный парсер RSS видит только ссылку.
• nginx_xaccel — отдаёт вложения (например, кэшированные изображения из лент) через X-Accel-Redirect, снимая нагрузку с PHP.
• feediron (сторонний, но один из самых популярных в сообществе) — настраиваемые по XPath/CSS-селектору правила извлечения контента персонально под конкретный проблемный источник, когда af_readability не справляется.

Плагины пишутся на PHP по достаточно простому API (класс с хуками на события — обработка статьи, рендер, добавление пункта меню), и написать свой под узкую задачу — вопрос часов, а не дней, если есть минимальный опыт с PHP. Это ключевое отличие в мышлении: во FreshRSS и особенно в Miniflux вы подстраиваетесь под то, что предусмотрели авторы; в TT-RSS при нехватке готовой функции у вас есть понятный путь её добавить самому, не форкая ядро.

Фильтры и правила обработки лент

Второй козырь — движок фильтров, который в TT-RSS заметно мощнее, чем rewrite-правила Miniflux или система меток FreshRSS. Фильтр в TT-RSS — это набор условий (по заголовку, содержимому, автору, тегам, дате) с булевой логикой «совпадает всё» или «совпадает любое», и набор действий, которые применяются к статье при совпадении:

• пометить прочитанной сразу при получении (полезно для лент, где 90% контента — шум, а нужные 10% вы читаете отдельно);
• присвоить метку (label) с произвольным цветом — по сути тегирование на лету;
• назначить score — числовой приоритет, по которому потом можно сортировать общую ленту;
• остановить дальнейшую обработку статьи другими фильтрами (аналог break в цепочке правил);
• полностью скрыть статью, если она попадает под условие «мусор» (например, рекламные посты в блоге, которые всегда начинаются с одной и той же фразы).

Практический пример — у вас пятнадцать технических блогов в одной категории, и вы хотите видеть анонсы релизов сразу с высоким приоритетом, а личные посты авторов — с низким, но не терять их вовсе:

Правило 1: заголовок содержит "release" ИЛИ "changelog"
  → действие: score = 10

Правило 2: заголовок содержит "personal" ИЛИ автор = "off-topic"
  → действие: score = -5, остановить обработку

Дальше сортируете общую ленту по score — и технические новости всплывают наверх без ручной сортировки по папкам. Ни в FreshRSS, ни тем более в Miniflux такой комбинации условий и действий из коробки нет — там либо простое автотегирование, либо regex-правила без числового скоринга.

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

Здесь у TT-RSS двойственная репутация, и справедливости ради нужно сказать честно про обе стороны.

Сильная сторона — сам API. У проекта есть собственный документированный JSON API (методы login, getHeadlines, updateArticle и так далее), который достаточно полон, чтобы на нём можно было построить полноценный клиент — что сообщество и делает годами. Плюс встроена поддержка Fever API через официальный плагин fever — это протокол, который изначально придумали для сервиса Fever, но он стал негласным стандартом, и многие мобильные RSS-читалки (например, Reeder и другие клиенты для iOS) умеют подключаться именно по нему, если у сервиса нет "родного" плагина под конкретное приложение.

Слабая сторона — официальное мобильное приложение. У проекта был официальный Android-клиент, который в какой-то момент пропал из Google Play на фоне конфликта разработчика с политикой площадки; сейчас его проще всего найти через F-Droid или собрать/установить APK напрямую с сайта проекта, а не искать в обычном маркете. Официального iOS-приложения нет вообще — для iPhone/iPad остаётся путь через Fever-совместимые сторонние клиенты. Это неудобно ровно один раз — на моменте установки приложения, — но именно это чаще всего отпугивает людей, которые сравнивают TT-RSS с FreshRSS и Miniflux по принципу «скачал из стора и сразу залогинился».

Если для вас критично именно «нашёл официальное приложение в маркете за минуту» — это довод в пользу более молодых читалок. Если вы уже привыкли ставить APK не из стора или пользуетесь Fever-совместимым клиентом — разница не ощущается, а взамен вы получаете гибкий API для своих скриптов (например, автоматически публиковать отобранные статьи в Telegram-канал, дергая getHeadlines по расписанию).

Когда выбрать TT-RSS, а когда — нет

Сравнение имеет смысл свести в таблицу, потому что универсального ответа тут нет — решает конкретный сценарий использования.

Выбирайте TT-RSS, если сценарий нетривиальный: десятки лент с разной степенью доверия, нужен скоринг и автосортировка по важности, вы хотите писать свои плагины под узкие задачи, или вам важен API с готовой экосистемой сторонних клиентов.

Выбирайте FreshRSS или Miniflux, если задача — просто читать ленты без тюнинга: поставить, залогиниться из приложения в сторе, подписаться и не трогать конфигурацию месяцами. Там ниже порог входа и меньше что может сломаться.

Эксплуатация и типичные грабли

Обновление TT-RSS идёт через git pull в каталоге установки с последующим прогоном миграций схемы базы данных — механизм устаревших автообновлений через веб-интерфейс проект в какой-то момент упростил в пользу git-based процесса, поэтому держите каталог установки именно как git-репозиторий, а не архив, распакованный вручную, иначе обновление превращается в ручное сравнение файлов.

Частые проблемы на практике:

• Ленты не обновляются, хотя интерфейс открывается. В 95% случаев — не запущен или упал update_daemon2.php. Проверяется командой systemctl status ttrss-daemon (или как вы назвали unit) и логами демона — там обычно сразу видна причина (не тот путь к PHP, нет прав на запись в кэш).
• Не логинится после смены домена. Почти всегда — не обновлён SELF_URL_PATH в конфиге после переезда на новый адрес или смену http на https.
• Плагин не появляется в списке доступных. Плагин должен лежать в plugins.local/, а не в plugins/ (последняя папка — часть git-репозитория и перезаписывается при обновлении), и быть явно перечислен в списке включённых плагинов в конфиге.
• Разрастание базы данных. При активном использовании таблица со статьями растёт быстро, особенно если храните полный текст через af_readability. Нужна периодическая очистка старых прочитанных статей — в самом TT-RSS есть настройка автоматической чистки по возрасту, её стоит включить сразу, а не разбираться с этим через полгода, когда база разрастётся.
• PHP-FPM таймауты на демоне. Демон обновления — долгоживущий процесс, не обычный веб-запрос; если он завёрнут в тот же PHP-FPM пул с короткими таймаутами, что и веб-интерфейс, будут случайные обрывы. Держите демон отдельным systemd-сервисом, как показано выше, а не запускайте его через cron-обёртку веб-запроса.

Ресурсы TT-RSS просит сопоставимые с FreshRSS: для небольшой коллекции лент (до пары сотен источников) хватает 1 vCPU и 1-2 ГБ RAM с запасом под PostgreSQL; при счёте на тысячи подписок или нескольких активных пользователях память под PostgreSQL и пул воркеров демона стоит закладывать больше — точную цифру лучше проверить на практике, а не ориентироваться на чужие бенчмарки: конфигурация лент у всех сильно разная.

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