VPS కోసం ఉత్తమమైన self-hosted RSS readers ఏవి?

చిన్న VPS కోసం ఏ self-hosted RSS reader సరిపోతుంది

చిన్న VPS లో ఇన్‌స్టాల్ చేయడానికి Miniflux ఒక ఉత్తమమైన self-hosted RSS reader. ఇది PostgreSQL తో పాటు ఒకే ఒక Go binary గా పనిచేస్తుంది. ఇది Fever మరియు Google Reader API లను సపోర్ట్ చేస్తుంది, కాబట్టి థర్డ్-పార్టీ ఫోన్ యాప్‌లు దీనికి కనెక్ట్ అవ్వగలవు, మరియు అప్‌గ్రేడ్ చేయడం అనేది కేవలం ఒక docker compose pull మాత్రమే. మీకు extensions కావాలన్నా లేదా SQLite తో కూడిన ఒకే container సరిపోతుందనుకున్నా FreshRSS ను ఎంచుకోండి.

VPS లో డిస్క్ స్థలాన్ని కేటాయించదగ్గ ఐదు RSS readers ఇవి: Miniflux, FreshRSS, CommaFeed, yarr మరియు Tiny Tiny RSS. ఈ పేజీ వాటి మధ్య ఉన్న అసలైన వ్యత్యాసాలను పోలుస్తుంది: ప్రతి stack కు అవసరమైన మెమరీ, అవి తప్పనిసరి చేసే డేటాబేస్, మీ ఫోన్ యాప్‌కు అవసరమైన sync API, మరియు అప్‌గ్రేడ్ చేసేటప్పుడు ఏమి జరుగుతుంది అనే విషయాలను వివరిస్తుంది. ఇక్కడ ఉన్న ప్రతి సంఖ్య ప్రాజెక్ట్ ద్వారా ప్రచురించబడినది లేదా సాధారణ గణితం ద్వారా లెక్కించబడినది, ఏది దేనికో టెక్స్ట్‌లో పేర్కొనబడింది. ఇది మీ హార్డ్‌వేర్ యొక్క బెంచ్‌మార్క్ కాదు, కాబట్టి మీ సొంత సర్వర్‌ను docker stats తో పరీక్షించుకోండి.

ఐదు రీడర్లు, ఒక్కో పేరా

Miniflux Go భాషలో వ్రాయబడింది మరియు ఒకే statically compiled binary గా విడుదలవుతుంది. దీని డాక్యుమెంటేషన్ ఒకే ఒక కఠినమైన డిపెండెన్సీ గురించి స్పష్టంగా చెబుతుంది: ఇది "PostgreSQL తో మాత్రమే పనిచేస్తుంది". ఇందులో SQLite మోడ్ లేదు. ఇది REST API, Fever అనుకూల API మరియు Google Reader అనుకూల APIని అందిస్తుంది, అలాగే OPML ఇంపోర్ట్ మరియు ఎక్స్‌పోర్ట్ సౌకర్యం కూడా ఉంది. పూర్తి టెక్స్ట్ సెర్చ్ బాధ్యతను PostgreSQL చూసుకుంటుంది, అందుకే డేటాబేస్ ఐచ్ఛికం కాదు.

FreshRSS PHP భాషలో ఉంటుంది మరియు వెబ్ సర్వర్, అప్లికేషన్ రెండింటినీ కలిపి ఒకే కంటైనర్‌లో నడుపుతుంది. SQLite దీని డిఫాల్ట్ డేటాబేస్ మరియు దీనికి రెండవ సర్వీస్ అవసరం లేదు, అయితే పెద్ద ఇన్‌స్టాలేషన్‌ల కోసం PostgreSQL మరియు MySQL లకు మద్దతు ఉంది. ఇది Google Reader API మరియు Fever API లతో పనిచేస్తుంది. దీని ఇన్‌స్టాలేషన్ గురించి ఇప్పటికే మా FreshRSS on a VPS walkthrough లో వివరించాము, కాబట్టి ఈ పేజీలో ఇన్‌స్టాలేషన్‌ను మళ్ళీ చెప్పకుండా, ఇతర వాటితో పోల్చడం జరిగింది.

CommaFeed అనేది Quarkus పై నడిచే Java అప్లికేషన్, దీని లేఅవుట్ Google Reader ను పోలి ఉంటుంది. దీని డేటాబేస్ రన్ టైమ్‌లో కాకుండా బిల్డ్ టైమ్‌లో ఎంచుకోవాలి, కాబట్టి ప్రాజెక్ట్ ప్రతి డేటాబేస్ కోసం ఒక ఇమేజ్‌ను విడుదల చేస్తుంది: athou/commafeed:latest-h2 అనేది ఎంబెడెడ్ H2 డేటాబేస్ కోసం, athou/commafeed:latest-postgresql అనేది PostgreSQL కోసం, మరియు MySQL, MariaDB ల కోసం మరిన్ని వేరియంట్లు ఉన్నాయి. ఇది REST API మరియు Fever అనుకూల APIని అందిస్తుంది.

yarr (yet another rss reader) అనేది SQLite ఎంబెడెడ్ కలిగిన ఒకే Go binary, దీనికి కంటైనర్ అవసరం లేదు. సాధారణ ./yarr అనేది 127.0.0.1:7070 పోర్ట్‌లో వింటుంది. దీని ఫ్లాగ్‌లు చిన్నవిగా ఉంటాయి: -addr 0.0.0.0:7070 -auth alice:secret ద్వారా పాస్‌వర్డ్ రక్షణతో నెట్‌వర్క్‌కు అందుబాటులోకి వస్తుంది, మరియు -db /data/yarr.db ద్వారా డేటాబేస్‌ను మీకు కావలసిన చోట ఉంచుకోవచ్చు. ఇది Fever అనుకూల APIని కలిగి ఉంది. దీని తాజా ట్యాగ్ చేయబడిన విడుదల v2.8, ఇది జూలై 2024 నాటిది, ఆగస్టు 2026లో తనిఖీ చేయబడింది, కాబట్టి దీనిని చురుకుగా అభివృద్ధి చెందుతున్న సాఫ్ట్‌వేర్‌గా కాకుండా, పూర్తయిన సాఫ్ట్‌వేర్‌గా పరిగణించండి.

Tiny Tiny RSS ఈ ఐదింటిలో అత్యంత పాతది మరియు నడపడానికి అత్యంత భారమైనది. దీని అధికారిక Docker సెటప్‌లో నాలుగు సర్వీసులు ఉంటాయి: ఒక PostgreSQL కంటైనర్, ఒక PHP-FPM అప్లికేషన్ కంటైనర్, ఫీడ్‌లను సేకరించే ప్రత్యేక అప్‌డేటర్ కంటైనర్, మరియు ముందు భాగంలో ఒక nginx కంటైనర్. "ఈ సెటప్ PostgreSQL ని ఉపయోగిస్తుంది" అని డాక్యుమెంటేషన్ స్పష్టంగా పేర్కొంది. దీనికి సొంత JSON API ఉంది, దీనిని దీని Android క్లయింట్ మరియు అనేక థర్డ్-పార్టీ యాప్‌లు ఉపయోగిస్తాయి. ఇందులో Fever భాగం లేదు.

ప్రతి stack కు ఎంత memory అవసరం

కింద ఉన్న గణాంకాలు అంచనాలు మాత్రమే, కొలతలు కావు: చిన్న VPS లో ప్రతి stack ఉండాల్సిన గరిష్ట memory పరిమితి ఇవి. CommaFeed కి సంబంధించిన సంఖ్య ఆ ప్రాజెక్ట్ స్వయంగా ప్రచురించిన ఉదాహరణ, ఇది container ను 256 MB కి పరిమితం చేస్తుంది. మిగిలినవి feed fetcher కోసం కొంత అదనపు స్థలాన్ని వదిలిపెట్టే పరిమితులు; ఎందుకంటే refresh cycle ప్రారంభమైనప్పుడు ఆ భాగమే ఎక్కువ memory ని వినియోగిస్తుంది.

[
  {
    "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 MB వద్ద ఉంటుంది, ఎందుకంటే ఇది ఒకే binary మరియు ఒకే SQLite ఫైల్, దీనికి ప్రత్యేక database server లేదా language runtime అవసరం లేదు. Miniflux కి 2 containers లో కలిపి 320 MB అవసరం, ఇందులో ఎక్కువ భాగం Miniflux కంటే PostgreSQL కే కేటాయించబడుతుంది. Tiny Tiny RSS 4 containers లో 640 MB తో భిన్నంగా ఉంటుంది, ఎందుకంటే అప్లికేషన్, updater, database మరియు web server అనేవి నాలుగు వేర్వేరు heaps కలిగిన నాలుగు విభిన్న processes.

వీటిని కేవలం ఆశలుగా కాకుండా వాస్తవ పరిమితులుగా సెట్ చేయండి. Docker Compose లో memory పరిమితులు అనే విభాగం దీనికి సంబంధించిన syntax ను మరియు ఒక container ఆ పరిమితిని చేరుకున్నప్పుడు ఏమి జరుగుతుందో వివరిస్తుంది. పరిమితి లేని container, memory నిండిన సర్వర్‌లో సరిగ్గా స్పందించదు: kernel ఒక process ను బాధితుడిగా ఎంచుకుని దాన్ని kill చేస్తుంది, ఆ బాధితుడు తరచుగా ఒత్తిడికి కారణమైన container కాకపోవచ్చు.

ప్రతి రీడర్ మీకు ఏ డేటాబేస్‌ను తప్పనిసరి చేస్తుందో

ఈ ఐదింటి మధ్య ఉన్న అతిపెద్ద కార్యాచరణ వ్యత్యాసం డేటాబేస్. యూజర్ ఇంటర్‌ఫేస్‌లో ఉండే తేడాల కంటే ఇది చాలా ముఖ్యమైన నిర్ణయం, ఎందుకంటే ఇది మీ బ్యాకప్ విధానాన్ని మరియు అప్‌గ్రేడ్ రిస్క్‌ను నిర్ణయిస్తుంది.

Miniflux మరియు అధికారిక Tiny Tiny RSS సెటప్‌లకు PostgreSQL అవసరం. ఇది నిజమైన ఫుల్ టెక్స్ట్ సెర్చ్ మరియు సురక్షితమైన కాంకరెంట్ రైట్స్‌ను అందిస్తుంది. దీని కోసం అదనంగా ఒక కంటైనర్, ఒక వాల్యూమ్ మరియు ఒక పునరావృత సమస్యను ఎదుర్కోవాల్సి ఉంటుంది: అధికారిక PostgreSQL ఇమేజ్‌లు మేజర్ వెర్షన్ల మధ్య డేటాను నేరుగా మైగ్రేట్ చేయలేవు. Tiny Tiny RSS డాక్యుమెంటేషన్ దీనిని నేరుగా పేర్కొంటూ, "అధికారిక PostgreSQL కంటైనర్‌లకు మేజర్ వెర్షన్ల మధ్య డేటాను మైగ్రేట్ చేయడానికి మద్దతు లేదు" అని హెచ్చరిస్తుంది. మీ ముందున్న వాస్తవిక మార్గాలు: పాత మేజర్ వెర్షన్‌ను అలాగే ఉంచడం లేదా pg_dump మరియు pg_restore ఉపయోగించి డేటాను డంప్ చేసి రీస్టోర్ చేయడం. దీని కోసం ప్రతి ఒకటి లేదా రెండు సంవత్సరాలకు ఒకసారి ప్రణాళిక సిద్ధం చేసుకోండి.

FreshRSS మరియు yarr డిఫాల్ట్‌గా SQLiteను ఉపయోగిస్తాయి. ఇది ఒకే ఫైల్, సర్వర్ అవసరం లేదు, పోర్ట్ అవసరం లేదు, పాస్‌వర్డ్ అవసరం లేదు. వందల కొద్దీ ఫీడ్లు ఉన్న ఒక వ్యక్తికి ఇది బాగా పనిచేస్తుంది, కానీ ఒకే సమయంలో ఎక్కువ మంది వినియోగదారులు డేటాను రాసేటప్పుడు ఇది నెమ్మదిస్తుంది; అప్పుడే FreshRSS యొక్క PostgreSQL ఆప్షన్ ఉపయోగకరంగా మారుతుంది. yarr తన v2.7 వెర్షన్‌లో ఐచ్ఛికంగా PostgreSQL మద్దతును జోడించింది, కానీ ఎంబెడెడ్ ఫైల్ వాడటమే సాధారణ పద్ధతి.

CommaFeed డిఫాల్ట్‌గా H2ను ఉపయోగిస్తుంది, దీని గురించి మీరు ప్రారంభించే ముందే ఆలోచించాలి, ఎందుకంటే ఇమేజ్ బిల్డ్ అయినప్పుడే CommaFeed తన డేటాబేస్‌ను ఎంచుకుంటుంది. తర్వాత H2 నుండి PostgreSQLకి మారడం అనేది కేవలం కాన్ఫిగరేషన్ మార్పు కాదు. ఇది వేరే ఇమేజ్ మరియు మీరు స్వయంగా నిర్వహించాల్సిన డేటా మైగ్రేషన్, కాబట్టి మీ రీడింగ్ హిస్టరీ ఒక సంవత్సరం పాటు పేరుకుపోకముందే నిర్ణయం తీసుకోండి.

మీ ఫోన్ యాప్ పనిచేస్తుందా

ఈ ప్రశ్న ప్రజలు ఊహించిన దానికంటే ఎక్కువ ప్రభావాన్ని చూపుతుంది, ఎందుకంటే ఫీడ్ రీడర్‌ను ఉపయోగించే విధానంలో వెబ్ ఇంటర్‌ఫేస్ సగం మాత్రమే.

Miniflux అనేది Fever అనుకూల API మరియు Google Reader అనుకూల API రెండింటినీ కలిగి ఉంటుంది, కాబట్టి చాలా iOS మరియు Android క్లయింట్లు దీనికి కనెక్ట్ అవుతాయి. FreshRSS కూడా ఈ రెండు APIలను కలిగి ఉంది, మరియు దాని డాక్యుమెంటేషన్ వీటిని ఇలా వర్గీకరిస్తుంది: Google Reader API పూర్తి ఫీచర్ మద్దతుతో "ఉత్తమమైనది"గా ఉంటుంది, అయితే Fever API "పరిమిత ఫీచర్లు మరియు తక్కువ సామర్థ్యం" కలిగిన ప్రవర్తనను కలిగి ఉంటుంది. ఏదైనా యాప్ లాగిన్ అవ్వడానికి ముందు FreshRSS లో రెండు దశలు పూర్తి చేయాలి. Authentication కింద "Allow API access (required for mobile apps)" ను ఎనేబుల్ చేయండి, ఆపై యూజర్ ప్రొఫైల్‌లో API పాస్‌వర్డ్‌ను సృష్టించండి. API పాస్‌వర్డ్‌ను సెట్ చేయకపోతే, వెబ్ లాగిన్ పనిచేస్తున్నప్పటికీ యాప్‌లో అథెంటికేషన్ ఫెయిల్యూర్ వస్తుంది, ఇది ఎక్కడ తనిఖీ చేయాలో తెలిసే వరకు గందరగోళంగా ఉంటుంది.

CommaFeed మరియు yarr రెండూ Fever అనుకూల APIని మాత్రమే అందిస్తాయి, కాబట్టి అవి Fever కు మద్దతు ఇచ్చే క్లయింట్లతో మాత్రమే పనిచేస్తాయి, కేవలం Google Reader APIని మాత్రమే ఉపయోగించే యాప్‌లతో పనిచేయవు. Tiny Tiny RSS సొంత APIని కలిగి ఉంటుంది, అంటే మీరు దాని కోసం ప్రత్యేకంగా రూపొందించిన క్లయింట్‌ను ఉపయోగించాలి. మీరు 300 ఫీడ్‌లను ఇంపోర్ట్ చేసే ముందు, మీకు నచ్చిన యాప్ ఈ రీడర్‌కు మద్దతు ఇస్తుందో లేదో తనిఖీ చేయండి.

1 GB బాక్స్ కోసం పని చేసే compose ఫైల్

ఇది Miniflux స్టాక్, ఆగస్టు 2026 నాటికి ప్రాజెక్ట్ యొక్క స్వంత Docker ఉదాహరణ నుండి స్వీకరించబడింది. ప్రచురించబడిన పోర్ట్ loopback కు బంధించబడింది, listen అడ్రస్ స్పష్టంగా సెట్ చేయబడింది మరియు రెండు కంటైనర్లు మెమరీ పరిమితిని కలిగి ఉన్నాయి.

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 మొదటిసారి ప్రారంభమైనప్పుడు దాని schema migrations ను లాగ్ చేస్తుంది, దీన్నే RUN_MIGRATIONS=1 ట్రిగ్గర్ చేస్తుంది. docker stats --no-stream లైవ్ మెమరీ కాలమ్‌ను ప్రింట్ చేస్తుంది, పైన ఉన్న చార్ట్‌లోని పరిమితులతో పోల్చడానికి ఇదే సంఖ్యను ఉపయోగించాలి. Miniflux కంటైనర్ లూప్‌లో రీస్టార్ట్ అవుతుంటే, దాని లాగ్‌ను చదవండి: connect: connection refused అంటే PostgreSQL కనెక్షన్‌లను స్వీకరించడానికి సిద్ధంగా లేకముందే అది ప్రారంభమైందని అర్థం, దీన్నే service_healthy కండిషన్ నివారిస్తుంది, కాబట్టి ఆ కండిషన్ మీ ఎడిటింగ్ తర్వాత కూడా అలాగే ఉందో లేదో తనిఖీ చేయండి. ఒకవేళ మీకు Compose కొత్త అయితే, Docker Compose basics on a VPS ముందుగా ఫైల్ లేఅవుట్‌ను వివరిస్తుంది.

1 GB బాక్స్‌లో సరిపోనివి

Tiny Tiny RSS ను వదిలేయడం మంచిది. దీని అధికారిక నాలుగు సర్వీసుల స్టాక్ 1 GB VPS లో అది ఒక్కటే నడుస్తున్నప్పుడు మాత్రమే పనిచేస్తుంది. వేరే డేటాబేస్ ఆధారిత అప్లికేషన్లు లేదా రివర్స్ ప్రాక్సీ ఉన్నప్పుడు ఇది అక్కడ పనిచేయదు. నాలుగు సర్వీసులు అంటే నాలుగు రకాల ఓవర్‌హెడ్, అందులో ఒకటి PostgreSQL.

CommaFeed సరిపోతుంది, కానీ అది H2 ఇమేజ్ మరియు ప్రాజెక్ట్ ఉదాహరణలో పేర్కొన్న 256 MB పరిమితితో మాత్రమే పనిచేస్తుంది. చిన్న బాక్స్‌లో 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 సెట్ చేసినప్పుడు ప్రారంభంలోనే schema migrations వర్తింపజేయబడతాయి. అప్‌గ్రేడ్ వల్ల కలిగే ప్రమాదం Miniflux వల్ల కాదు, దాని కింద ఉన్న PostgreSQL మేజర్ వెర్షన్ వల్ల వస్తుంది.
• FreshRSS: కొత్త image ను pull చేయండి. SQLite తో డేటాబేస్ ఇంజిన్‌ను అప్‌గ్రేడ్ చేయాల్సిన అవసరం లేదు, కాబట్టి సాధారణంగా సమస్యలు అప్‌డేట్ చేయని థర్డ్-పార్టీ ఎక్స్‌టెన్షన్ల వల్ల వస్తాయి.
• CommaFeed: మీ డేటాబేస్‌కు సరిపోయే image variant ను pull చేయండి. latest-h2 నుండి latest-postgresql కి మారడం వల్ల మీ డేటా బదిలీ అవ్వదు.
• yarr: binary ని భర్తీ చేసి, డేటాబేస్ ఫైల్‌ను అలాగే ఉంచండి. జూలై 2024 లో v2.8 తర్వాత ఎటువంటి release లేనందున, ఆగస్టు 2026 నాటికి తనిఖీ చేసినప్పుడు, అప్‌గ్రేడ్ చేయడానికి సాధారణంగా ఏమీ ఉండదు.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Schema migrations స్వయంచాలకంగా రన్ అవుతాయి, మరియు ఏదైనా నిర్ధారణ అవసరమైనప్పుడు interface మిమ్మల్ని migration స్క్రీన్‌కు మళ్ళిస్తుంది.

వీటిలో దేనినైనా చేసే ముందు డేటాబేస్ dump తీసుకోండి, తర్వాత కాదు.

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

రిఫ్రెష్ విరామం వల్ల బ్యాండ్‌విడ్త్ పై పడే భారం

కింద ఉన్న సంఖ్యలు గణితపరమైన అంచనాలు మాత్రమే, కొలతలు కావు. ఇవి 100 ఫీడ్‌లు, ప్రతి విరామానికి ఒక అభ్యర్థన, మరియు ప్రతి ప్రతిస్పందనకు 40 KB పరిమాణాన్ని ప్రాతిపదికగా తీసుకుంటాయి. సర్వర్ conditional requests ను గౌరవించినప్పుడు వాస్తవ ట్రాఫిక్ తక్కువగా ఉంటుంది, ఫీడ్‌లలో పూర్తి వ్యాస పాఠ్యం ఉన్నప్పుడు ఎక్కువగా ఉంటుంది.

[
  {
    "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 నిమిషాలకు సెట్ చేయబడి ఉంటుంది, ఇది ఆ పట్టికలో చివరి వరుస. ఈ డిఫాల్ట్ విలువ దాదాపు అందరికీ సరిపోతుంది. మీరు తరచుగా అడిగినంత మాత్రాన ఒక వ్యాసం త్వరగా రాదు.

గణితపరమైన అంచనాల కంటే వాస్తవ సంఖ్య తక్కువగా ఉండటానికి కారణం conditional requests. ఒక ఫీడ్ తిరిగి పంపిన ETag మరియు Last-Modified హెడర్‌లను నిల్వ ఉంచుకునే రీడర్, వాటిని If-None-Match మరియు If-Modified-Since గా తిరిగి పంపుతుంది. కొత్త సమాచారం లేని సర్వర్ 304 Not Modified అని సమాధానమిస్తుంది, దీనికి బాడీ ఉండదు. ఈ కనెక్షన్‌కు హ్యాండ్‌షేక్ ఖర్చు ఉంటుంది కానీ పేలోడ్ ఖర్చు ఉండదు. conditional requests ను పట్టించుకోని ఫీడ్‌లు ప్రతిసారీ పూర్తి డాక్యుమెంట్‌ను పంపిస్తాయి, కాబట్టి కొన్ని పెద్ద ఫీడ్‌లు మీ ట్రాన్స్‌ఫర్ బిల్లును పెంచే అవకాశం ఉంది.

అతిగా పోలింగ్ చేయడం వల్ల మీరు బ్లాక్ అయ్యే ప్రమాదం కూడా ఉంది. మీరు సర్వర్‌ను ఇబ్బంది పెడుతున్నారని భావిస్తే, అది 429 Too Many Requests అని సమాధానమిస్తుంది, కొన్ని సైట్లు 403 అని కూడా పంపవచ్చు. Miniflux ఆ చివరి ఎర్రర్‌ను ఫీడ్ వివరాల్లోనే నమోదు చేస్తుంది, కాబట్టి మిగిలిన ఫీడ్‌లు పనిచేస్తూ ఒక ఫీడ్ మాత్రమే అప్‌డేట్ కాకపోతే, ఫీడ్ జాబితాను ముందుగా తనిఖీ చేయాలి.

ఫీడ్లు పనిచేయవు, మరియు OPML ఫైల్ బ్యాకప్ కాదు

మీరు ఊహించిన దానికంటే వేగంగా ఫీడ్లు పాడవుతాయి. డొమైన్‌లు గడువు ముగియడం, సైట్లు ఫీడ్ లేని ప్లాట్‌ఫారమ్‌లకు మారడం జరుగుతుంది. ఒకప్పుడు XML అందించిన URL, ఇప్పుడు 200 OK స్టేటస్‌తో HTML ఎర్రర్ పేజీని చూపించవచ్చు. చివరి సందర్భం చాలా ఇబ్బందికరమైనది: ఫెచ్ (fetch) విజయవంతమవుతుంది, కానీ పార్సింగ్ (parse) విఫలమవుతుంది. అప్పుడు మీ రీడర్ నెట్‌వర్క్ ఎర్రర్‌కు బదులుగా పార్సింగ్ ఎర్రర్‌ను నమోదు చేస్తుంది. సంవత్సరానికి ఒకసారి, ఫీడ్ జాబితాను చివరిగా అప్‌డేట్ చేసిన సమయం ఆధారంగా క్రమబద్ధీకరించి, నిశ్శబ్దంగా ఉన్నవాటిని తొలగించండి.

OPML ఎగుమతి అనేది మీ సబ్‌స్క్రిప్షన్ జాబితా మాత్రమే. ఇది ఫీడ్ URLలు మరియు ఫోల్డర్ పేర్లను కలిగి ఉంటుంది. ఇది చదివిన స్థితి (read state), స్టార్ చేసిన ఆర్టికల్స్, ఫీడ్-వారీ సెట్టింగ్‌లు, ఫిల్టర్ నియమాలు లేదా మీరు సేవ్ చేసిన ఆర్టికల్ టెక్స్ట్‌ను కలిగి ఉండదు. ఆ OPMLని కొత్త ఇన్‌స్టాలేషన్‌లో ఇంపోర్ట్ చేస్తే, మీ ఫీడ్లు తిరిగి వస్తాయి కానీ మీరు చదివిన ప్రతి ఆర్టికల్ మళ్ళీ 'unread'గా కనిపిస్తుంది.

నిజమైన బ్యాకప్ అంటే డేటాబేస్. PostgreSQL కోసం, పైన పేర్కొన్న pg_dump కమాండ్ మొత్తం పనిని పూర్తి చేస్తుంది. FreshRSS లేదా yarr వంటి SQLite రీడర్ల కోసం, రైటర్‌ను ఆపివేసి ఫైల్‌ను కాపీ చేయండి, లేదా sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" ఉపయోగించి అది రన్ అవుతున్నప్పుడు స్థిరమైన కాపీని తీసుకోండి. డేటాబేస్ వ్రాయబడుతున్నప్పుడు సాధారణ cp చేయడం వల్ల, ఆ ఫైల్ తర్వాత తెరవబడకపోవచ్చు, ఎందుకంటే ఆ కాపీ సగం పూర్తయిన రైట్‌ను క్యాప్చర్ చేస్తుంది. ఆ ఫైళ్లను షెడ్యూల్ ప్రకారం సర్వర్ నుండి బయటకు పంపండి, దీని కోసమే restic backups on a VPS ఉపయోగపడతాయి. ప్రక్రియ పనిచేస్తుందో లేదో తెలుసుకోవడానికి కనీసం ఒక్కసారైనా ఒక స్క్రాచ్ కంటైనర్‌లో రీస్టోర్ చేసి చూడండి.

ఫీడ్ రీడర్ అనేది మీరు సొంతంగా నడుపుకోగలిగే అత్యంత చౌకైన సేవల్లో ఒకటి, అందుకే ఇది things worth self-hosting in 2026 జాబితాలో ఉంటుంది. దీని పక్కనే a self-hosted SearXNG instance ను ఏర్పాటు చేయండి, తద్వారా మీ రీడింగ్ మరియు సెర్చింగ్ రెండూ మీరు నియంత్రించే హార్డ్‌వేర్‌లోనే ఉంటాయి.

FAQ

ఏ self-hosted RSS reader తక్కువ మెమరీని ఉపయోగిస్తుంది?

yarr. ఇది SQLite తో కలిపి కంపైల్ చేయబడిన ఒకే ఒక Go binary, కాబట్టి దీనికి ప్రత్యేక డేటాబేస్ సర్వర్ లేదా ఇతర లాంగ్వేజ్ రన్‌టైమ్ అవసరం లేదు. దీనికి 128 MB మెమరీ సరిపోతుంది. అయితే దీనివల్ల ఫీచర్లు మరియు మెయింటెనెన్స్‌లో పరిమితులు ఉంటాయి: దీని తాజా వెర్షన్ జూలై 2024 నాటి v2.8 మాత్రమే, మరియు ఇది కేవలం Fever API కి మాత్రమే మద్దతు ఇస్తుంది. ఇదే పరిమాణంలో చురుకైన డెవలప్‌మెంట్ ఉన్న ప్రాజెక్ట్ కావాలంటే, 320 MB మెమరీతో నడిచే Miniflux మరియు PostgreSQL ఉత్తమమైన ఎంపిక.

నేను 1 GB VPS లో self-hosted RSS reader ను రన్ చేయగలనా?

అవును. మీరు రెండు కంటైనర్లపై mem_limit సెట్ చేసినప్పుడు, Miniflux మరియు PostgreSQL సుమారు 320 MB లోపు సరిపోతాయి. అలాగే FreshRSS ను SQLite తో ఒకే కంటైనర్‌లో రన్ చేయవచ్చు. 1 GB VPS లో అధికారిక Tiny Tiny RSS stack ను వాడకండి, ఎందుకంటే ఇది దాని స్వంత PostgreSQL తో కలిపి మొత్తం 4 సర్వీసులను కలిగి ఉంటుంది. ఎల్లప్పుడూ మెమరీ పరిమితులను (memory limits) సెట్ చేయండి, ఎందుకంటే పరిమితి లేని కంటైనర్ మెమరీ నిండినప్పుడు, kernel ఏదో ఒక ప్రాసెస్‌ను kill చేస్తుంది. తరచుగా అప్లికేషన్ కంటే డేటాబేస్ ప్రాసెస్ kill అయ్యే అవకాశం ఉంది.

వీటిలో ఏవి iOS మరియు Android RSS యాప్‌లతో పనిచేస్తాయి?

Miniflux మరియు FreshRSS రెండూ Fever API మరియు Google Reader API లకు మద్దతు ఇస్తాయి, కాబట్టి దాదాపు ఏ మొబైల్ క్లయింట్ అయినా వీటితో కనెక్ట్ అవుతుంది. CommaFeed మరియు yarr కేవలం Fever API ని మాత్రమే అందిస్తాయి. Tiny Tiny RSS దాని స్వంత API ని ఉపయోగిస్తుంది, కాబట్టి మీరు దాని కోసం ప్రత్యేకంగా రూపొందించిన క్లయింట్‌ను వాడాలి. FreshRSS లో మీరు Authentication సెట్టింగ్స్‌లో API యాక్సెస్‌ను ఎనేబుల్ చేసి, ప్రొఫైల్‌లో ప్రత్యేకమైన API పాస్‌వర్డ్‌ను సెట్ చేయాలి; లేకపోతే వెబ్‌సైట్ పనిచేసినప్పటికీ, యాప్ లాగిన్ అవ్వదు.

OPML ఎగుమతి (export) నా RSS reader కి బ్యాకప్ అవుతుందా?

కాదు. OPML కేవలం ఫీడ్ URLలు మరియు ఫోల్డర్లను మాత్రమే కలిగి ఉంటుంది, కాబట్టి ఇది మీ సబ్‌స్క్రిప్షన్ జాబితాను మాత్రమే పునరుద్ధరించగలదు. చదివిన స్థితి (read state), స్టార్ చేసిన అంశాలు, ఫిల్టర్ నియమాలు మరియు ఆర్టికల్ టెక్స్ట్ అన్నీ డేటాబేస్‌లోనే ఉంటాయి. PostgreSQL కోసం pg_dump తో లేదా SQLite కోసం .backup కమాండ్‌తో డేటాబేస్‌ను బ్యాకప్ చేసి, ఆ ఫైల్‌ను సర్వర్ నుండి బయటకు కాపీ చేసుకోండి.

Miniflux కి SQLite మద్దతు ఉందా?

లేదు. ఈ ప్రాజెక్ట్ డాక్యుమెంటేషన్ ప్రకారం ఇది "కేవలం PostgreSQL తో మాత్రమే పనిచేస్తుంది". ఫుల్ టెక్స్ట్ సెర్చ్ ఫీచర్ కూడా PostgreSQL ఫీచర్ల ద్వారానే అమలు చేయబడింది, కాబట్టి దీనికి తేలికపాటి మోడ్ లేదు. మీకు డేటాబేస్ కంటైనర్ అవసరం లేని ఫీడ్ రీడర్ కావాలంటే, FreshRSS ను దాని డిఫాల్ట్ SQLite బ్యాకెండ్‌తో లేదా yarr ను దాని ఎంబెడెడ్ ఫైల్‌తో రన్ చేయండి.