VPS के लिए सर्वश्रेष्ठ self-hosted RSS reader की तुलना

छोटे VPS के लिए कौन सा self-hosted RSS reader उपयुक्त है

छोटे VPS पर इस्तेमाल करने के लिए Miniflux सबसे अच्छा self-hosted RSS reader है। यह PostgreSQL के साथ केवल एक Go binary है। यह Fever और Google Reader APIs को सपोर्ट करता है, जिससे थर्ड-पार्टी फोन ऐप्स इससे कनेक्ट हो सकते हैं, और इसे अपग्रेड करना केवल एक docker compose pull है। यदि आपको extensions चाहिए और एक ऐसा container चाहिए जिसमें SQLite पहले से हो, तो FreshRSS चुनें।

VPS पर जगह बनाने के लिए पाँच readers उपयोगी हैं: Miniflux, FreshRSS, CommaFeed, yarr और Tiny Tiny RSS। यह पेज इनके बीच के वास्तविक अंतर की तुलना करता है: प्रत्येक stack को कितनी memory चाहिए, प्रत्येक कौन सा database अनिवार्य करता है, आपके फोन ऐप को किस sync API की आवश्यकता है, और अपग्रेड के दिन क्या होता है। यहाँ दी गई प्रत्येक संख्या या तो प्रोजेक्ट द्वारा प्रकाशित है या सामान्य गणित पर आधारित है, और टेक्स्ट में बताया गया है कि कौन सी क्या है। इनमें से कोई भी आपके हार्डवेयर का benchmark नहीं है, इसलिए अपने बॉक्स को docker stats के साथ स्वयं मापें।

पाँच रीडर्स, प्रत्येक के लिए एक पैराग्राफ

Miniflux को Go में लिखा गया है और यह एक सिंगल statically compiled binary के रूप में आता है। इसका documentation इसकी एकमात्र अनिवार्य dependency के बारे में स्पष्ट है: यह "केवल PostgreSQL के साथ काम करता है"। इसमें कोई SQLite मोड नहीं है। यह एक REST API, एक Fever compatible API और एक Google Reader compatible API प्रदान करता है, साथ ही OPML import और export की सुविधा भी देता है। Full text search का काम PostgreSQL को सौंपा गया है, जो इस बात का एक कारण है कि डेटाबेस वैकल्पिक क्यों नहीं है।

FreshRSS PHP आधारित है और एक ऐसे container में चलता है जिसमें web server और application दोनों शामिल होते हैं। SQLite इसका डिफ़ॉल्ट डेटाबेस है और इसके लिए किसी दूसरे सर्विस की आवश्यकता नहीं होती, जबकि बड़े इंस्टॉलेशन के लिए PostgreSQL और MySQL समर्थित हैं। यह Google Reader API और Fever API का समर्थन करता है। इसे इंस्टॉल करने की प्रक्रिया हमारे FreshRSS on a VPS walkthrough में पहले ही कवर की जा चुकी है, इसलिए यह पेज इसे दोहराने के बजाय इसकी तुलना करता है।

CommaFeed Quarkus पर आधारित Java एप्लीकेशन है जिसका लेआउट Google Reader की नकल करता है। इसका डेटाबेस रन-टाइम के बजाय बिल्ड-टाइम पर चुना जाता है, इसलिए प्रोजेक्ट प्रत्येक डेटाबेस के लिए एक अलग इमेज प्रकाशित करता है: एम्बेडेड H2 डेटाबेस के लिए athou/commafeed:latest-h2, PostgreSQL के लिए athou/commafeed:latest-postgresql, और MySQL तथा MariaDB के लिए अन्य वेरिएंट्स। यह एक REST API और एक Fever compatible API प्रदान करता है।

yarr (yet another rss reader) एक Go बाइनरी है जिसमें SQLite एम्बेडेड है, और इसे किसी भी container की आवश्यकता नहीं होती है। साधारण ./yarr, 127.0.0.1:7070 पर लिसन करता है। इसके फ्लैग्स संक्षिप्त हैं: -addr 0.0.0.0:7070 -auth alice:secret इसे पासवर्ड के पीछे नेटवर्क के लिए खोलता है, और -db /data/yarr.db डेटाबेस को आपकी इच्छित लोकेशन पर रखता है। इसमें Fever compatible API मौजूद है। इसका नवीनतम टैग्ड रिलीज़ v2.8 है, जो जुलाई 2024 का है और जिसे अगस्त 2026 में चेक किया गया था, इसलिए इसे सक्रिय रूप से विकसित होने वाले सॉफ़्टवेयर के बजाय एक पूर्ण (finished) सॉफ़्टवेयर के रूप में देखें।

Tiny Tiny RSS इन पाँचों में सबसे पुराना है और चलाने में सबसे भारी है। इसका आधिकारिक Docker सेटअप चार सर्विसेज का है: एक PostgreSQL container, एक PHP-FPM एप्लीकेशन container, एक अलग अपडेटर container जो फीड्स फेच करता है, और सामने एक nginx container। इसका documentation स्पष्ट रूप से बताता है कि "यह सेटअप PostgreSQL का उपयोग करता है"। इसका अपना JSON API है, जिसका उपयोग इसका Android क्लाइंट और कई थर्ड-पार्टी ऐप्स करते हैं। Fever इसका हिस्सा नहीं है।

प्रत्येक stack को कितनी memory की आवश्यकता है

नीचे दिए गए आंकड़े अनुमानित बजट हैं, वास्तविक माप नहीं: यह वह memory सीमा है जिसके भीतर एक छोटे VPS पर प्रत्येक stack को रहना चाहिए। CommaFeed की संख्या परियोजना द्वारा स्वयं प्रकाशित उदाहरण है, जो container को 256 MB पर सीमित करती है। अन्य आंकड़े वे सीमाएं हैं जो feed fetcher के लिए अतिरिक्त जगह (headroom) छोड़ती हैं, क्योंकि 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 file है, जिसमें कोई database server या language runtime नहीं होता। Miniflux को 2 containers में 320 MB की आवश्यकता होती है, और इसमें से अधिकांश हिस्सा Miniflux के बजाय PostgreSQL का होता है। Tiny Tiny RSS 4 containers में 640 MB के साथ सबसे अलग है, क्योंकि application, updater, database और web server चार अलग-अलग processes हैं जिनमें चार अलग-अलग heaps होते हैं।

इन्हें केवल उम्मीद के तौर पर नहीं, बल्कि वास्तविक सीमाओं (limits) के रूप में सेट करें। Docker Compose में memory सीमाएं इस syntax को कवर करता है और बताता है कि सीमा तक पहुँचने पर container क्या करता है। बिना किसी सीमा वाला container पूरी तरह भरे हुए box पर सही ढंग से fail नहीं होता: kernel एक victim process को चुनता है और उसे kill कर देता है, और वह victim अक्सर वह container नहीं होता जिसने दबाव (pressure) पैदा किया था।

प्रत्येक reader आप पर कौन सा database थोपता है

इन पाँचों के बीच सबसे बड़ा परिचालन अंतर database का है। यह user interface के किसी भी अंतर से बड़ा निर्णय है, क्योंकि यह आपकी backup प्रक्रिया और upgrade के जोखिम को तय करता है।

Miniflux और आधिकारिक Tiny Tiny RSS सेटअप के लिए PostgreSQL आवश्यक है। यह वास्तविक full text search और सुरक्षित concurrent writes की सुविधा देता है। इसकी कीमत एक दूसरा container, एक volume और एक आवर्ती समस्या है: आधिकारिक PostgreSQL images major versions के बीच डेटा को इन-प्लेस migrate नहीं कर सकती हैं। Tiny Tiny RSS का documentation इसे सीधे तौर पर कहता है और चेतावनी देता है कि "आधिकारिक PostgreSQL containers में major versions के बीच डेटा migrate करने के लिए कोई समर्थन नहीं है"। आपके पास व्यावहारिक विकल्प यह है कि आप पुराने major version को पिन कर दें, या pg_dump और pg_restore का उपयोग करके dump और restore करें। हर एक या दो साल में एक बार इसके लिए योजना बनाएँ।

SQLite, FreshRSS और yarr का डिफ़ॉल्ट है। एक फ़ाइल, कोई सर्वर नहीं, कोई port नहीं, कोई password नहीं। यह कुछ सौ feeds वाले एक व्यक्ति के लिए अच्छा काम करता है, और जब कई users एक साथ लिखते हैं तो यह धीमा हो जाता है, तभी FreshRSS का PostgreSQL विकल्प अपनी उपयोगिता साबित करता है। yarr ने v2.7 में वैकल्पिक PostgreSQL समर्थन जोड़ा है, लेकिन embedded फ़ाइल ही इसे चलाने का सामान्य तरीका है।

H2, CommaFeed का embedded डिफ़ॉल्ट है, और शुरू करने से पहले इस पर थोड़ा विचार करना आवश्यक है, क्योंकि CommaFeed image build होते समय ही अपना database चुन लेता है। बाद में H2 से PostgreSQL पर जाना केवल configuration बदलना नहीं है। यह एक अलग image है और साथ ही एक डेटा माइग्रेशन है जिसे आपको स्वयं करना होगा, इसलिए बॉक्स में एक साल का read history होने से पहले ही निर्णय ले लें।

क्या आपका फोन ऐप काम करेगा

यह प्रश्न उम्मीद से कहीं अधिक महत्वपूर्ण है, क्योंकि वेब इंटरफेस केवल एक फीड रीडर के उपयोग का आधा हिस्सा है।

Miniflux एक Fever compatible API और एक Google Reader compatible API का समर्थन करता है, इसलिए अधिकांश iOS और Android क्लाइंट इससे कनेक्ट हो जाते हैं। FreshRSS भी इन्हीं दो API का समर्थन करता है, और इसके अपने दस्तावेज़ उन्हें इस प्रकार क्रमबद्ध करते हैं: Google Reader API पूर्ण फीचर समर्थन के साथ "सर्वश्रेष्ठ" है, जबकि Fever API में "सीमित फीचर्स और कम कुशल" व्यवहार होता है। FreshRSS में किसी भी ऐप के लॉग इन करने से पहले दो चरणों की आवश्यकता होती है। Authentication के अंतर्गत "Allow API access (required for mobile apps)" को सक्षम करें, फिर यूजर प्रोफाइल में एक API पासवर्ड बनाएं। API पासवर्ड को छोड़ने पर ऐप में ऑथेंटिकेशन फेलियर (authentication failure) आता है, जबकि वेब लॉगिन काम करता रहता है, जो तब तक भ्रमित करने वाला होता है जब तक आप यह न जान लें कि कहाँ देखना है।

CommaFeed और yarr दोनों केवल Fever compatible API को एक्सपोज़ करते हैं, इसलिए वे Fever का समर्थन करने वाले क्लाइंट्स के साथ काम करते हैं, न कि उन ऐप्स के साथ जो केवल Google Reader का उपयोग करते हैं। इसके विपरीत, Tiny Tiny RSS का अपना API है, जिसका अर्थ है कि आपको इसके लिए विशेष रूप से लिखे गए क्लाइंट की आवश्यकता होगी। 300 फीड्स इम्पोर्ट करने से पहले यह जांच लें कि आपका पसंदीदा ऐप उस रीडर का समर्थन करता है या नहीं।

1 GB RAM वाले सर्वर के लिए एक कार्यशील compose file

यह Miniflux stack है, जिसे अगस्त 2026 तक के प्रोजेक्ट के आधिकारिक Docker उदाहरण के अनुसार अनुकूलित किया गया है। पब्लिश किया गया पोर्ट loopback पर बाइंड है, listen address स्पष्ट रूप से सेट है, और दोनों containers पर मेमोरी लिमिट लगाई गई है।

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 का एरर मिलता है जबकि कंटेनर healthy दिखता है। वॉल्यूम पाथ /var/lib/postgresql, PostgreSQL 18 से मेल खाता है; वर्जन 17 और उससे पुराने वर्जन डेटा को /var/lib/postgresql/data में स्टोर करते हैं, और गलत पाथ माउंट करने का मतलब है कि डेटा डायरेक्टरी वॉल्यूम पर है ही नहीं, इसलिए कंटेनर के दोबारा बनने पर सब कुछ गायब हो जाता है। 127.0.0.1:8080:8080 पोर्ट को पब्लिक इंटरनेट से दूर रखता है, क्योंकि बिना एड्रेस के पोर्ट पब्लिश करने पर एक ऐसा नियम (rule) चेन में लिख जाता है जिसे 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 लाइव मेमोरी कॉलम को प्रिंट करता है, और यही वह संख्या है जिसकी तुलना ऊपर दिए गए चार्ट की सीमाओं (ceilings) से करनी है। यदि 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 का प्रमुख संस्करण (major version) है।
• FreshRSS: नया image pull करें। SQLite के साथ अपग्रेड करने के लिए कोई डेटाबेस इंजन नहीं होता, इसलिए सामान्य समस्याएँ उन third-party extensions से आती हैं जो अपडेट नहीं हुए हैं।
• 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। स्कीमा माइग्रेशन स्वचालित रूप से चलते हैं, और जब किसी माइग्रेशन को पुष्टि की आवश्यकता होती है, तो इंटरफ़ेस आपको माइग्रेशन स्क्रीन पर रीडायरेक्ट कर देता है।

इनमें से किसी भी प्रक्रिया से पहले डेटाबेस का 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 फीड के विरुद्ध अंतिम त्रुटि को रिकॉर्ड करता है, इसलिए जब कोई एक फीड अपडेट होना बंद कर दे और बाकी काम करते रहें, तो फीड लिस्ट सबसे पहली जगह है जहाँ आपको देखना चाहिए।

Feeds समाप्त हो जाते हैं, और एक OPML फ़ाइल बैकअप नहीं है

Feeds आपकी अपेक्षा से अधिक तेज़ी से खराब होते हैं। डोमेन की समय-सीमा समाप्त हो जाती है, साइटें बिना किसी फ़ीड वाले प्लेटफ़ॉर्म पर चली जाती हैं, और जो URL पहले XML प्रदान करता था, वह अब 200 OK स्टेटस के साथ HTML एरर पेज दिखाने लगता है। अंतिम स्थिति सबसे कठिन है: फ़ेच सफल होता है, पार्स विफल हो जाता है, और आपका रीडर नेटवर्क एरर के बजाय पार्सिंग एरर रिकॉर्ड करता है। साल में एक बार, फ़ीड सूची को 'अंतिम अपडेट' के आधार पर सॉर्ट करें और जो फ़ीड शांत हो गए हैं, उन्हें हटा दें।

एक OPML एक्सपोर्ट केवल आपकी सब्सक्रिप्शन सूची है। इसमें फ़ीड URL और फ़ोल्डर के नाम होते हैं। इसमें रीड स्टेट, स्टार किए गए लेख, प्रति-फ़ीड सेटिंग्स, फ़िल्टर नियम, या आपके द्वारा सहेजा गया लेख का टेक्स्ट नहीं होता है। उस OPML को एक नए इंस्टॉलेशन में इम्पोर्ट करने पर आपको अपने फ़ीड तो वापस मिल जाते हैं, लेकिन आपके द्वारा पढ़े गए सभी लेख फिर से 'अपठित' (unread) के रूप में चिह्नित हो जाते हैं।

जो बैकअप वास्तव में मायने रखता है, वह डेटाबेस है। PostgreSQL के लिए, ऊपर दिया गया pg_dump कमांड ही पूरा काम है। FreshRSS या yarr जैसे SQLite रीडर के लिए, राइटर को रोकें और फ़ाइल को कॉपी करें, या sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" का उपयोग करके चलते हुए डेटाबेस की एक सुसंगत कॉपी लें। लिखे जा रहे डेटाबेस का साधारण cp ऐसी फ़ाइल बना सकता है जो बाद में नहीं खुलेगी, क्योंकि कॉपी में अधूरा लेखन (half-finished write) कैप्चर हो जाता है। फिर इन फ़ाइलों को एक शेड्यूल पर सर्वर से बाहर भेजें, जिसके लिए restic backups on a VPS का उपयोग किया जाता है, और कम से कम एक बार किसी स्क्रैच कंटेनर में रिस्टोर करके देखें ताकि आप सुनिश्चित हो सकें कि प्रक्रिया काम करती है।

एक फ़ीड रीडर स्वयं चलाने के लिए सबसे सस्ती सेवाओं में से एक है, यही कारण है कि यह things worth self-hosting in 2026 की हर सूची में दिखाई देता है। इसके साथ a self-hosted SearXNG instance लगाएँ और आपकी रीडिंग और सर्चिंग दोनों आपके नियंत्रण वाले हार्डवेयर पर सुरक्षित रहेंगी।

FAQ

कौन सा self-hosted RSS reader सबसे कम memory का उपयोग करता है?

yarr। यह SQLite के साथ compile किया गया एक single Go binary है, इसलिए इसमें कोई database server या अतिरिक्त language runtime की आवश्यकता नहीं होती है, और 128 MB की सीमा इसके लिए पर्याप्त है। इसका नुकसान maintenance और features में है: इसका नवीनतम release जुलाई 2024 का v2.8 है, और यह केवल Fever API को support करता है। यदि आप समान footprint वाला कोई सक्रिय रूप से विकसित project चाहते हैं, तो Miniflux के साथ PostgreSQL, 320 MB पर एक बेहतर विकल्प है।

क्या मैं 1 GB VPS पर self-hosted RSS reader चला सकता हूँ?

हाँ। PostgreSQL के साथ Miniflux दोनों containers पर mem_limit set करने पर लगभग 320 MB के भीतर आ जाता है, और SQLite के साथ FreshRSS एक ही container में फिट हो जाता है। 1 GB पर जिस stack से बचना चाहिए वह आधिकारिक Tiny Tiny RSS है, जो अपने स्वयं के PostgreSQL सहित 4 services का उपयोग करता है। हमेशा memory limits set करें, क्योंकि full box पर unlimited container होने से kernel किसी process को kill कर देता है, और अक्सर वह process application के बजाय database होती है।

इनमें से कौन से iOS और Android RSS apps के साथ काम करते हैं?

Miniflux और FreshRSS दोनों Fever compatible API और Google Reader compatible API को support करते हैं, इसलिए लगभग कोई भी mobile client इनसे connect हो जाता है। CommaFeed और yarr केवल Fever API प्रदान करते हैं। Tiny Tiny RSS अपनी स्वयं की API का उपयोग करता है, इसलिए आपको इसके लिए बने client की आवश्यकता होगी। FreshRSS पर आपको Authentication के अंतर्गत API access को enable करना होगा और profile में एक अलग API password set करना होगा, अन्यथा website काम करने के बावजूद app login नहीं कर पाएगा।

क्या OPML export मेरे RSS reader का backup है?

नहीं। OPML में केवल feed URLs और folders होते हैं, इसलिए यह केवल आपकी subscription list को फिर से बनाता है। Read state, starred items, filter rules और article text सभी database में रहते हैं। PostgreSQL के लिए pg_dump या SQLite के लिए .backup command का उपयोग करके database का backup लें और result को server से बाहर copy करें।

क्या Miniflux SQLite को support करता है?

नहीं। Project documentation के अनुसार यह "केवल PostgreSQL के साथ काम करता है", और full text search को PostgreSQL features के साथ implement किया गया है, इसलिए इसमें switch करने के लिए कोई हल्का mode उपलब्ध नहीं है। यदि आप बिना किसी database container के feed reader चाहते हैं, तो FreshRSS को उसके default SQLite backend के साथ या yarr को उसके embedded file के साथ चलाएं।