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 on a VPS वॉकथ्रू मध्ये आधीच कव्हर केले आहे, म्हणून हे पान पुन्हा इन्स्टॉलेशन सांगण्याऐवजी तुलना करते.

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) हे एक Go binary असून त्यात SQLite एम्बेड केलेले आहे, त्यामुळे कोणत्याही कंटेनरची गरज नाही. साधे ./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 चा यात समावेश नाही.

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

खालील आकडे हे अंदाज आहेत, मोजमापे नाहीत: एका लहान 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 वापरून डंप आणि रिस्टोर करणे. दर एक किंवा दोन वर्षांनी या कामाचे नियोजन करा.

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 आणि yarr हे दोन्ही फक्त Fever सुसंगत API उपलब्ध करून देतात, त्यामुळे ते फक्त Fever ला सपोर्ट करणाऱ्या क्लायंट्ससोबतच काम करतात; जे ॲप्स फक्त Google Reader API वापरतात, त्यांच्यासोबत ते चालत नाहीत. 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 सेट केले आहे कारण बायनरीचे दस्तऐवजीकरण केलेले डीफॉल्ट 127.0.0.1:8080 आहे, आणि कंटेनरच्या आत लूपबॅकवर बांधलेली प्रक्रिया पब्लिश केलेल्या पोर्टद्वारे गाठता येत नाही. परिणामी, कंटेनर व्यवस्थित दिसत असूनही तुम्हाला 'connection reset' ही त्रुटी मिळते. व्हॉल्यूम पाथ /var/lib/postgresql हा PostgreSQL 18 शी जुळतो; आवृत्ती 17 आणि त्यापूर्वीचा डेटा /var/lib/postgresql/data मध्ये साठवला जातो. चुकीचा पाथ माउंट केल्यास डेटा डिरेक्टरी व्हॉल्यूमवर राहत नाही आणि कंटेनर पुन्हा तयार केल्यावर सर्व डेटा नष्ट होतो. 127.0.0.1:8080:8080 पोर्टला सार्वजनिक इंटरनेटपासून दूर ठेवते, कारण पत्त्याशिवाय पोर्ट पब्लिश केल्यास ufw द्वारे व्यवस्थापित न होणाऱ्या साखळीमध्ये (chain) नियम लिहिला जातो. 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 वर तेव्हाच चालते जेव्हा तो 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 सेट केलेले असते तेव्हा स्टार्टअपच्या वेळी स्कीमा मायग्रेशन आपोआप लागू होतात. अपग्रेडचा धोका Miniflux मुळे नसून, त्याखालील PostgreSQL च्या मेजर व्हर्जनमुळे असतो.
• FreshRSS: नवीन इमेज पुल करा. SQLite वापरत असल्यास डेटाबेस इंजिन अपग्रेड करण्याची गरज नसते, त्यामुळे सहसा त्रुटी अशा थर्ड-पार्टी एक्स्टेंशन्समुळे येतात ज्या अपडेटेड नसतात.
• CommaFeed: तुमच्या डेटाबेसशी जुळणारी इमेज व्हेरिएंट पुल करा. latest-h2 वरून latest-postgresql वर स्विच केल्यास तुमचा डेटा आपोआप ट्रान्सफर होत नाही.
• yarr: बायनरी फाईल बदला आणि डेटाबेस फाईल तशीच ठेवा. ऑगस्ट 2026 मध्ये तपासल्यानुसार, जुलै 2024 मधील v2.8 नंतर कोणतेही नवीन रिलीज आलेले नाही, त्यामुळे सहसा अपग्रेड करण्यासाठी काहीही नसते.
• 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 डेटा गृहीत धरला आहे. जेव्हा सर्व्हर 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 एक्सपोर्ट ही केवळ तुमची सबस्क्रिप्शन लिस्ट असते. त्यात फीड URL आणि फोल्डरची नावे असतात. त्यात वाचलेली स्थिती (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 ची मर्यादा यासाठी पुरेशी आहे. मात्र, यात मेंटेनन्स आणि फीचर्सची मर्यादा आहे: याची नवीन आवृत्ती जुलै 2024 मधील v2.8 आहे आणि ते फक्त Fever API ला सपोर्ट करते. जर तुम्हाला याच क्षमतेचे सक्रियपणे विकसित होणारे प्रोजेक्ट हवे असेल, तर Miniflux सोबत PostgreSQL वापरणे हा 320 MB मर्यादेत एक उत्तम पर्याय आहे.

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

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

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

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

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

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

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

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