VPS साठी सर्वोत्तम self-hosted RSS reader कोणता?

लहान VPS साठी कोणता self-hosted RSS reader योग्य आहे

लहान VPS वर चालवण्यासाठी Miniflux हा सर्वोत्तम self-hosted RSS reader आहे. हे PostgreSQL सोबत चालणारे एकच Go binary आहे. हे Fever आणि Google Reader API ला सपोर्ट करते, त्यामुळे थर्ड-पार्टी फोन अॅप्स याला सहज जोडता येतात आणि अपग्रेड करण्यासाठी फक्त एक docker compose pull कमांड लागते. जर तुम्हाला extensions हवे असतील आणि SQLite वापरणारा एकच कंटेनर हवा असेल, तर FreshRSS निवडा.

VPS वर ठेवण्यायोग्य पाच RSS readers खालीलप्रमाणे आहेत: Miniflux, FreshRSS, CommaFeed, yarr आणि Tiny Tiny RSS. हे पान त्यांच्यातील मुख्य फरकांची तुलना करते: प्रत्येक stack ला लागणारी मेमरी, प्रत्येक reader साठी आवश्यक असलेला डेटाबेस, तुमच्या फोन अॅपला लागणारे sync API आणि अपग्रेडच्या दिवशी काय करावे लागते याची माहिती. येथे दिलेली प्रत्येक आकडेवारी एकतर प्रोजेक्टद्वारे प्रकाशित केलेली आहे किंवा साध्या गणितावर आधारित आहे, आणि मजकुरात तसा उल्लेख केला आहे. यातील कोणतीही माहिती तुमच्या हार्डवेअरची बेंचमार्क नाही, त्यामुळे तुमच्या स्वतःच्या सर्व्हरवर docker stats वापरून मोजमाप करा.

पाच वाचक, प्रत्येकी एक परिच्छेद

Miniflux हे Go मध्ये लिहिलेले असून ते एकच statically compiled binary म्हणून उपलब्ध आहे. त्याच्या दस्तऐवजीकरणामध्ये एका अनिवार्य dependency बद्दल स्पष्टपणे नमूद केले आहे: ते "केवळ PostgreSQL सोबतच काम करते". यामध्ये SQLite मोड उपलब्ध नाही. हे एक REST API, Fever सुसंगत API आणि Google Reader सुसंगत API ऑफर करते, तसेच OPML import आणि export ची सुविधाही देते. पूर्ण मजकूर शोधण्याची (full text search) जबाबदारी PostgreSQL कडे असते, म्हणूनच डेटाबेस ऐच्छिक नाही.

FreshRSS हे PHP मध्ये असून ते वेब सर्व्हर आणि ॲप्लिकेशन दोन्ही सामावून घेणाऱ्या एकाच कंटेनरमध्ये चालते. SQLite हा डीफॉल्ट डेटाबेस असून त्यासाठी दुसऱ्या सेवेची गरज नसते, तर मोठ्या इन्स्टॉलेशन्ससाठी PostgreSQL आणि MySQL ला सपोर्ट दिला जातो. हे Google Reader API आणि Fever API ला सपोर्ट करते. हे कसे इन्स्टॉल करायचे हे आमच्या FreshRSS ऑन VPS वॉकथ्रू मध्ये आधीच कव्हर केले आहे, त्यामुळे हे पान पुन्हा इन्स्टॉलेशन न सांगता तुलना करते.

CommaFeed हे Quarkus वरील Java आधारित असून त्याची मांडणी Google Reader ची प्रतिकृती आहे. याचा डेटाबेस रन-टाइमला नाही तर बिल्ड-टाइमला निवडला जातो, त्यामुळे हा प्रकल्प प्रति डेटाबेस एक इमेज प्रकाशित करतो: athou/commafeed:latest-h2 हे एम्बेडेड H2 डेटाबेससाठी, athou/commafeed:latest-postgresql हे PostgreSQL साठी, आणि MySQL व MariaDB साठी इतर प्रकार. हे टॅग्स natively compiled बिल्ड्स आहेत आणि -jvm हा प्रत्यय JVM वर चालणाऱ्या प्रकारांना दर्शवतो. हे एक REST API आणि Fever सुसंगत API उघड करते, आणि 7.3.0 (ऑगस्ट 2026) आवृत्तीपासून Google Reader सुसंगत 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.9 आहे, जी सप्टेंबर 2026 मधील असून ऑक्टोबर 2026 मध्ये तपासली गेली आहे; याआधी जूनमध्ये v2.7 आणि जुलैमध्ये v2.8 आली होती, त्यामुळे यावर पुन्हा सक्रियपणे काम सुरू आहे.

Tiny Tiny RSS हे या पाचपैकी सर्वात जुने आणि चालवण्यासाठी सर्वात जड आहे. tt-rss.org वरील मूळ प्रकल्प 1 नोव्हेंबर 2025 रोजी बंद करण्यात आला आणि विकास आता github.com/tt-rss/tt-rss वरील कम्युनिटी फोर्कमध्ये सुरू आहे, ज्याचे दस्तऐवजीकरण आता अधिकृत सेटअप मानले जाते. या सेटअपमध्ये चार सेवा आहेत: एक PostgreSQL कंटेनर, एक PHP-FPM ॲप्लिकेशन कंटेनर, फीड्स मिळवणारा एक स्वतंत्र अपडेटर कंटेनर आणि समोर एक nginx कंटेनर. दस्तऐवजीकरण स्पष्टपणे सांगते की "हा सेटअप PostgreSQL वापरतो". याचे स्वतःचे JSON API आहे, ज्याचा वापर त्याचे Android क्लायंट आणि अनेक थर्ड-पार्टी ॲप्स करतात. Fever चा यात समावेश नाही.

प्रत्येक स्टॅकसाठी आवश्यक मेमरी

खालील आकडे हे अंदाज आहेत, मोजमापे नाहीत: एका लहान VPS वर प्रत्येक स्टॅकने ज्या मेमरी मर्यादेत राहणे अपेक्षित आहे, ती ही मर्यादा आहे. CommaFeed साठी दिलेला आकडा हा प्रकल्पाने स्वतः प्रसिद्ध केलेले उदाहरण आहे, जे कंटेनरला 256 MB वर मर्यादित करते. इतर आकडे अशा मर्यादा आहेत ज्या फीड फेचरसाठी (feed fetcher) पुरेशी जागा ठेवतात, कारण रिफ्रेश सायकल सुरू झाल्यावर याच भागाचा मेमरी वापर अचानक वाढतो.

[
  {
    "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 इतका आहे, कारण हे एकच बायनरी आणि एक SQLite फाईल आहे, ज्याच्या मागे कोणताही डेटाबेस सर्व्हर किंवा लँग्वेज रनटाइम नाही. Miniflux ला 2 कंटेनर्समध्ये 320 MB ची गरज असते आणि त्यातील बहुतांश मेमरी Miniflux ऐवजी PostgreSQL वापरते. Tiny Tiny RSS हे 4 कंटेनर्समध्ये 640 MB सह अपवाद ठरते, कारण ॲप्लिकेशन, अपडेटर, डेटाबेस आणि वेब सर्व्हर हे चार स्वतंत्र प्रोसेस असून त्यांचे चार स्वतंत्र हीप्स (heaps) असतात.

या मर्यादा केवळ अपेक्षा म्हणून न ठेवता प्रत्यक्ष मर्यादा (limits) म्हणून सेट करा. Docker Compose मधील मेमरी मर्यादा या विषयामध्ये सिंटॅक्स आणि कंटेनर मर्यादेपर्यंत पोहोचल्यावर काय करतो, याची माहिती दिली आहे. पूर्ण भरलेल्या सर्व्हरवर कोणतीही मर्यादा नसलेला कंटेनर व्यवस्थित बंद पडत नाही: कर्नल एक प्रोसेस निवडते आणि तिला बंद (kill) करते, आणि बऱ्याचदा ती प्रोसेस मेमरीचा ताण निर्माण करणारा कंटेनर नसते.

प्रत्येक रीडर तुमच्यावर कोणता डेटाबेस लादतो

या पाचही रीडर्समधील सर्वात मोठा कार्यात्मक फरक म्हणजे त्यांचा डेटाबेस. वापरकर्ता इंटरफेसच्या फरकांपेक्षा हा निर्णय अधिक महत्त्वाचा आहे, कारण यावरच तुमची बॅकअप प्रक्रिया आणि अपग्रेडचा धोका अवलंबून असतो.

Miniflux आणि अधिकृत Tiny Tiny RSS सेटअपसाठी PostgreSQL आवश्यक आहे. यामुळे तुम्हाला उत्तम फुल-टेक्स्ट सर्च आणि सुरक्षित कॉनकरंट राइट्स मिळतात. यासाठी तुम्हाला एक अतिरिक्त कंटेनर आणि एक व्हॉल्यूम वापरावा लागतो, तसेच एक वारंवार उद्भवणारी समस्या म्हणजे: अधिकृत PostgreSQL इमेजेस मेजर व्हर्जन दरम्यान डेटाचे थेट मायग्रेशन करू शकत नाहीत. Tiny Tiny RSS च्या डॉक्युमेंटेशनमध्ये हे स्पष्टपणे नमूद केले आहे आणि इशारा दिला आहे की "अधिकृत PostgreSQL कंटेनर्समध्ये मेजर व्हर्जन दरम्यान डेटा मायग्रेट करण्यासाठी कोणतीही सपोर्ट सिस्टिम नाही". फीड रीडरसाठी तुमच्याकडे दोनच वास्तववादी पर्याय आहेत: जुन्या मेजर व्हर्जनवरच राहणे, किंवा pg_dump आणि pg_restore वापरून डेटा डंप आणि रिस्टोर करणे. PostgreSQL मध्ये pg_upgrade आणि रेप्लिकेशन-आधारित अपग्रेड्सची सुविधा देखील आहे, जी मोठ्या डेटाबेससाठी उपयुक्त ठरते जिथे डाउनटाइम महत्त्वाचा असतो, परंतु फीड रीडरचा डेटाबेस सहसा इतका मोठा नसतो. दर एक-दोन वर्षांनी यासाठी नियोजन करा.

SQLite हे FreshRSS आणि yarr चे डीफॉल्ट आहे. यात एकच फाईल असते, कोणताही सर्व्हर, पोर्ट किंवा पासवर्डची गरज नसते. काही शे फीड्स असलेल्या एका वापरकर्त्यासाठी हे उत्तम काम करते, परंतु जेव्हा अनेक वापरकर्ते एकाच वेळी डेटा लिहितात तेव्हा याचा वेग मंदावतो; अशा वेळी FreshRSS चा PostgreSQL पर्याय अधिक फायदेशीर ठरतो. yarr ने v2.7 मध्ये PostgreSQL सपोर्ट दिला आहे, परंतु एम्बेडेड फाईल वापरणे हीच ती चालवण्याची सामान्य पद्धत आहे.

H2 हे CommaFeed चे एम्बेडेड डीफॉल्ट आहे. सुरुवात करण्यापूर्वी याचा थोडा विचार करणे आवश्यक आहे, कारण CommaFeed इमेज बिल्ड होतानाच आपला डेटाबेस निवडते. नंतर H2 वरून PostgreSQL वर जाणे म्हणजे केवळ कॉन्फिगरेशन बदलणे नव्हे. यासाठी तुम्हाला वेगळी इमेज वापरावी लागेल आणि स्वतः डेटा मायग्रेशन करावे लागेल, त्यामुळे तुमच्याकडे एक वर्षाचा वाचन इतिहास जमा होण्यापूर्वीच निर्णय घ्या.

तुमचे फोन ॲप काम करेल का

हा प्रश्न लोकांच्या अपेक्षेपेक्षा जास्त महत्त्वाचा आहे, कारण वेब इंटरफेस हा फीड रीडर वापरण्याचा केवळ अर्धा भाग आहे.

Miniflux मध्ये Fever सुसंगत API आणि Google Reader सुसंगत API उपलब्ध आहे, त्यामुळे बहुतेक iOS आणि Android क्लायंट त्याला कनेक्ट होऊ शकतात. FreshRSS मध्येही हे दोन API उपलब्ध आहेत आणि त्यांच्या स्वतःच्या दस्तऐवजीकरणानुसार (documentation) त्यांचे वर्गीकरण केले आहे: Google Reader API हे पूर्ण फिचर सपोर्टसह "सर्वोत्तम" आहे, तर Fever API मध्ये "मर्यादित फिचर्स आणि कमी कार्यक्षम" वर्तन आढळते. कोणत्याही ॲपला लॉग इन करण्यापूर्वी FreshRSS मध्ये दोन पायऱ्या पूर्ण करणे आवश्यक आहे. Authentication अंतर्गत "Allow API access (required for mobile apps)" सक्षम करा आणि त्यानंतर युजर प्रोफाइलमध्ये एक API पासवर्ड तयार करा. API पासवर्ड तयार न केल्यास ॲपमध्ये ऑथेंटिकेशन अयशस्वी (authentication failure) होते, तर वेब लॉग इन सुरूच राहते. हे गोंधळात टाकणारे असू शकते, जोपर्यंत तुम्हाला नेमके कुठे तपासायचे हे माहित नसते.

CommaFeed आता दोन्ही API ला सपोर्ट करते: यामध्ये बऱ्याच काळापासून Fever सुसंगत API होते आणि 7.3.0 आवृत्तीमध्ये अशा ॲप्ससाठी Google Reader सुसंगत API जोडले गेले आहे जे Fever ला सपोर्ट करत नाहीत. त्यामुळे जर तुमचे ॲप फक्त Google Reader ला सपोर्ट करत असेल, तर 7.3.0 किंवा त्यापुढील आवृत्ती वापरा. yarr फक्त Fever सुसंगत API प्रदान करते, त्यामुळे ते फक्त Fever ला सपोर्ट करणाऱ्या क्लायंटसोबत काम करते, Google Reader ला सपोर्ट करणाऱ्या ॲप्ससोबत नाही. Tiny Tiny RSS मध्ये स्वतःचे वेगळे API आहे, ज्याचा अर्थ असा की तुम्हाला त्यासाठी खास बनवलेले क्लायंट वापरावे लागेल. 300 फीड्स इम्पोर्ट करण्यापूर्वी तुमचे पसंतीचे ॲप त्या रीडरला सपोर्ट करते का, याची खात्री करा.

1 GB रॅम असलेल्या सर्व्हरसाठी एक कार्यक्षम compose फाईल

हे Miniflux स्टॅक आहे, जे ऑक्टोबर 2026 पर्यंतच्या प्रकल्पाच्या अधिकृत Docker उदाहरणावरून स्वीकारले आहे. पब्लिश केलेला पोर्ट लूपबॅकवर बाइंड केला आहे, लिसन ॲड्रेस स्पष्टपणे सेट केला आहे आणि दोन्ही कंटेनरवर मेमरी मर्यादा लागू केली आहे.

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 हे अधिकृत इमेजने आधीच Dockerfile मध्ये सेट केलेल्या गोष्टींची पुनरावृत्ती करते, त्यामुळे miniflux/miniflux सह ती दुरुस्ती करण्याऐवजी एक सुरक्षित उपाय ठरते. जेव्हा तुम्ही स्वतःची इमेज तयार करता किंवा पॅकेज केलेली बायनरी चालवता तेव्हा हे महत्त्वाचे ठरते, कारण बायनरीचे डीफॉल्ट 127.0.0.1:8080 असते. कंटेनरच्या आत लूपबॅकवर बाइंड झालेली प्रक्रिया पब्लिश केलेल्या पोर्टद्वारे गाठता येत नाही, त्यामुळे कंटेनर व्यवस्थित दिसत असूनही तुम्हाला '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 GB च्या सर्व्हरवर काय चालणार नाही

Tiny Tiny RSS हे टाळले पाहिजे. त्याचे अधिकृत चार सर्व्हिसेसचे स्टॅक जेव्हा 1 GB च्या VPS वर चालवले जाते, तेव्हा तो सर्व्हर इतर कोणतेही काम करू शकत नाही. तसेच, ते इतर डेटाबेस-आधारित ॲप्लिकेशन आणि रिव्हर्स प्रॉक्सीसोबत चालत नाही. चार सर्व्हिसेस म्हणजे ओव्हरहेडचे चार संच आणि त्यापैकी एक PostgreSQL आहे.

CommaFeed बसू शकते, पण फक्त H2 इमेज आणि प्रोजेक्टच्या उदाहरणात दिलेल्या 256 MB च्या मर्यादेसह. लहान सर्व्हरवर CommaFeed आणि स्वतंत्र डेटाबेस सर्व्हर एकत्र चालवल्यास अडचण येते. -jvm इमेज प्रकार परिस्थिती अधिक बिघडवतात, कारण प्रोजेक्टच्या डॉक्युमेंटेशननुसार JVM डीफॉल्टनुसार मेमरीचा जास्त वापर करते आणि न वापरलेली मेमरी ऑपरेटिंग सिस्टमला परत देत नाही. latest-h2 आणि latest-postgresql टॅग हे नेटिव्ह बिल्ड्स आहेत, जे कमी मेमरी वापरासाठी प्रोजेक्टद्वारे सुचवले जातात. त्यामुळे, 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: बायनरी फाईल बदला आणि डेटाबेस फाईल तशीच ठेवा. जून, जुलै आणि सप्टेंबर 2026 मध्ये नवीन रिलीज आले होते, ऑक्टोबर 2026 पर्यंत v2.9 हे सर्वात नवीन व्हर्जन आहे, त्यामुळे अधूनमधून रिलीज पेज तपासा.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. ॲप्लिकेशन कंटेनर स्टार्टअपच्या वेळी स्वतःला अपडेट करतो. प्रोजेक्टच्या FAQ नुसार, स्कीमा अपडेटमध्ये त्रुटी आल्यास त्याचे कारण खराब झालेले व्हॉल्यूम किंवा ओव्हरराइड सेटअप असू शकते, त्यामुळे त्रुटी आल्यास सर्वप्रथम ते तपासा. जर तुमची compose फाईल अजूनही बंद पडलेल्या tt-rss.org प्रोजेक्टवरून इमेजेस पुल करत असेल, तर ती फोर्कच्या इमेजेसवर (Docker Hub वरील supahgreg/tt-rss किंवा ghcr.io/tt-rss/tt-rss) स्विच करा.

यापैकी कोणतीही प्रक्रिया करण्यापूर्वी डेटाबेसचा डंप घ्या, नंतर घेऊ नका.

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 फाईल हा बॅकअप नाही

फीड्स तुमच्या अपेक्षेपेक्षा लवकर निकामी होतात. डोमेनची मुदत संपते, साइट्स अशा प्लॅटफॉर्मवर स्थलांतरित होतात जिथे फीड उपलब्ध नसते आणि जी URL पूर्वी XML देत असे, ती आता 200 OK स्टेटससह HTML एरर पेज दाखवू लागते. शेवटची स्थिती अधिक त्रासदायक असते: फेच (fetch) यशस्वी होते, पण पार्सिंग (parse) अयशस्वी होते आणि तुमचा रीडर नेटवर्क एररऐवजी पार्सिंग एरर नोंदवतो. वर्षातून एकदा, फीड लिस्टला 'last updated' नुसार सॉर्ट करा आणि जे फीड्स शांत झाले आहेत, ते काढून टाका.

OPML एक्सपोर्ट म्हणजे तुमची सबस्क्रिप्शन लिस्ट असते. एका मानक OPML फाईलमध्ये फीड URLs आणि फोल्डरची नावे असतात. FreshRSS स्वतःचे XML नेमस्पेस जोडते, ज्यामध्ये प्रति-फीड सेटिंग्ज जसे की रिफ्रेश इंटरव्हल, XPath स्क्रॅपिंग सिलेक्टर्स आणि ऑटो-रीड फिल्टर्स असतात. मात्र, कोणत्याही OPML एक्सपोर्टमध्ये वाचलेली स्थिती (read state), स्टार केलेले लेख किंवा तुम्ही जतन केलेला लेखाचा मजकूर नसतो. ती OPML फाईल नवीन इन्स्टॉलेशनमध्ये इम्पोर्ट केल्यास तुम्हाला फीड्स परत मिळतात, पण तुम्ही वाचलेले सर्व लेख पुन्हा 'unread' म्हणून दिसतात.

महत्त्वाचा बॅकअप म्हणजे डेटाबेस. PostgreSQL साठी, वरील pg_dump कमांड हेच पूर्ण काम करते. FreshRSS किंवा yarr सारख्या SQLite रीडरसाठी, रायटर (writer) थांबवून फाईल कॉपी करा, किंवा 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. हे एकच Go binary आहे ज्यामध्ये SQLite इन-बिल्ट असते, त्यामुळे वेगळ्या डेटाबेस सर्व्हरची किंवा रनटाइमची गरज नसते. हे 128 MB च्या मर्यादेत आरामात चालते. याचा तोटा म्हणजे यात मर्यादित फीचर्स आहेत: हे फक्त Fever API ला सपोर्ट करते आणि याची नवीन आवृत्ती सप्टेंबर 2026 मधील v2.9 ही आहे. जर तुम्हाला Google Reader API सपोर्ट आणि फुल टेक्स्ट सर्च हवा असेल, तर Miniflux सोबत PostgreSQL वापरणे हा 320 MB च्या मर्यादेत उत्तम पर्याय आहे.

मी 1 GB च्या VPS वर self-hosted RSS reader चालवू शकतो का?

हो. Miniflux आणि PostgreSQL दोन्ही कंटेनर्सवर mem_limit सेट केल्यास ते 320 MB च्या आत बसतात, आणि FreshRSS सोबत SQLite एकाच कंटेनरमध्ये मावते. 1 GB वर टाळायची गोष्ट म्हणजे अधिकृत Tiny Tiny RSS स्टॅक, कारण त्यात स्वतःच्या PostgreSQL सह 4 सेवा असतात. नेहमी मेमरी लिमिट सेट करा, कारण मर्यादेशिवाय चालणारा कंटेनर पूर्ण सर्व्हरची मेमरी संपवतो आणि कर्नल अशा वेळी चुकीच्या प्रक्रियेला (बहुतेकदा डेटाबेस) बंद करतो.

यापैकी कोणते RSS reader iOS आणि Android अॅप्ससोबत काम करतात?

Miniflux, FreshRSS आणि CommaFeed 7.3.0 किंवा त्यानंतरच्या आवृत्त्या Fever API आणि Google Reader API दोन्हीला सपोर्ट करतात, त्यामुळे जवळजवळ सर्व मोबाईल क्लायंट्सना ते जोडता येतात. yarr फक्त Fever API ला सपोर्ट करते. Tiny Tiny RSS स्वतःचे API वापरते, त्यामुळे तुम्हाला त्यासाठी बनवलेलाच क्लायंट वापरावा लागेल. FreshRSS वर तुम्हाला Authentication अंतर्गत API access सुरू करावा लागतो आणि प्रोफाइलमध्ये वेगळा API password सेट करावा लागतो, अन्यथा वेबसाइट चालत असूनही अॅपमध्ये लॉगिन अयशस्वी होते.

OPML एक्सपोर्ट म्हणजे माझ्या RSS reader चा बॅकअप आहे का?

नाही. OPML फक्त तुमची सबस्क्रिप्शन लिस्ट पुन्हा तयार करते. FreshRSS चे विस्तारित एक्सपोर्ट फीड-निहाय सेटिंग्ज आणि फिल्टर्स देखील साठवते, परंतु वाचलेली स्थिती (read state), स्टार केलेले आयटम आणि लेखांचा मजकूर डेटाबेसमध्ये असतो. PostgreSQL साठी pg_dump वापरून किंवा SQLite साठी .backup कमांड वापरून डेटाबेसचा बॅकअप घ्या आणि तो सर्व्हरच्या बाहेर सुरक्षित ठेवा.

Miniflux मध्ये SQLite ला सपोर्ट आहे का?

नाही. प्रोजेक्टच्या डॉक्युमेंटेशननुसार ते "फक्त PostgreSQL सोबत काम करते". फुल टेक्स्ट सर्च हे PostgreSQL च्या फीचर्सवर आधारित आहे, त्यामुळे यात बदलण्यासाठी कोणताही हलका पर्याय उपलब्ध नाही. जर तुम्हाला डेटाबेस कंटेनरशिवाय फीड रीडर हवा असेल, तर FreshRSS त्याच्या डीफॉल्ट SQLite बॅकएंडसह किंवा yarr त्याच्या एम्बेडेड फाईलसह वापरा.