Miniflux vs FreshRSS at Iba pang RSS Reader sa VPS

Aling self-hosted RSS reader ang angkop sa maliit na VPS

Ang Miniflux ang self-hosted RSS reader na dapat gamitin sa maliit na VPS. Isa itong Go binary na katabi ng PostgreSQL. Sinusuportahan nito ang Fever at Google Reader APIs, kaya makakakonekta ang mga third-party phone app, at ang pag-upgrade ay isang docker compose pull. Piliin ang FreshRSS kung kailangan mo ng extensions at isang container na may SQLite sa loob nito.

Limang reader ang sulit ilaanan ng disk space sa isang VPS: Miniflux, FreshRSS, CommaFeed, yarr, at Tiny Tiny RSS. Inihahambing ng page na ito ang aktuwal na pagkakaiba ng mga ito: ang memory na kailangan ng bawat stack, ang database na kinakailangan ng bawat isa, ang sync API na kailangan ng phone app mo, at ang mangyayari kapag araw na ng upgrade. Ang bawat figure dito ay alinman sa inilathala ng project o simpleng arithmetic, at sinasabi ng teksto kung alin dito ang ginamit. Wala sa mga ito ang benchmark ng hardware mo, kaya sukatin ang sarili mong box gamit ang docker stats.

Ang limang reader, tig-isang talata

Ang Miniflux ay isinulat sa Go at inilalabas bilang isang statically compiled binary. Malinaw ang dokumentasyon nito tungkol sa isang mandatoryong dependency: “gumagana lamang ito sa PostgreSQL”. Walang SQLite mode. Mayroon itong REST API, Fever compatible API, at Google Reader compatible API, pati OPML import at export. PostgreSQL ang humahawak sa full-text search, kaya hindi optional ang database.

Ang FreshRSS ay PHP at tumatakbo bilang isang container na naglalaman ng web server at application. SQLite ang default na database at hindi nangangailangan ng pangalawang service, habang suportado ang PostgreSQL at MySQL para sa mas malalaking installation. Gumagamit ito ng Google Reader API at Fever API. Nasa aming walkthrough sa FreshRSS sa isang VPS na ang installation nito, kaya ihahambing lamang ito rito at hindi na uulitin ang installation.

Ang CommaFeed ay Java sa Quarkus, na may layout na kumokopya sa Google Reader. Pinipili ang database nito sa build time, hindi sa run time, kaya naglalabas ang project ng isang image para sa bawat database: athou/commafeed:latest-h2 para sa embedded H2 database, athou/commafeed:latest-postgresql para sa PostgreSQL, at iba pang variant para sa MySQL at MariaDB. Naglalantad ito ng REST API at Fever compatible API.

Ang yarr (yet another rss reader) ay isang Go binary na may embedded SQLite, at hindi nangangailangan ng container. Nakikinig ang plain ./yarr sa 127.0.0.1:7070. Maikli ang mga flag nito: binubuksan ito ng -addr 0.0.0.0:7070 -auth alice:secret sa network sa likod ng password, at inilalagay ng -db /data/yarr.db ang database sa lokasyong gusto mo. Mayroon itong Fever compatible API. Ang pinakabagong tagged release nito ay v2.8, mula Hulyo 2024, at sinuri noong Agosto 2026, kaya ituring itong tapos nang software sa halip na aktibong dine-develop.

Ang Tiny Tiny RSS ang pinakamatanda sa lima at pinakamabigat patakbuhin. Ang opisyal na Docker setup ay may apat na service: isang PostgreSQL container, isang PHP-FPM application container, isang hiwalay na updater container na kumukuha ng feeds, at isang nginx container sa harap. Malinaw na sinasabi ng dokumentasyon na “PostgreSQL ang ginagamit ng setup na ito”. May sarili itong JSON API na ginagamit ng Android client nito at ng ilang third-party app. Hindi ito kasama sa Fever.

Gaano karaming memory ang kailangan ng bawat stack

Ang mga figure sa ibaba ay mga budget, hindi aktuwal na sukat: ito ang memory ceiling na dapat hindi lampasan ng bawat stack sa isang maliit na VPS. Ang numero para sa CommaFeed ay mula sa sarili nitong published example ng project, na naglilimita sa container sa 256 MB. Ang iba naman ay mga ceiling na may natitirang headroom para sa feed fetcher, na siyang karaniwang biglang kumokonsumo ng memory kapag nagsimula ang refresh cycle.

[
  {
    "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
  }
]

Pinakamababa ang yarr sa 128 MB dahil isa itong binary at isang SQLite file, na walang database server at walang language runtime sa ilalim nito. Kailangan ng Miniflux ng 320 MB para sa 2 containers, at ang karamihan nito ay napupunta sa PostgreSQL, hindi sa Miniflux. Ang Tiny Tiny RSS ang outlier sa 640 MB para sa 4 containers, dahil magkahiwalay na process ang application, updater, database, at web server, at bawat isa ay may sariling heap.

Itakda ang mga ito bilang aktuwal na limits, hindi bilang mga inaasahan lamang. Saklaw ng Memory limits sa Docker Compose ang syntax at ipinapaliwanag nito kung ano ang ginagawa ng container kapag naabot nito ang ceiling. Kapag walang limit ang isang container, hindi ito maayos na magfa-fail kapag napuno ang server: pipili ang kernel ng process na papatayin, at kadalasan ay hindi ang container na nagdulot ng pressure ang napipiling biktima.

Aling database ang ipinapataw sa iyo ng bawat reader

Ang database ang pinakamalaking pagkakaiba sa operasyon ng limang ito. Mas malaking desisyon ito kaysa sa anumang pagkakaiba sa user interface, dahil tinutukoy nito ang backup procedure at upgrade risk mo.

Kinakailangan ang PostgreSQL ng Miniflux at ng official Tiny Tiny RSS setup. Nagbibigay ito ng tunay na full-text search at ligtas na concurrent writes. Kapalit nito ang ikalawang container, isang volume, at isang paulit-ulit na problema: hindi kayang mag-migrate ng data in place ng official PostgreSQL images sa pagitan ng major versions. Direktang sinasabi ito sa Tiny Tiny RSS documentation, at nagbababala na “walang support ang official PostgreSQL containers para sa pag-migrate ng data sa pagitan ng major versions.” Ang makatotohanan mong mga opsyon ay i-pin ang lumang major version, o mag-dump at mag-restore gamit ang pg_dump at pg_restore. Magplano para rito isang beses bawat isa o dalawang taon.

Ang SQLite ang default ng FreshRSS at ng yarr. Isang file lang ito; walang server, port, o password. Maayos ang performance nito para sa isang tao na may ilang daang feed. Bumibigat ito kapag sabay-sabay na nagsusulat ang ilang user. Sa ganitong sitwasyon nagsisimulang maging kapaki-pakinabang ang PostgreSQL option ng FreshRSS. Nagdagdag ang yarr ng optional PostgreSQL support sa v2.7, pero ang embedded file ang karaniwang paraan ng pag-run nito.

Ang H2 ang embedded default ng CommaFeed. Dapat mo itong pag-isipan bago magsimula, dahil pinipili ng CommaFeed ang database nito kapag bina-build ang image. Ang paglipat mula H2 papuntang PostgreSQL ay hindi simpleng configuration change. Ibang image ito, kasama ang data migration na ikaw mismo ang kailangang magsagawa. Kaya magpasya bago umabot ng isang taon ang read history na naka-store sa server.

Gagana ba ang phone app mo

Mas mahalaga ang tanong na ito kaysa sa inaasahan ng marami, dahil kalahati lamang ng paggamit ng feed reader ang web interface.

May Fever compatible API at Google Reader compatible API ang Miniflux, kaya nakakonekta rito ang karamihan sa iOS at Android client. Pareho ring API ang sinasalita ng FreshRSS, at inaayos ng sarili nitong documentation ang antas ng suporta: “best” ang Google Reader API dahil buo ang feature support, samantalang ang Fever API ay may “limited features and less efficient” na behavior. Kailangan din ng FreshRSS ng dalawang hakbang bago makapag-log in ang anumang app. I-enable ang “Allow API access (required for mobile apps)” sa ilalim ng Authentication, pagkatapos ay gumawa ng API password sa user profile. Kapag nilaktawan ang API password, magbibigay ng authentication failure ang app habang patuloy na gumagana ang web login. Nakalilito ito kung hindi mo alam kung saan titingin.

Parehong naglalantad ang CommaFeed at yarr ng Fever compatible API lamang, kaya gumagana ang mga ito sa Fever capable client ngunit hindi sa mga app na Google Reader lamang ang sinusuportahan. Sarili nitong API ang gamit ng Tiny Tiny RSS, kaya kailangan mo ng client na ginawa para rito. Tiyaking sinusuportahan ng napili mong app ang reader bago ka mag-import ng 300 feed dito.

Isang gumaganang compose file para sa isang 1 GB na server

Ito ang Miniflux stack, na inangkop mula sa sariling Docker example ng proyekto noong August 2026. Naka-bind ang published port sa loopback, tahasang itinakda ang listen address, at may memory limit ang dalawang container.

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:

Tatlong linya sa file na ito ang madalas nagkakamali ang mga tao. Itinakda ang LISTEN_ADDR=0.0.0.0:8080 dahil ang dokumentadong default ng binary ay 127.0.0.1:8080. Hindi maaabot sa pamamagitan ng published port ang prosesong naka-bind sa loopback sa loob ng container. Dahil dito, makakakuha ka ng connection reset kahit mukhang healthy ang container. Ang volume path na /var/lib/postgresql ay tumutugma sa PostgreSQL 18. Sa version 17 at mas luma, sa /var/lib/postgresql/data iniimbak ang data. Kapag maling path ang ni-mount, wala talaga sa volume ang data directory. Kaya mawawala ang lahat sa susunod na pag-recreate ng container. Pinananatili ng 127.0.0.1:8080:8080 na hindi naaabot ng public internet ang port. Kapag nag-publish ng port nang walang address, naglalagay ito ng rule sa chain na hindi mina-manage ng ufw. Ipinaliliwanag ng Ang mga Docker port ay lumalampas sa ufw ang mekanismong iyon, at ang isang Traefik reverse proxy ang ginagamit para maglagay ng TLS sa harap nito.

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

Dapat ipakita ng docker compose ps na parehong running ang dalawang service, at dapat markahan ang database bilang healthy. Sa unang pag-start ng Miniflux, nilala-log nito ang schema migrations. Ito ang tina-trigger ng RUN_MIGRATIONS=1. Ipinapakita ng docker stats --no-stream ang live memory column. Iyon ang numerong dapat ihambing sa mga ceiling sa chart sa itaas. Kung paulit-ulit na nagre-restart ang Miniflux container, basahin ang log nito. Ibig sabihin ng connect: connection refused ay nagsimula ito bago handang tumanggap ng connections ang PostgreSQL. Ito mismo ang pinipigilan ng condition na service_healthy, kaya tiyaking nanatili ang condition matapos mong i-edit ang file. Kung bago sa iyo ang Compose, inilalahad muna ng Mga pangunahing kaalaman sa Docker Compose sa isang VPS ang layout ng file.

Mga hindi kasya sa 1 GB na server

Ang Tiny Tiny RSS ang dapat laktawan. Ang opisyal nitong four-service stack ay tumatakbo sa 1 GB VPS kapag wala nang ibang ginagawa ang VPS, pero hindi ito tatakbo roon kasabay ng isa pang database-backed application at reverse proxy. Apat na serbisyo ang ibig sabihin ay apat na set ng overhead, at PostgreSQL ang isa sa mga ito.

Kasya ang CommaFeed, pero gamit lamang ang H2 image at ang 256 MB cap na itinakda sa sariling example ng proyekto. Ang pairing na nagpapabigat sa maliit na server ay JVM na katabi ng hiwalay na database server, dahil ginagamit ng JVM ang anumang memory headroom na iiwan mo rito. Itinuturo ng documentation ng CommaFeed ang -Xmx256m bilang hard limit at ang OpenJ9 bilang “a more memory-efficient alternative to the HotSpot JVM,” kaya malinaw kung saan napupunta ang memory nito.

Kapag nauubusan ng memory ang server, pumipili ang kernel out of memory killer ng isang process at tina-terminate ito. Ipinapakita ng dmesg -T ang linyang gaya ng Out of memory: Killed process 1234 (java), at basta nawawala ang container mula sa docker compose ps nang walang mensahe sa application log, dahil hindi na nakapagsulat ng mensahe ang application.

Paano umaasal ang bawat isa kapag nag-upgrade

• Miniflux: docker compose pull && docker compose up -d, at inilalapat ang schema migration sa pagsisimula habang naka-set ang RUN_MIGRATIONS=1. Hindi Miniflux ang pangunahing panganib sa upgrade. Ang PostgreSQL major version na nasa ilalim nito ang panganib.
• FreshRSS: i-pull ang bagong image. Sa SQLite, walang database engine na kailangang i-upgrade, kaya karaniwang nagmumula ang mga problema sa third-party extension na hindi nakasabay sa mga pagbabago.
• CommaFeed: i-pull ang image variant na tugma sa iyong database. Kapag lumipat mula latest-h2 patungo sa latest-postgresql, hindi naililipat ang iyong data.
• yarr: palitan ang binary at panatilihin ang database file. Dahil walang release mula v2.8 noong July 2024, batay sa pagsusuri noong August 2026, karaniwan ay wala nang kailangang i-upgrade.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Awtomatikong tumatakbo ang schema migration, at nire-redirect ka ng interface sa migration screen kapag kailangan ng kumpirmasyon.

Gumawa ng database dump bago ang alinman sa mga ito, hindi pagkatapos.

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

Magkano ang bandwidth na nagagastos sa refresh interval

Ang mga numero sa ibaba ay batay sa arithmetic, hindi sa aktuwal na measurement. Ipinapalagay ng mga ito ang 100 feed, isang request bawat feed sa bawat interval, at 40 KB bawat response. Karaniwang mas mababa ang totoong traffic kapag hinahawakan ng server ang conditional requests, at mas mataas kapag buong article text ang dala ng mga feed.

[
  {
    "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
  }
]

Ang limang minutong interval para sa 100 feed ay 864,000 request at humigit-kumulang 34.6 GB bawat buwan. Ang hourly polling ay 72,000 request at humigit-kumulang 2.9 GB. Kasama sa Miniflux ang POLLING_FREQUENCY na nakatakda sa 60 minuto. Ito ang huling row ng chart na iyon, at tama ang default na ito para sa halos lahat. Hindi mas mabilis dumarating ang article dahil mas madalas mo itong hinihingi.

Ang conditional requests ang dahilan kung bakit mas mababa sa arithmetic ang aktuwal na bilang. Ang reader na nagse-save ng ETag at Last-Modified headers na ibinalik ng feed ay ibinabalik ang mga ito bilang If-None-Match at If-Modified-Since. Kapag walang bagong content ang server, sumasagot ito ng 304 Not Modified nang walang body. May gastos pa rin ang connection para sa handshake, pero wala nang payload. Ang mga feed na hindi tumatanggap ng conditional requests ay ipinapadala ang buong document sa bawat request. Dahil dito, maaaring ilang malalaking feed lang ang bumuo sa malaking bahagi ng iyong transfer bill.

Maaari ka ring ma-block kapag sobra ang polling. Ang server na nagpasiyang masyado kang maraming request ay sumasagot ng 429 Too Many Requests, at may ilang site na 403 naman ang isinasagot. Itinatala ng Miniflux ang huling error laban sa mismong feed. Kaya ang feed list ang unang dapat suriin kapag tumigil sa pag-update ang isang feed habang patuloy na gumagana ang iba.

Nasasira ang feeds, at hindi backup ang isang OPML file

Mas mabilis masira ang feeds kaysa sa inaasahan mo. Nag-e-expire ang mga domain, lumilipat ang mga site sa platform na walang feed, at ang URL na dating naghahatid ng XML ay nagsisimulang maghatid ng HTML error page na may 200 OK status. Iyon ang mahirap na kaso: nagtatagumpay ang fetch, bumabagsak ang parse, at nagtatala ang reader ng parsing error sa halip na network error. Minsan sa isang taon, ayusin ang feed list ayon sa pinakahuling update at tanggalin ang mga feed na matagal nang walang bagong nilalaman.

Ang OPML export ay listahan ng iyong mga subscription. Naglalaman ito ng mga feed URL at pangalan ng folder. Hindi nito naglalaman ang read state, starred articles, per-feed settings, filter rules, o article text na na-save mo. Kapag in-import mo ang OPML sa bagong installation, maibabalik ang iyong mga feed, pero mamarkahang unread muli ang bawat article na nabasa mo na.

Ang mahalagang i-backup ay ang database. Para sa PostgreSQL, buong proseso na ang pg_dump command sa itaas. Para sa SQLite reader gaya ng FreshRSS o yarr, ihinto ang writer at kopyahin ang file, o kumuha ng consistent copy habang tumatakbo ito gamit ang sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Ang plain na cp ng database na sinusulatan pa ay maaaring lumikha ng file na hindi na magbubukas, dahil maaaring makuha ng kopya ang write na hindi pa tapos. Pagkatapos, regular na itulak ang mga file na iyon palabas ng server, gaya ng ginagawa sa restic backups sa isang VPS, at kahit isang beses ay i-restore ang isa sa isang scratch container upang matiyak mong gumagana ang procedure.

Isa ang feed reader sa pinakamurang serbisyong maaari mong i-self-host, kaya kasama ito sa bawat listahan ng mga serbisyong sulit i-self-host sa 2026. Maglagay ng self-hosted na SearXNG instance sa tabi nito upang manatili sa hardware na kontrolado mo ang pagbabasa at paghahanap mo.

FAQ

Aling self-hosted RSS reader ang gumagamit ng pinakamaliit na memory?

yarr. Isa itong binary na ginawa sa Go na may naka-compile na SQLite, kaya walang hiwalay na database server o language runtime, at sapat na ang 128 MB na ceiling. Kapalit nito ang maintenance at mga feature: ang pinakabagong release nito ay v2.8 mula Hulyo 2024, at Fever API lamang ang sinusuportahan nito. Kung gusto mo ng aktibong dine-develop na project na halos kapareho ang footprint, mas mainam ang Miniflux kasama ang PostgreSQL sa 320 MB.

Maaari ba akong magpatakbo ng self-hosted RSS reader sa 1 GB VPS?

Oo. Kasya ang Miniflux kasama ang PostgreSQL sa humigit-kumulang 320 MB kapag itinakda mo ang mem_limit sa parehong container, at kasya ang FreshRSS kasama ang SQLite sa isang container. Ang dapat iwasan sa 1 GB ay ang official Tiny Tiny RSS stack, na may 4 service kasama ang sarili nitong PostgreSQL. Palaging magtakda ng memory limits, dahil kapag walang limit ang isang container sa punô nang server, may process na papatayin ang kernel, at madalas database ang napipili sa halip na ang application na may problema.

Alin sa mga ito ang gumagana sa iOS at Android RSS app?

Sinusuportahan ng Miniflux at FreshRSS ang Fever compatible API at Google Reader compatible API, kaya halos anumang mobile client ay makakakonekta. Fever API lamang ang iniaalok ng CommaFeed at yarr. Sarili nitong API ang ginagamit ng Tiny Tiny RSS, kaya kailangan mo ng client na ginawa para rito. Sa FreshRSS, kailangan mo ring i-enable ang API access sa ilalim ng Authentication at magtakda ng hiwalay na API password sa profile. Kung hindi, hindi makakapag-login ang app kahit gumagana pa ang website.

Backup ba ng RSS reader ko ang OPML export?

Hindi. Nagtatago ang OPML ng feed URLs at folders, kaya nire-rebuild nito ang subscription list at wala nang iba. Nasa database ang read state, starred items, filter rules, at article text. I-back up mismo ang database gamit ang pg_dump para sa PostgreSQL, o isang .backup command para sa SQLite, at kopyahin ang resulta palabas ng server.

Sinusuportahan ba ng Miniflux ang SQLite?

Hindi. Ayon sa documentation ng project, "works only with PostgreSQL" ito, at gumagamit ang full text search ng mga feature ng PostgreSQL, kaya walang mas magaan na mode na maaaring paglipatan. Kung gusto mo ng feed reader na walang database container, patakbuhin ang FreshRSS gamit ang default nitong SQLite backend o ang yarr gamit ang embedded file.