چھوٹے VPS کے لیے بہترین self-hosted RSS reader کون سا ہے؟

کون سا 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 کے ذریعے کریں۔

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

Miniflux Go میں لکھا گیا ہے اور ایک واحد statically compiled binary کے طور پر جاری ہوتا ہے۔ اس کی documentation ایک بنیادی dependency کے بارے میں واضح ہے: یہ "صرف PostgreSQL کے ساتھ کام کرتا ہے"۔ SQLite mode موجود نہیں ہے۔ اس میں REST API، Fever compatible API اور Google Reader compatible API کے علاوہ OPML import اور export بھی موجود ہیں۔ Full text search PostgreSQL کو سونپی جاتی ہے، اور یہی ایک وجہ ہے کہ database optional نہیں ہے۔

FreshRSS PHP ہے اور ایک ایسے container کے طور پر چلتا ہے جس میں web server اور application دونوں شامل ہیں۔ SQLite default database ہے اور اسے دوسری service کی ضرورت نہیں ہوتی، جبکہ بڑی installations کے لیے PostgreSQL اور MySQL supported ہیں۔ یہ Google Reader API اور Fever API استعمال کرتا ہے۔ اسے install کرنے کا طریقہ پہلے ہی VPS پر ہمارے FreshRSS walkthrough میں دیا جا چکا ہے، اس لیے یہ page install کا طریقہ دہرانے کے بجائے اس کا موازنہ کرتا ہے۔

CommaFeed Quarkus پر Java ہے اور اس کا layout Google Reader کی نقل کرتا ہے۔ اس کا database runtime کے بجائے build time پر منتخب کیا جاتا ہے، اس لیے project ہر database کے لیے ایک image شائع کرتا ہے: embedded H2 database کے لیے athou/commafeed:latest-h2، PostgreSQL کے لیے athou/commafeed:latest-postgresql، اور MySQL اور MariaDB کے لیے مزید variants۔ یہ tags natively compiled builds ہیں، جبکہ -jvm suffix ان variants کی نشاندہی کرتا ہے جو JVM پر چلتے ہیں۔ یہ REST API اور Fever compatible API فراہم کرتا ہے، اور version 7.3.0 (August 2026) سے Google Reader compatible API بھی فراہم کرتا ہے۔

yarr (yet another rss reader) ایک Go binary ہے جس میں SQLite embedded ہے، اور اسے کسی container کی ضرورت نہیں ہوتی۔ سادہ ./yarr، 127.0.0.1:7070 پر listen کرتا ہے۔ اس کے flags مختصر ہیں: -addr 0.0.0.0:7070 -auth alice:secret اسے password کے پیچھے network کے لیے کھولتا ہے، اور -db /data/yarr.db database کو آپ کی مطلوبہ جگہ پر رکھتا ہے۔ اس میں Fever compatible API موجود ہے۔ اس کی تازہ ترین tagged release September 2026 کی v2.9 ہے، جسے October 2026 میں check کیا گیا؛ اس سے پہلے June میں v2.7 اور July میں v2.8 جاری ہوئے تھے، اس لیے project دوبارہ فعال طور پر develop ہو رہا ہے۔

Tiny Tiny RSS ان پانچوں میں سب سے پرانا اور چلانے کے لحاظ سے سب سے بھاری ہے۔ tt-rss.org پر اصل project 1 November 2025 کو retired ہو گیا، اور development community fork میں github.com/tt-rss/tt-rss پر جاری ہے، جس کی documentation اب official setup ہے۔ اس setup میں چار services شامل ہیں: PostgreSQL container، PHP-FPM application container، feeds fetch کرنے والا الگ updater container، اور سامنے nginx container۔ Documentation واضح طور پر کہتی ہے کہ "یہ setup PostgreSQL استعمال کرتا ہے"۔ اس کی اپنی JSON API ہے، جسے اس کا Android client اور کئی third-party apps استعمال کرتے ہیں۔ 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) کا احاطہ کرتا ہے اور یہ بتاتا ہے کہ جب کوئی کنٹینر اپنی حد تک پہنچ جاتا ہے تو کیا ہوتا ہے۔ بغیر حد والا کنٹینر مکمل بھرے ہوئے باکس پر شائستگی سے فیل نہیں ہوتا: کرنل ایک شکار پروسیس کا انتخاب کر کے اسے ختم کر دیتا ہے، اور اکثر وہ شکار وہ کنٹینر نہیں ہوتا جس نے دباؤ پیدا کیا ہوتا ہے۔

ہر reader آپ پر کون سا database مسلط کرتا ہے

ان پانچوں میں operational فرق سب سے زیادہ database کی وجہ سے ہے۔ یہ user interface کے کسی بھی فرق سے بڑا فیصلہ ہے، کیونکہ اسی سے آپ کا backup procedure اور upgrade risk طے ہوتا ہے۔

Miniflux اور official Tiny Tiny RSS setup کے لیے PostgreSQL ضروری ہے۔ اس کے بدلے حقیقی full text search اور محفوظ concurrent writes ملتی ہیں۔ اس کی قیمت ایک دوسرے container، ایک volume، اور ایک مستقل مسئلہ ہے: official PostgreSQL images major versions کے درمیان data کو in place migrate نہیں کر سکتیں۔ Tiny Tiny RSS documentation یہ بات براہ راست کہتی ہے اور خبردار کرتی ہے کہ "official PostgreSQL containers have no support for migrating data between major versions"۔ Feed reader کے لیے آپ کے عملی اختیارات یہ ہیں کہ پرانی major version کو pin کریں، یا pg_dump اور pg_restore کے ذریعے dump اور restore کریں۔ PostgreSQL pg_upgrade اور replication-based upgrades بھی document کرتا ہے۔ یہ اضافی setup ان بڑے databases کے لیے مفید ہے جہاں downtime اہم ہو، جبکہ feed reader کا database شاذونادر ہی ان میں شامل ہوتا ہے۔ ہر ایک یا دو سال میں ایک بار اس کی منصوبہ بندی کریں۔

SQLite، FreshRSS اور yarr کا default ہے۔ ایک file، کوئی server نہیں، کوئی port نہیں، کوئی password نہیں۔ چند سو feeds والے ایک شخص کے لیے یہ اچھی طرح کام کرتا ہے، اور جب کئی users بیک وقت write کرتے ہیں تو سست ہو جاتا ہے۔ اسی صورت میں FreshRSS کا PostgreSQL option مفید ثابت ہونا شروع ہوتا ہے۔ yarr نے v2.7 میں optional PostgreSQL support شامل کیا، لیکن اسے چلانے کا معمول کا طریقہ embedded file ہے۔

H2، CommaFeed کا embedded default ہے، اور شروع کرنے سے پہلے اس پر غور کرنا ضروری ہے، کیونکہ CommaFeed اپنا database image build ہونے کے وقت منتخب کرتا ہے۔ بعد میں H2 سے PostgreSQL پر منتقل ہونا configuration change نہیں ہے۔ یہ ایک مختلف image اور data migration ہے، جو آپ کو خود انجام دینی ہوگی۔ اس لیے box میں ایک سال کی read history جمع ہونے سے پہلے فیصلہ کر لیں۔

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

یہ سوال توقع سے زیادہ اہم ہے، کیونکہ feed reader استعمال کرنے کا طریقہ صرف web interface تک محدود نہیں ہوتا۔

Miniflux ایک Fever compatible API اور ایک Google Reader compatible API فراہم کرتا ہے، اس لیے زیادہ تر iOS اور Android clients اس سے connect ہو جاتے ہیں۔ FreshRSS بھی یہی دونوں APIs فراہم کرتا ہے، اور اس کی اپنی documentation ان کی درجہ بندی کرتی ہے: مکمل feature support کے ساتھ Google Reader API کو "best" قرار دیا گیا ہے، جبکہ Fever API کا رویہ "limited features and less efficient" ہے۔ کسی بھی app کے login کرنے سے پہلے FreshRSS میں دو steps بھی درکار ہیں۔ Authentication کے تحت "Allow API access (required for mobile apps)" enable کریں، پھر user profile میں API password بنائیں۔ API password نہ بنانے پر app میں authentication failure ظاہر ہوتی ہے، جبکہ web login کام کرتا رہتا ہے۔ یہ صورت حال اس وقت تک confusing رہتی ہے جب تک آپ کو معلوم نہ ہو کہ password کہاں بنانا ہے۔

CommaFeed اب دونوں APIs فراہم کرتا ہے۔ اس میں کافی عرصے سے Fever compatible API موجود ہے، اور version 7.3.0 میں ان apps کے لیے Google Reader compatible API شامل کی گئی جو Fever کو support نہیں کرتیں۔ اس لیے اگر آپ کی app صرف Google Reader API استعمال کرتی ہے تو 7.3.0 یا اس کے بعد کا version چلائیں۔ yarr صرف Fever compatible API فراہم کرتا ہے، اس لیے یہ Fever capable clients کے ساتھ کام کرتا ہے، لیکن ان apps کے ساتھ نہیں جو صرف Google Reader API استعمال کرتی ہیں۔ Tiny Tiny RSS اس کے بجائے اپنی API فراہم کرتا ہے، اس لیے آپ کو اسی کے لیے لکھی گئی client درکار ہوگی۔ اس میں 300 feeds import کرنے سے پہلے تصدیق کریں کہ آپ کی پسندیدہ app اس reader کو support کرتی ہے۔

1 GB والے سرور کے لیے کام کرنے والی compose فائل

یہ Miniflux stack ہے، جسے اکتوبر 2026 تک project کی اپنی Docker مثال سے اخذ کیا گیا ہے۔ شائع کیا گیا port loopback سے bind ہے، listen address واضح طور پر set کیا گیا ہے، اور دونوں containers پر memory limit عائد ہے۔

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:

اس فائل میں تین lines ایسی ہیں جن میں لوگ عموماً غلطی کرتے ہیں۔ LISTEN_ADDR=0.0.0.0:8080 وہی configuration دوبارہ set کرتا ہے جو official image پہلے ہی اپنے Dockerfile میں set کرتی ہے، اس لیے miniflux/miniflux کے ساتھ یہ fix کے بجائے بے ضرر حفاظتی انتظام ہے۔ یہ اس وقت اہم ہوتا ہے جب آپ اپنی image build کریں یا packaged binary چلائیں، کیونکہ binary کا documented default 127.0.0.1:8080 ہے۔ Container کے اندر loopback سے bound process تک published port کے ذریعے رسائی نہیں ہو سکتی، اس لیے container بظاہر healthy ہونے کے باوجود connection reset ملتا ہے۔ Volume path /var/lib/postgresql PostgreSQL 18 سے مطابقت رکھتا ہے؛ version 17 اور اس سے پہلے کے versions data کو /var/lib/postgresql/data میں محفوظ کرتے ہیں۔ غلط path mount کرنے کا مطلب ہے کہ data directory volume پر موجود ہی نہیں، اس لیے container دوبارہ create ہونے پر تمام data غائب ہو جاتا ہے۔ 127.0.0.1:8080:8080 port کو public internet سے دور رکھتا ہے، کیونکہ address کے بغیر port publish کرنے سے ایسی chain میں rule شامل ہو جاتا ہے جسے ufw manage نہیں کرتا۔ Docker ports ufw کو bypass کرتے ہیں اس mechanism کی وضاحت کرتا ہے، جبکہ Traefik reverse proxy اس کے سامنے TLS رکھنے کا طریقہ ہے۔

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps میں دونوں services running کے طور پر ظاہر ہونی چاہئیں، اور database کو healthy کے طور پر نشان زد ہونا چاہیے۔ Miniflux کا پہلی بار start ہونا اپنی schema migrations کو log کرتا ہے، اور RUN_MIGRATIONS=1 اسی عمل کو trigger کرتا ہے۔ docker stats --no-stream live memory column دکھاتا ہے، اور یہی وہ number ہے جس کا اوپر موجود chart کی limits سے موازنہ کرنا چاہیے۔ اگر Miniflux container بار بار restart ہو، تو اس کا log پڑھیں: connect: connection refused کا مطلب ہے کہ یہ PostgreSQL کے connections قبول کرنے کے لیے ready ہونے سے پہلے start ہو گیا۔ یہی صورت حال service_healthy condition روکتی ہے، اس لیے تصدیق کریں کہ edits کے بعد condition برقرار ہے۔ اگر Compose آپ کے لیے نیا ہے تو VPS پر Docker Compose کی بنیادی باتیں پہلے file layout سمجھاتی ہیں۔

1 GB کے سرور پر کیا نہیں چلے گا

Tiny Tiny RSS کو چھوڑ دینا چاہیے۔ اس کا سرکاری four service stack، 1 GB VPS پر تب چلتا ہے جب وہ VPS کوئی اور کام نہ کر رہا ہو۔ یہ اسی VPS پر کسی دوسری database-backed application اور reverse proxy کے ساتھ نہیں چلتا۔ چار services کا مطلب overhead کے چار مجموعے ہیں، اور ان میں سے ایک PostgreSQL ہے۔

CommaFeed چل جاتا ہے، لیکن صرف H2 image اور 256 MB cap کے ساتھ، جو project کی اپنی example میں مقرر ہے۔ چھوٹے server پر مسئلہ اس وقت پیدا ہوتا ہے جب CommaFeed کے ساتھ الگ database server بھی چلایا جائے۔ -jvm image variants صورتحال کو مزید خراب بناتے ہیں، کیونکہ project کی documentation خبردار کرتی ہے کہ JVM default طور پر زیادہ memory استعمال کرتا ہے اور غیر استعمال شدہ memory operating system کو واپس نہیں کرتا۔ latest-h2 اور latest-postgresql tags native builds ہیں، جنہیں project کم memory استعمال کرنے کی وجہ سے تجویز کرتا ہے۔ اس لیے انہی پر رہیں، جب تک JVM چلانے کی کوئی خاص وجہ نہ ہو۔

جب server میں memory ختم ہو جاتی ہے تو kernel کا out of memory killer کسی process کا انتخاب کرکے اسے terminate کر دیتا ہے۔ dmesg -T ایسی line دکھاتا ہے جیسی Out of memory: Killed process 1234 (java)، اور container docker compose ps سے بغیر کسی message کے غائب ہو جاتا ہے، کیونکہ application کو message لکھنے کا موقع ہی نہیں ملا۔

ہر ایک میں اپ گریڈ کا طریقۂ کار

• Miniflux: docker compose pull && docker compose up -d، اور RUN_MIGRATIONS=1 کے set ہونے پر start کے وقت schema migrations apply ہوتی ہیں۔ اپ گریڈ کا خطرہ Miniflux نہیں ہے۔ اصل خطرہ اس کے نیچے موجود PostgreSQL major version ہے۔
• FreshRSS: نئی image pull کریں۔ SQLite کے ساتھ upgrade کرنے کے لیے کوئی database engine نہیں ہوتا، اس لیے عام خرابی ان third-party extensions کی وجہ سے آتی ہے جو نئی version کے ساتھ ہم آہنگ نہیں رہیں۔
• CommaFeed: اپنی database کے مطابق image variant pull کریں۔ latest-h2 سے latest-postgresql پر منتقل ہونے سے آپ کا data منتقل نہیں ہوتا۔
• yarr: binary replace کریں اور database file برقرار رکھیں۔ Releases June، July اور September 2026 میں آئیں، اور October 2026 تک v2.9 جدید ترین release تھی، اس لیے وقتاً فوقتاً release page چیک کریں۔
• Tiny Tiny RSS: docker compose pull && docker compose up -d۔ Application container start پر خود کو update کرتا ہے، اور project کی FAQ schema update errors کو broken volume یا override setup سے منسلک کرتی ہے، اس لیے ایسی error ظاہر ہو تو پہلے ان چیزوں کو چیک کریں۔ اگر آپ کی compose file اب بھی retired tt-rss.org project سے images pull کرتی ہے تو اسے fork کی images پر منتقل کریں (Docker Hub پر supahgreg/tt-rss یا ghcr.io/tt-rss/tt-rss)۔

ان میں سے کسی بھی اپ گریڈ سے پہلے database 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 فیڈز پر 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 آخری ایرر کو فیڈ کے ساتھ ریکارڈ کرتا ہے، لہذا جب کوئی ایک فیڈ اپ ڈیٹ ہونا بند کر دے جبکہ باقی کام کر رہی ہوں، تو فیڈ لسٹ سب سے پہلے دیکھنے کی جگہ ہے۔

Feeds ختم ہو جاتے ہیں، اور OPML فائل backup نہیں ہوتی

Feeds آپ کی توقع سے زیادہ تیزی سے ناکارہ ہو جاتے ہیں۔ Domains کی میعاد ختم ہو جاتی ہے، sites ایسی platform پر منتقل ہو جاتی ہیں جہاں feed موجود نہیں ہوتی، اور جو URL پہلے XML فراہم کرتا تھا وہ 200 OK status کے ساتھ HTML error page فراہم کرنے لگتا ہے۔ آخری صورت قدرے پیچیدہ ہے: fetch کامیاب ہوتی ہے، parse ناکام ہو جاتا ہے، اور آپ کا reader network error کے بجائے parsing error درج کرتا ہے۔ سال میں ایک بار feed list کو last updated کے لحاظ سے sort کریں اور ان feeds کو delete کر دیں جو خاموش ہو چکی ہیں۔

OPML export آپ کی subscription list ہوتی ہے۔ ایک standard OPML file میں feed URLs اور folder names محفوظ ہوتے ہیں۔ FreshRSS اپنا XML namespace شامل کرتا ہے، جس میں ہر feed کی settings بھی محفوظ ہوتی ہیں، مثلاً refresh interval، XPath scraping selectors اور auto-read filters؛ لیکن کوئی بھی OPML export read state، starred articles یا وہ article text محفوظ نہیں کرتا جسے آپ نے save کیا ہو۔ اس OPML کو fresh install میں import کرنے پر آپ کی feeds واپس آ جاتی ہیں، لیکن آپ کے پڑھے ہوئے ہر article کو دوبارہ unread نشان زد کیا جاتا ہے۔

اہم backup database کا ہوتا ہے۔ PostgreSQL کے لیے اوپر دیا گیا pg_dump command ہی مکمل طریقہ ہے۔ FreshRSS یا yarr جیسے SQLite reader کے لیے writer کو stop کر کے file copy کریں، یا service کے چلتے ہوئے sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" کے ذریعے consistent copy لیں۔ جس database میں write جاری ہو، اس کا سادہ cp کرنے سے ایسی file بن سکتی ہے جو بعد میں open نہ ہو، کیونکہ copy میں ادھوری write شامل ہو سکتی ہے۔ پھر مقررہ schedule کے مطابق ان files کو server سے باہر منتقل کریں۔ VPS پر restic backups اسی مقصد کے لیے ہیں۔ کم از کم ایک بار کسی backup کو scratch container میں restore کریں، تاکہ آپ کو معلوم ہو کہ طریقۂ کار کام کرتا ہے۔

Feed reader ان services میں سے ہے جنہیں خود چلانا سب سے کم لاگت میں ممکن ہے۔ اسی لیے یہ 2026 میں self-host کرنے کے قابل چیزوں کی ہر فہرست میں شامل ہوتا ہے۔ اس کے ساتھ self-hosted SearXNG instance چلائیں، تاکہ reading اور searching دونوں ایسے hardware پر رہیں جسے آپ control کرتے ہیں۔

FAQ

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

yarr۔ یہ ایک single Go binary ہے جس میں SQLite شامل ہے، اس لیے اس کے ساتھ نہ database server درکار ہے اور نہ کوئی الگ language runtime، اور 128 MB کی حد کافی رہتی ہے۔ اس کے عوض features محدود ہیں: یہ صرف Fever API استعمال کرتا ہے، اور اس کا تازہ ترین release ستمبر 2026 کا v2.9 ہے۔ اگر آپ اسی کے قریب memory footprint میں Google Reader API support اور full text search چاہتے ہیں تو 320 MB پر PostgreSQL کے ساتھ Miniflux بہتر انتخاب ہے۔

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

ہاں۔ جب آپ دونوں containers پر mem_limit set کرتے ہیں تو PostgreSQL کے ساتھ Miniflux تقریباً 320 MB کے اندر چلتا ہے، جبکہ SQLite کے ساتھ FreshRSS ایک container میں چلتا ہے۔ 1 GB پر official Tiny Tiny RSS stack سے گریز کریں، کیونکہ اس میں اس کے اپنے PostgreSQL سمیت 4 services شامل ہوتی ہیں۔ ہمیشہ memory limits set کریں، کیونکہ مکمل طور پر بھرے ہوئے host پر unlimited container کے کسی process کو kernel ختم کر سکتا ہے، اور اکثر منتخب کیا جانے والا process database کا ہوتا ہے، نہ کہ اصل application کا۔

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

Miniflux، FreshRSS اور CommaFeed 7.3.0 یا بعد کے versions Fever compatible API اور Google Reader compatible API، دونوں استعمال کرتے ہیں، اس لیے تقریباً کوئی بھی mobile client connect ہو جاتا ہے۔ 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 آپ کی subscription list دوبارہ بناتا ہے، اور FreshRSS کا extended export ہر feed کی settings اور filters بھی شامل کرتا ہے، لیکن read state، starred items اور article text سب database میں محفوظ ہوتے ہیں۔ PostgreSQL کے لیے pg_dump استعمال کرتے ہوئے database کا خود backup بنائیں، یا SQLite کے لیے .backup command استعمال کریں، اور حاصل شدہ file کو server سے باہر بھی copy کریں۔

کیا Miniflux SQLite support کرتا ہے؟

نہیں۔ project documentation کے مطابق یہ "works only with PostgreSQL" ہے، اور full text search PostgreSQL features کے ذریعے implement کی گئی ہے، اس لیے کسی ہلکے mode پر switch نہیں کیا جا سکتا۔ اگر آپ ایسا feed reader چاہتے ہیں جس کے لیے الگ database container بالکل نہ ہو تو FreshRSS کو اس کے default SQLite backend کے ساتھ، یا yarr کو اس کی embedded file کے ساتھ چلائیں۔