Найкращі self-hosted RSS-рідери для VPS: порівняння

Який self-hosted RSS-рідер підійде для невеликого VPS

Miniflux — це self-hosted RSS-рідер для невеликого VPS. Він складається з одного бінарного файлу Go та бази даних PostgreSQL. Він підтримує API Fever та Google Reader, тому сторонні мобільні застосунки легко підключаються, а оновлення виконується однією командою docker compose pull. Обирайте FreshRSS, якщо вам потрібні розширення та один контейнер із вбудованою SQLite.

П’ять рідерів варті місця на диску вашого VPS: Miniflux, FreshRSS, CommaFeed, yarr та Tiny Tiny RSS. Ця сторінка порівнює їхні реальні відмінності: обсяг пам’яті, необхідний для кожного стека, базу даних, яку вимагає кожен із них, API для синхронізації, потрібний вашому мобільному застосунку, та процес оновлення. Усі наведені цифри або опубліковані розробниками проєктів, або є результатом простих обчислень, про що зазначено в тексті. Це не є тестуванням продуктивності вашого обладнання, тому вимірюйте показники власного сервера за допомогою docker stats.

П'ять читачів, по одному абзацу на кожного

Miniflux написаний на Go і постачається як єдиний статично скомпільований бінарний файл. Його документація прямо вказує на єдину жорстку залежність: він «працює лише з PostgreSQL». Режиму SQLite немає. Він пропонує REST API, API, сумісний із Fever, та API, сумісний із Google Reader, а також імпорт і експорт OPML. Повнотекстовий пошук покладено на PostgreSQL, що є однією з причин, чому база даних не є опціональною.

FreshRSS написаний на PHP і працює як один контейнер, що містить і вебсервер, і застосунок. SQLite є базою даних за замовчуванням і не потребує окремого сервісу, тоді як PostgreSQL і MySQL підтримуються для більших інсталяцій. Він підтримує API Google Reader та API Fever. Його встановлення вже розглянуто в нашому посібнику з FreshRSS на VPS, тому ця сторінка порівнює його, а не повторює процес встановлення.

CommaFeed — це Java на Quarkus із макетом, що копіює Google Reader. Його база даних обирається під час збірки, а не під час виконання, тому проєкт публікує по одному образу для кожної бази: athou/commafeed:latest-h2 для вбудованої бази даних H2, athou/commafeed:latest-postgresql для PostgreSQL, а також інші варіанти для MySQL та MariaDB. Він надає REST API та API, сумісний із Fever.

yarr (yet another rss reader) — це один бінарний файл Go із вбудованим SQLite, який взагалі не потребує контейнера. Звичайний ./yarr слухає 127.0.0.1:7070. Прапорці короткі: -addr 0.0.0.0:7070 -auth alice:secret відкриває доступ до мережі за паролем, а -db /data/yarr.db розміщує базу даних там, де вам потрібно. Він має API, сумісний із Fever. Його найновіший тегований реліз — v2.8, від липня 2024 року, перевірений у серпні 2026 року, тому сприймайте його як завершене програмне забезпечення, а не як проєкт, що активно розвивається.

Tiny Tiny RSS — найстаріший із п'яти і найважчий у запуску. Офіційна Docker-конфігурація складається з чотирьох сервісів: контейнера PostgreSQL, контейнера застосунку PHP-FPM, окремого контейнера оновлення, який завантажує стрічки, і контейнера nginx попереду. Документація чітко зазначає, що «ця конфігурація використовує PostgreSQL». Він має власний JSON API, який використовує його Android-клієнт і кілька сторонніх застосунків. Fever не підтримується.

Скільки пам'яті потрібно кожному стеку

Наведені нижче цифри — це бюджети, а не результати вимірювань: це ліміти пам'яті, у межах яких має працювати кожен стек на невеликому VPS. Значення для CommaFeed — це офіційно опублікований приклад проєкту, який обмежує контейнер 256 МБ. Інші значення — це граничні показники, що залишають запас для механізму отримання стрічок, який споживає найбільше ресурсів під час циклу оновлення.

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr займає найменше місця — 128 МБ, оскільки це один бінарний файл і один файл SQLite без окремого сервера баз даних чи середовища виконання мови програмування. Miniflux потребує 320 МБ для 2 контейнерів, причому більша частина цього обсягу припадає на PostgreSQL, а не на сам Miniflux. Tiny Tiny RSS виділяється на фоні інших із 640 МБ для 4 контейнерів, оскільки застосунок, оновлювач, база даних і вебсервер — це чотири окремі процеси з чотирма окремими областями пам'яті (heaps).

Встановлюйте ці значення як реальні ліміти, а не як очікування. У розділі Ліміти пам'яті в Docker Compose описано синтаксис і поведінку контейнера при досягненні граничного значення. Контейнер без лімітів не завершує роботу коректно при вичерпанні ресурсів системи: ядро обирає процес-жертву і примусово завершує його, і цією жертвою часто стає не той контейнер, що спричинив навантаження.

Яку базу даних нав'язує кожен зчитувач

База даних — це найбільша операційна відмінність між цими п'ятьма варіантами. Це важливіше рішення, ніж будь-яка різниця в інтерфейсі користувача, оскільки воно визначає вашу процедуру резервного копіювання та ризики під час оновлення.

PostgreSQL вимагається для Miniflux та офіційного налаштування Tiny Tiny RSS. Вона забезпечує повнотекстовий пошук і безпечний паралельний запис даних. Це коштує додаткового контейнера, окремого тому та однієї постійної проблеми: офіційні образи PostgreSQL не можуть виконувати міграцію даних між основними версіями (major versions) на місці. Документація Tiny Tiny RSS прямо зазначає це і попереджає, що "офіційні контейнери PostgreSQL не підтримують міграцію даних між основними версіями". Ваші реалістичні варіанти — зафіксувати стару основну версію або виконувати дамп і відновлення за допомогою pg_dump та pg_restore. Плануйте це раз на рік або два.

SQLite є стандартним вибором для FreshRSS та yarr. Один файл, жодного сервера, жодних портів чи паролів. Він добре працює для однієї людини з кількома сотнями стрічок, але сповільнюється, коли кілька користувачів записують дані одночасно — саме тоді опція PostgreSQL у FreshRSS починає виправдовувати себе. yarr додав підтримку PostgreSQL як опцію у v2.7, але вбудований файл залишається стандартним способом запуску.

H2 — це вбудований стандарт для CommaFeed, і він заслуговує на увагу перед початком роботи, оскільки CommaFeed обирає базу даних під час збірки образу. Перехід з H2 на PostgreSQL пізніше — це не просто зміна конфігурації. Це інший образ плюс міграція даних, яку ви повинні виконати самостійно, тому вирішуйте це до того, як у вас накопичиться рік історії читання в системі.

Чи працюватиме ваш мобільний застосунок

Це питання важливіше, ніж здається на перший погляд, оскільки веб-інтерфейс — це лише частина того, як користувачі взаємодіють із читачем стрічок.

Miniflux підтримує API, сумісні з Fever та Google Reader, тому більшість клієнтів для iOS та Android можуть до нього підключитися. FreshRSS підтримує ці ж два API, і в його документації вони ранжовані: API Google Reader є «найкращим» із повною підтримкою функцій, тоді як API Fever має «обмежені можливості та менш ефективну» роботу. FreshRSS також потребує виконання двох кроків перед тим, як будь-який застосунок зможе увійти в систему. Увімкніть «Allow API access (required for mobile apps)» у розділі Authentication, а потім створіть пароль API у профілі користувача. Пропуск кроку зі створенням пароля API призведе до помилки автентифікації в застосунку, тоді як вхід через веб-інтерфейс продовжуватиме працювати, що збиває з пантелику, доки ви не дізнаєтеся, де шукати причину.

CommaFeed та yarr надають лише API, сумісний із Fever, тому вони працюють із клієнтами, що підтримують Fever, але не з тими, що працюють лише через Google Reader. Tiny Tiny RSS натомість використовує власний API, що означає потребу в клієнті, розробленому спеціально для нього. Переконайтеся, що обраний вами застосунок підтримує читач, перш ніж імпортувати в нього 300 стрічок.

Робочий compose-файл для сервера з 1 ГБ пам'яті

Це стек Miniflux, адаптований з офіційного прикладу Docker станом на серпень 2026 року. Опублікований порт прив'язаний до loopback, адреса прослуховування встановлена явно, а для обох контейнерів задано ліміт пам'яті.

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

У цьому файлі є три рядки, у яких найчастіше припускаються помилок. LISTEN_ADDR=0.0.0.0:8080 встановлено тому, що задокументоване значення за замовчуванням для бінарного файлу — 127.0.0.1:8080, а процес, прив'язаний до loopback всередині контейнера, недоступний через опублікований порт. У результаті ви отримуєте скидання з'єднання (connection reset), хоча контейнер виглядає справним. Шлях до тому /var/lib/postgresql відповідає PostgreSQL 18; версія 17 і раніші зберігають дані в /var/lib/postgresql/data, і монтування неправильного шляху означає, що каталог даних взагалі не потрапляє на том, тому все зникає після наступного перестворення контейнера. 127.0.0.1:8080:8080 обмежує доступ до порту з публічного інтернету, оскільки публікація порту без вказання адреси додає правило в ланцюжок, яким ufw не керує. Docker ports bypass ufw пояснює цей механізм, а a Traefik reverse proxy показує, як налаштувати TLS перед ним.

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps має показувати обидва сервіси як активні, а базу даних — як healthy. Перший запуск Miniflux виводить у журнал процес міграції схеми, що ініціюється командою RUN_MIGRATIONS=1. docker stats --no-stream виводить поточне споживання пам'яті, це значення слід порівнювати з лімітами в таблиці вище. Якщо контейнер Miniflux перезапускається в циклі, перевірте його журнал: connect: connection refused означає, що він запустився раніше, ніж PostgreSQL був готовий приймати з'єднання, що саме і запобігає умові service_healthy, тому переконайтеся, що ця умова збереглася після ваших редагувань. Якщо ви вперше працюєте з Compose, Docker Compose basics on a VPS допоможе розібратися зі структурою файлу.

Що не вміститься на сервері з 1 ГБ оперативної пам'яті

Tiny Tiny RSS — це сервіс, від якого варто відмовитися. Його офіційний стек із чотирьох служб працює на VPS з 1 ГБ пам'яті лише тоді, коли на цьому сервері більше нічого немає, і він не працюватиме поруч з іншим застосунком, що потребує бази даних, та reverse proxy. Чотири служби означають чотири набори накладних витрат, а одна з них — це PostgreSQL.

CommaFeed вміщується, але лише з образом H2 та обмеженням у 256 МБ, яке встановлено у власному прикладі проєкту. Поєднання, що виводить з ладу невеликий сервер — це JVM поруч із окремим сервером бази даних, оскільки JVM займає весь вільний простір, який ви їй залишаєте. Документація CommaFeed вказує на -Xmx256m як на жорсткий ліміт, а на OpenJ9 — як на «більш ефективну щодо пам'яті альтернативу HotSpot JVM», що дає зрозуміти, куди витрачається пам'ять.

Коли на сервері закінчується пам'ять, ядро системи за допомогою механізму out of memory killer обирає процес і завершує його. dmesg -T показує рядок на кшталт Out of memory: Killed process 1234 (java), і контейнер просто зникає з docker compose ps без жодного повідомлення в журналі застосунку, оскільки застосунок не встигає його записати.

Як відбуваються оновлення для кожного з них

• Miniflux: docker compose pull && docker compose up -d, міграції схеми застосовуються під час запуску, якщо встановлено RUN_MIGRATIONS=1. Ризик під час оновлення полягає не в Miniflux, а в мажорній версії PostgreSQL, на якій він працює.
• FreshRSS: завантажте новий образ. У разі використання SQLite немає потреби оновлювати рушій бази даних, тому типові проблеми виникають через сторонні розширення, які не були вчасно оновлені.
• CommaFeed: завантажте варіант образу, що відповідає вашій базі даних. Перехід з latest-h2 на latest-postgresql не передбачає перенесення ваших даних.
• yarr: замініть бінарний файл і збережіть файл бази даних. Оскільки з моменту виходу v2.8 у липні 2024 року, станом на серпень 2026 року, нових релізів не було, оновлювати зазвичай нічого.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Міграції схеми виконуються автоматично, а інтерфейс перенаправляє вас на сторінку міграції, якщо вона потребує підтвердження.

Робіть дамп бази даних до початку будь-яких цих дій, а не після.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

Вартість інтервалу оновлення в пропускній здатності

Наведені нижче цифри є арифметичними, а не результатами вимірювань. Вони базуються на припущенні про 100 стрічок, один запит на стрічку за інтервал і 40 KB на відповідь. Реальний трафік нижчий, коли сервер підтримує умовні запити, і вищий, коли стрічки містять повний текст статей.

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

П'ятихвилинний інтервал для 100 стрічок — це 864,000 запитів і приблизно 34.6 GB на місяць. Погодинне опитування — це 72,000 запитів і близько 2.9 GB. Miniflux постачається з параметром POLLING_FREQUENCY, встановленим на 60 хвилин, що відповідає останньому рядку таблиці, і це значення за замовчуванням є оптимальним майже для всіх. Стаття не з'явиться швидше лише тому, що ви запитуєте її частіше.

Умовні запити дозволяють утримувати реальні показники нижче арифметичних. Читач, який зберігає заголовки ETag та Last-Modified, отримані від стрічки, надсилає їх назад як If-None-Match та If-Modified-Since, і сервер, якщо немає нових даних, відповідає 304 Not Modified без тіла відповіді. З'єднання все одно потребує виконання рукостискання, але не передачі корисного навантаження. Стрічки, що ігнорують умовні запити, щоразу надсилають весь документ, тому кілька великих стрічок можуть самотужки вичерпати ваш ліміт передачі даних.

Надто часте опитування також призводить до блокування. Сервер, який вирішить, що ви створюєте надмірне навантаження, відповість 429 Too Many Requests, а деякі сайти відповідають 403. Miniflux записує останню помилку для кожної стрічки, тому список стрічок — це перше місце, куди варто зазирнути, якщо одна стрічка перестала оновлюватися, тоді як інші продовжують працювати.

Стрічки новин зникають, а OPML-файл — це не резервна копія

Стрічки новин застарівають швидше, ніж ви очікуєте. Термін дії доменів спливає, сайти переходять на платформи без підтримки стрічок, а URL-адреса, що раніше віддавала XML, починає повертати HTML-сторінку з помилкою зі статусом 200 OK. Останній випадок найбільш проблемний: запит проходить успішно, але парсинг завершується помилкою, і ваш зчитувач фіксує помилку парсингу замість мережевої помилки. Раз на рік сортуйте список стрічок за датою останнього оновлення та видаляйте ті, що замовкли.

Експорт у форматі OPML — це лише ваш список підписок. Він містить URL-адреси стрічок та назви папок. Він не зберігає стан прочитання, позначені зірочкою статті, налаштування для окремих стрічок, правила фільтрації чи збережений текст статей. Якщо імпортувати цей OPML у нову інсталяцію, ви отримаєте свої стрічки назад, але всі раніше прочитані статті знову будуть позначені як непрочитані.

Резервна копія, що має значення, — це база даних. Для PostgreSQL команда pg_dump, наведена вище, виконує всю роботу. Для зчитувача на базі SQLite, як-от FreshRSS або yarr, зупиніть процес запису та скопіюйте файл, або створіть консистентну копію під час роботи за допомогою sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Звичайне виконання cp для бази даних, у яку в цей момент іде запис, може призвести до створення файлу, який згодом не відкриється, оскільки копія зафіксує незавершений запис. Після цього пересилайте ці файли за межі сервера за розкладом — саме для цього призначені резервні копії restic на VPS, і принаймні один раз відновіть дані в тестовий контейнер, щоб переконатися, що процедура працює.

Зчитувач стрічок — один із найдешевших сервісів для self-hosting, тому він присутній у кожному списку проєктів, які варто розміщувати самостійно у 2026 році. Розгорніть поруч власний екземпляр SearXNG, і як ваше читання, так і пошук залишаться на обладнанні, яке ви контролюєте.

FAQ

Який self-hosted RSS-рідер споживає найменше оперативної пам'яті?

yarr. Це один бінарний файл Go із вбудованою SQLite, тому він не потребує окремого сервера баз даних чи середовища виконання, а ліміту в 128 МБ цілком достатньо. Компромісом є підтримка та функціонал: останній реліз v2.8 вийшов у липні 2024 року, і він підтримує лише Fever API. Якщо вам потрібен проєкт, що активно розвивається, з аналогічним споживанням ресурсів, кращим вибором буде Miniflux разом із PostgreSQL з лімітом 320 МБ.

Чи можна запустити self-hosted RSS-рідер на VPS з 1 ГБ оперативної пам'яті?

Так. Miniflux із PostgreSQL вкладається приблизно в 320 МБ, якщо встановити mem_limit для обох контейнерів, а FreshRSS із SQLite працює в одному контейнері. На 1 ГБ варто уникати офіційного стека Tiny Tiny RSS, оскільки він складається з 4 сервісів, включно з власним екземпляром PostgreSQL. Завжди встановлюйте ліміти пам'яті, оскільки без них ядро може примусово завершити процес при вичерпанні ресурсів, і часто це буде база даних, а не проблемний застосунок.

Які з цих сервісів працюють із мобільними RSS-клієнтами на iOS та Android?

Miniflux і FreshRSS підтримують як Fever API, так і Google Reader API, тому до них можна підключити майже будь-який мобільний клієнт. CommaFeed та yarr пропонують лише Fever API. Tiny Tiny RSS використовує власний API, тому для нього потрібен спеціалізований клієнт. У FreshRSS необхідно додатково увімкнути доступ до API в налаштуваннях автентифікації та встановити окремий пароль для API у профілі, інакше застосунок не зможе авторизуватися, попри те, що вебверсія працюватиме.

Чи є експорт OPML резервною копією мого RSS-рідера?

Ні. OPML містить лише URL-адреси стрічок та структуру папок, тому він дозволяє відновити лише список підписок. Статус прочитання, позначені зірочкою статті, правила фільтрації та текст самих статей зберігаються в базі даних. Створюйте резервну копію самої бази даних за допомогою pg_dump для PostgreSQL або команди .backup для SQLite, а потім копіюйте отриманий файл за межі сервера.

Чи підтримує Miniflux SQLite?

Ні. У документації проєкту зазначено, що він «працює лише з PostgreSQL», а повнотекстовий пошук реалізовано за допомогою функцій PostgreSQL, тому полегшеного режиму роботи не передбачено. Якщо вам потрібен RSS-рідер без окремого контейнера бази даних, використовуйте FreshRSS із типовим бекендом SQLite або yarr із вбудованим файлом бази.