بہترین self-hosted RSS reader کا انتخاب VPS کے لیے

کون سا self-hosted RSS reader چھوٹے VPS کے لیے موزوں ہے

Miniflux وہ self-hosted RSS reader ہے جسے چھوٹے VPS پر انسٹال کرنا چاہیے۔ یہ PostgreSQL کے ساتھ ایک Go binary پر مشتمل ہے۔ یہ Fever اور Google Reader APIs کو سپورٹ کرتا ہے، لہذا فریق ثالث (third-party) فون ایپس اس سے منسلک ہو سکتی ہیں، اور اپ گریڈ کا عمل صرف ایک docker compose pull ہے۔ اگر آپ کو extensions اور SQLite کے ساتھ ایک ہی container درکار ہو تو FreshRSS کا انتخاب کریں۔

VPS پر ڈسک کی جگہ کے لحاظ سے پانچ readers قابلِ غور ہیں: Miniflux، FreshRSS، CommaFeed، yarr اور Tiny Tiny RSS۔ یہ صفحہ ان کے درمیان حقیقی فرق کا موازنہ کرتا ہے: ہر stack کے لیے درکار memory، وہ database جو ہر ایک کے لیے لازمی ہے، وہ sync API جس کی آپ کی فون ایپ کو ضرورت ہے، اور اپ گریڈ کے دن کیا ہوتا ہے۔ یہاں موجود ہر عدد یا تو پروجیکٹ کی طرف سے شائع کردہ ہے یا سادہ حساب کتاب پر مبنی ہے، اور متن میں اس کی وضاحت موجود ہے۔ ان میں سے کوئی بھی آپ کے ہارڈویئر کا benchmark نہیں ہے، لہذا اپنے باکس کی پیمائش docker stats کے ذریعے کریں۔

پانچ ریڈرز، ہر ایک کے لیے ایک پیراگراف

Miniflux کو Go میں لکھا گیا ہے اور یہ ایک واحد statically compiled بائنری کے طور پر ریلیز ہوتا ہے۔ اس کی دستاویزات اس کی واحد سخت ضرورت کے بارے میں واضح ہیں: یہ "صرف 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 واک تھرو میں بیان کیا جا چکا ہے، لہذا یہ صفحہ انسٹالیشن کو دہرانے کے بجائے اس کا موازنہ پیش کرتا ہے۔

CommaFeed کو Quarkus پر Java میں لکھا گیا ہے اور اس کا لے آؤٹ Google Reader کی نقل ہے۔ اس کا ڈیٹا بیس رن ٹائم کے بجائے بلڈ ٹائم پر منتخب کیا جاتا ہے، اس لیے پروجیکٹ ہر ڈیٹا بیس کے لیے ایک الگ امیج شائع کرتا ہے: ایمبیڈڈ H2 ڈیٹا بیس کے لیے athou/commafeed:latest-h2، PostgreSQL کے لیے athou/commafeed:latest-postgresql، اور MySQL اور MariaDB کے لیے مزید ویریئنٹس۔ یہ ایک REST API اور Fever کے ساتھ ہم آہنگ API فراہم کرتا ہے۔

yarr (yet another rss reader) ایک Go بائنری ہے جس میں SQLite ایمبیڈڈ ہے، اور اسے کسی کنٹینر کی ضرورت نہیں ہوتی۔ سادہ ./yarr، 127.0.0.1:7070 پر لسن کرتا ہے۔ اس کے فلیگز مختصر ہیں: -db /data/yarr.db ڈیٹا بیس کو آپ کی مطلوبہ جگہ پر رکھتا ہے اور -addr 0.0.0.0:7070 -auth alice:secret اسے پاس ورڈ کے ساتھ نیٹ ورک پر کھولتا ہے۔ اس میں Fever کے ساتھ ہم آہنگ API موجود ہے۔ اس کی تازہ ترین ٹیگ شدہ ریلیز v2.8 ہے، جو جولائی 2024 کی ہے اور اگست 2026 میں چیک کی گئی ہے، لہذا اسے فعال طور پر تیار ہونے والے سافٹ ویئر کے بجائے ایک مکمل شدہ سافٹ ویئر سمجھیں۔

Tiny Tiny RSS ان پانچوں میں سب سے پرانا اور چلانے میں سب سے بھاری ہے۔ اس کا آفیشل Docker سیٹ اپ چار سروسز پر مشتمل ہے: ایک PostgreSQL کنٹینر، ایک PHP-FPM ایپلیکیشن کنٹینر، فیڈز حاصل کرنے کے لیے ایک الگ اپڈیٹر کنٹینر، اور سامنے ایک nginx کنٹینر۔ دستاویزات واضح طور پر بیان کرتی ہیں کہ "یہ سیٹ اپ PostgreSQL استعمال کرتا ہے"۔ اس کا اپنا JSON API ہے، جسے اس کا اینڈرائیڈ کلائنٹ اور کئی تھرڈ پارٹی ایپس استعمال کرتی ہیں۔ 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) ہیں۔

ان کو محض خواہشات کے بجائے حقیقی حدود کے طور پر سیٹ کریں۔ Docker Compose میں میموری کی حدود اس کے نحو (syntax) کا احاطہ کرتا ہے اور یہ بتاتا ہے کہ جب کوئی کنٹینر اپنی حد تک پہنچ جاتا ہے تو کیا ہوتا ہے۔ بغیر حد والا کنٹینر مکمل بھرے ہوئے باکس پر شائستگی سے فیل نہیں ہوتا: کرنل ایک شکار پروسیس کا انتخاب کر کے اسے ختم کر دیتا ہے، اور اکثر وہ شکار وہ کنٹینر نہیں ہوتا جس نے دباؤ پیدا کیا ہوتا ہے۔

ہر ریڈر آپ پر کون سا ڈیٹا بیس مسلط کرتا ہے

ان پانچوں کے درمیان سب سے بڑا آپریشنل فرق ڈیٹا بیس کا ہے۔ یہ یوزر انٹرفیس کے کسی بھی فرق سے زیادہ اہم فیصلہ ہے، کیونکہ یہ آپ کے بیک اپ کے طریقہ کار اور اپ گریڈ کے خطرے کا تعین کرتا ہے۔

Miniflux اور سرکاری Tiny Tiny RSS سیٹ اپ کے لیے PostgreSQL درکار ہے۔ یہ حقیقی فل ٹیکسٹ سرچ اور محفوظ کنکرنٹ رائٹس (concurrent writes) کی سہولت دیتا ہے۔ اس کی قیمت ایک اضافی کنٹینر، ایک والیوم، اور ایک مستقل مسئلہ ہے: سرکاری PostgreSQL امیجز میجر ورژنز کے درمیان ڈیٹا کو براہ راست مائیگریٹ نہیں کر سکتیں۔ Tiny Tiny RSS کی دستاویزات میں یہ بات واضح طور پر درج ہے، اور خبردار کیا گیا ہے کہ "سرکاری PostgreSQL کنٹینرز میں میجر ورژنز کے درمیان ڈیٹا مائیگریشن کی کوئی سپورٹ نہیں ہے"۔ آپ کے پاس حقیقت پسندانہ آپشنز یہ ہیں کہ پرانے میجر ورژن کو پن (pin) کر لیں، یا pg_dump اور pg_restore کے ذریعے ڈمپ اور ریسٹور کریں۔ ہر ایک یا دو سال میں اس کے لیے منصوبہ بندی کریں۔

SQLite، FreshRSS اور yarr کا ڈیفالٹ ہے۔ ایک فائل، کوئی سرور نہیں، کوئی پورٹ نہیں، کوئی پاس ورڈ نہیں۔ یہ ایک شخص کے لیے چند سو فیڈز کے ساتھ بہترین کام کرتا ہے، اور جب کئی صارفین ایک ساتھ لکھتے ہیں تو یہ سست ہو جاتا ہے، تب ہی FreshRSS کا PostgreSQL آپشن اپنی افادیت ثابت کرتا ہے۔ yarr نے v2.7 میں اختیاری PostgreSQL سپورٹ شامل کی ہے، لیکن ایمبیڈڈ فائل ہی اسے چلانے کا معمول کا طریقہ ہے۔

H2، CommaFeed کا ایمبیڈڈ ڈیفالٹ ہے، اور شروع کرنے سے پہلے اس پر غور کرنا ضروری ہے، کیونکہ CommaFeed امیج بنتے وقت ہی اپنا ڈیٹا بیس منتخب کر لیتا ہے۔ بعد میں H2 سے PostgreSQL پر منتقل ہونا محض کنفیگریشن کی تبدیلی نہیں ہے۔ یہ ایک مختلف امیج ہے جس کے ساتھ ڈیٹا مائیگریشن بھی آپ کو خود کرنی پڑتی ہے، لہذا اس سے پہلے فیصلہ کریں کہ آپ کے پاس ایک سال کی ریڈ ہسٹری جمع ہو جائے۔

کیا آپ کی فون ایپ کام کرے گی

یہ سوال توقع سے زیادہ اہمیت رکھتا ہے، کیونکہ ویب انٹرفیس فیڈ ریڈر کے استعمال کا صرف نصف حصہ ہے۔

Miniflux ایک Fever compatible API اور ایک Google Reader compatible API کو سپورٹ کرتا ہے، لہذا زیادہ تر iOS اور Android کلائنٹس اس سے منسلک ہو سکتے ہیں۔ FreshRSS بھی یہی دو APIs سپورٹ کرتا ہے، اور اس کی اپنی دستاویزات میں ان کی درجہ بندی یوں ہے: 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 باکس کے لیے ایک فعال compose فائل

یہ Miniflux اسٹیک ہے، جسے اگست 2026 تک پروجیکٹ کی اپنی Docker مثال سے اخذ کیا گیا ہے۔ شائع شدہ پورٹ کو loopback پر bind کیا گیا ہے، 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 پر bind ہونے والا عمل شائع شدہ پورٹ کے ذریعے قابل رسائی نہیں ہوتا، جس کے نتیجے میں کنٹینر کے صحت مند نظر آنے کے باوجود 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 پر تبھی چلتا ہے جب وہ VPS کچھ اور نہ کر رہا ہو، اور یہ کسی دوسری ڈیٹا بیس پر مبنی ایپلیکیشن اور reverse proxy کے ساتھ وہاں نہیں چل سکتا۔ چار سروسز کا مطلب ہے چار گنا overhead، اور ان میں سے ایک PostgreSQL ہے۔

CommaFeed چل سکتا ہے، لیکن صرف H2 امیج اور 256 MB کی حد کے ساتھ جو پروجیکٹ کی اپنی مثال میں دی گئی ہے۔ جو چیز چھوٹے باکس کو ناکام بناتی ہے وہ ایک JVM کا الگ ڈیٹا بیس سرور کے ساتھ ہونا ہے، کیونکہ JVM کو جتنی بھی جگہ ملے وہ اسے استعمال کر لیتی ہے۔ CommaFeed کی دستاویزات -Xmx256m کو ایک سخت حد کے طور پر اور OpenJ9 کو "HotSpot JVM کا زیادہ میموری بچانے والا متبادل" قرار دیتی ہیں، جس سے آپ کو اندازہ ہو جائے گا کہ اس کی میموری کہاں خرچ ہوتی ہے۔

جب باکس کی میموری ختم ہو جاتی ہے، تو kernel کا 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: بائنری کو تبدیل کریں اور ڈیٹا بیس فائل کو برقرار رکھیں۔ جولائی 2024 میں v2.8 کے بعد سے کوئی ریلیز نہ ہونے کی وجہ سے، اگست 2026 میں چیک کرنے پر، عام طور پر اپ گریڈ کرنے کے لیے کچھ نہیں ہوتا۔
• 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 فیڈز پر 5 منٹ کا وقفہ 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 فراہم کرتا تھا وہ اب ایک HTML ایرر پیج دکھانے لگتا ہے جس کا اسٹیٹس 200 OK ہوتا ہے۔ آخری صورت سب سے زیادہ پریشان کن ہے: فیچ (fetch) کامیاب ہو جاتا ہے، پارس (parse) ناکام ہو جاتا ہے، اور آپ کا ریڈر نیٹ ورک ایرر کے بجائے پارسنگ ایرر ریکارڈ کرتا ہے۔ سال میں ایک بار، اپنی فیڈ لسٹ کو آخری اپ ڈیٹ کے لحاظ سے ترتیب دیں اور جو فیڈز خاموش ہو چکی ہیں انہیں ڈیلیٹ کر دیں۔

OPML ایکسپورٹ صرف آپ کی سبسکرپشن لسٹ ہے۔ اس میں فیڈ URLs اور فولڈر کے نام ہوتے ہیں۔ اس میں پڑھنے کی حالت (read state)، اسٹار شدہ آرٹیکلز، فیڈ کے مطابق سیٹنگز، فلٹر رولز، یا آپ کا محفوظ کردہ آرٹیکل ٹیکسٹ شامل نہیں ہوتا۔ اس OPML کو کسی نئی انسٹالیشن میں امپورٹ کریں تو آپ کو اپنی فیڈز تو واپس مل جائیں گی لیکن آپ کے پڑھے ہوئے تمام آرٹیکلز دوبارہ 'unread' کے طور پر نشان زد ہو جائیں گے۔

اصل بیک اپ ڈیٹا بیس ہے۔ PostgreSQL کے لیے، اوپر دیا گیا pg_dump کمانڈ ہی مکمل کام ہے۔ FreshRSS یا yarr جیسے SQLite ریڈرز کے لیے، رائٹر کو روکیں اور فائل کاپی کریں، یا پھر sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" کا استعمال کرتے ہوئے اس وقت مستقل کاپی لیں جب وہ چل رہا ہو۔ کسی ایسے ڈیٹا بیس کی سادہ cp جو اس وقت لکھا جا رہا ہو، ایسی فائل بنا سکتی ہے جو بعد میں کھلے گی نہیں، کیونکہ کاپی میں ادھورا لکھا ہوا ڈیٹا آ جاتا ہے۔ پھر ان فائلوں کو ایک شیڈول کے مطابق سرور سے باہر منتقل کریں، جس کے لیے restic backups on a VPS استعمال ہوتے ہیں، اور کم از کم ایک بار کسی ٹیسٹ کنٹینر میں بحال (restore) کر کے دیکھیں تاکہ آپ کو طریقہ کار کا علم ہو۔

فیڈ ریڈر خود چلانے کے لیے سب سے سستی سروسز میں سے ایک ہے، اسی لیے یہ things worth self-hosting in 2026 کی ہر فہرست میں شامل ہے۔ اس کے ساتھ a self-hosted SearXNG instance لگائیں تو آپ کی ریڈنگ اور سرچنگ دونوں ایسے ہارڈویئر پر رہیں گے جس پر آپ کا کنٹرول ہے۔

FAQ

کون سا self-hosted RSS reader سب سے کم میموری استعمال کرتا ہے؟

yarr۔ یہ ایک واحد Go binary ہے جس میں SQLite شامل ہے، لہذا اس کے ساتھ کوئی الگ database server یا language runtime درکار نہیں ہوتا، اور 128 MB کی حد اس کے لیے کافی ہے۔ اس کا نقصان دیکھ بھال اور فیچرز کی کمی ہے: اس کا تازہ ترین release جولائی 2024 کا v2.8 ہے، اور یہ صرف Fever API کو سپورٹ کرتا ہے۔ اگر آپ اسی طرح کے footprint کے ساتھ کوئی فعال پروجیکٹ چاہتے ہیں، تو Miniflux بمعہ PostgreSQL جو 320 MB پر چلتا ہے، بہتر انتخاب ہے۔

کیا میں 1 GB کے VPS پر self-hosted RSS reader چلا سکتا ہوں؟

جی ہاں۔ Miniflux بمعہ PostgreSQL تقریباً 320 MB میں سما جاتا ہے جب آپ دونوں containers پر mem_limit سیٹ کرتے ہیں، اور FreshRSS بمعہ SQLite ایک ہی container میں فٹ ہو جاتا ہے۔ 1 GB پر Tiny Tiny RSS کا آفیشل اسٹیک استعمال کرنے سے گریز کریں، کیونکہ یہ 4 سروسز پر مشتمل ہے جس میں اس کا اپنا PostgreSQL بھی شامل ہے۔ ہمیشہ memory limits سیٹ کریں، کیونکہ مکمل بھرے ہوئے سرور پر بغیر حد والا container kernel کے ہاتھوں process kill کروا سکتا ہے، اور اکثر غلطی کرنے والی application کے بجائے database کو kill کر دیا جاتا ہے۔

ان میں سے کون سے iOS اور Android RSS ایپس کے ساتھ کام کرتے ہیں؟

Miniflux اور FreshRSS دونوں Fever compatible API اور Google Reader compatible API کو سپورٹ کرتے ہیں، اس لیے تقریباً ہر موبائل کلائنٹ ان سے منسلک ہو سکتا ہے۔ CommaFeed اور yarr صرف Fever API پیش کرتے ہیں۔ Tiny Tiny RSS اپنا API استعمال کرتا ہے، لہذا آپ کو اس کے لیے مخصوص کلائنٹ کی ضرورت ہوگی۔ FreshRSS پر آپ کو Authentication کے تحت API access کو فعال کرنا ہوگا اور profile میں الگ API password سیٹ کرنا ہوگا، ورنہ ایپ لاگ ان نہیں ہو سکے گی جبکہ ویب سائٹ کام کرتی رہے گی۔

کیا OPML ایکسپورٹ میرے RSS reader کا بیک اپ ہے؟

نہیں۔ OPML میں صرف feed URLs اور فولڈرز ہوتے ہیں، لہذا یہ صرف آپ کی سبسکرپشن لسٹ کو بحال کرتا ہے، کچھ اور نہیں۔ پڑھنے کی حالت (read state)، اسٹار کردہ آئٹمز، فلٹر رولز اور آرٹیکل کا متن سب ڈیٹا بیس میں محفوظ ہوتے ہیں۔ ڈیٹا بیس کا بیک اپ لینے کے لیے PostgreSQL کے لیے pg_dump یا SQLite کے لیے .backup کمانڈ استعمال کریں اور نتیجے کو سرور سے باہر کاپی کر لیں۔

کیا Miniflux SQLite کو سپورٹ کرتا ہے؟

نہیں۔ پروجیکٹ کی دستاویزات کے مطابق یہ "صرف PostgreSQL کے ساتھ کام کرتا ہے"، اور full text search کو PostgreSQL کے فیچرز کے ساتھ نافذ کیا گیا ہے، لہذا اس میں سوئچ کرنے کے لیے کوئی ہلکا موڈ موجود نہیں ہے۔ اگر آپ ایسا فیڈ ریڈر چاہتے ہیں جس میں کوئی ڈیٹا بیس کنٹینر نہ ہو، تو FreshRSS کو اس کے ڈیفالٹ SQLite بیک اینڈ کے ساتھ یا yarr کو اس کی ایمبیڈڈ فائل کے ساتھ چلائیں۔