مقایسه بهترین RSS readerهای خودمیزبان برای VPS

کدام RSS reader خودمیزبان برای یک VPS کوچک مناسب است

Miniflux بهترین RSS reader خودمیزبان برای نصب روی یک VPS کوچک است. این برنامه تنها شامل یک فایل باینری Go در کنار PostgreSQL است. این ابزار از APIهای Fever و Google Reader پشتیبانی می‌کند، بنابراین اپلیکیشن‌های موبایل شخص‌ثالث به آن متصل می‌شوند و ارتقای آن تنها با یک docker compose pull انجام می‌شود. اگر به افزونه‌ها و یک کانتینر واحد با دیتابیس داخلی SQLite نیاز دارید، FreshRSS را انتخاب کنید.

پنج RSS reader ارزش فضای دیسک در یک VPS را دارند: Miniflux، FreshRSS، CommaFeed، yarr و Tiny Tiny RSS. این صفحه تفاوت‌های واقعی آن‌ها را مقایسه می‌کند: میزان حافظه مورد نیاز هر پشته (stack)، دیتابیسی که هر کدام به شما تحمیل می‌کنند، API همگام‌سازی که اپلیکیشن موبایل شما به آن نیاز دارد و اتفاقاتی که در روز ارتقا رخ می‌دهد. تمام ارقام ذکر شده در اینجا یا توسط خود پروژه منتشر شده‌اند و یا حاصل محاسبات ساده هستند و متن مشخص می‌کند که کدام مورد است. هیچ‌کدام از این‌ها بنچمارک سخت‌افزار شما نیستند، بنابراین سرور خود را با docker stats اندازه‌گیری کنید.

پنج خواننده، هر کدام در یک پاراگراف

Miniflux با زبان Go نوشته شده و به صورت یک فایل باینری کامپایل‌شدهٔ ایستا عرضه می‌شود. مستندات آن در مورد تنها وابستگی سخت‌افزاری‌اش صریح است: «فقط با PostgreSQL کار می‌کند». حالت SQLite وجود ندارد. این سرویس یک REST API، یک API سازگار با Fever و یک API سازگار با Google Reader، به‌علاوه قابلیت وارد کردن و خروجی گرفتن OPML ارائه می‌دهد. جستجوی متن کامل به PostgreSQL سپرده شده است که بخشی از دلیل غیرقابل‌حذف بودن پایگاه داده است.

FreshRSS با PHP نوشته شده و به صورت یک کانتینر اجرا می‌شود که هم وب‌سرور و هم برنامه را در خود جای داده است. SQLite پایگاه داده پیش‌فرض است و به سرویس دومی نیاز ندارد، در حالی که PostgreSQL و MySQL برای نصب‌های بزرگ‌تر پشتیبانی می‌شوند. این برنامه از APIهای Google Reader و Fever پشتیبانی می‌کند. نصب آن قبلاً در راهنمای ما برای نصب FreshRSS روی VPS پوشش داده شده است، بنابراین این صفحه به‌جای تکرار مراحل نصب، به مقایسه آن می‌پردازد.

CommaFeed با Java روی Quarkus ساخته شده و طرح‌بندی آن از Google Reader کپی‌برداری شده است. پایگاه داده آن در زمان build انتخاب می‌شود، نه در زمان اجرا؛ بنابراین پروژه برای هر پایگاه داده یک image منتشر می‌کند: athou/commafeed:latest-h2 برای پایگاه داده تعبیه‌شده H2، athou/commafeed:latest-postgresql برای PostgreSQL، و نسخه‌های دیگر برای MySQL و MariaDB. این سرویس یک REST API و یک API سازگار با Fever ارائه می‌دهد.

yarr (مخفف yet another rss reader) یک فایل باینری Go با SQLite تعبیه‌شده است و اصلاً به کانتینر نیاز ندارد. دستور ساده ./yarr روی پورت 127.0.0.1:7070 گوش می‌دهد. فلگ‌ها کوتاه هستند: -addr 0.0.0.0:7070 -auth alice:secret آن را با یک رمز عبور در شبکه در دسترس قرار می‌دهد و -db /data/yarr.db پایگاه داده را در مسیر دلخواه شما قرار می‌دهد. این برنامه دارای یک API سازگار با Fever است. جدیدترین نسخه تگ‌شده آن 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 است و هیچ سرور پایگاه‌داده یا runtime زبان برنامه‌نویسی در زیرمجموعه خود ندارد. Miniflux به 320 MB حافظه در 2 کانتینر نیاز دارد که بخش عمده آن متعلق به PostgreSQL است تا خود Miniflux. برنامه Tiny Tiny RSS با 640 MB در 4 کانتینر، یک مورد استثنا محسوب می‌شود؛ زیرا برنامه، به‌روزرسان، پایگاه‌داده و وب‌سرور، چهار پردازش مجزا با چهار heap حافظه جداگانه هستند.

این مقادیر را به عنوان محدودیت‌های واقعی تنظیم کنید، نه صرفاً یک امیدواری. محدودیت‌های حافظه در Docker Compose نحو (syntax) این کار و رفتار کانتینر هنگام رسیدن به سقف حافظه را توضیح می‌دهد. کانتینری که هیچ محدودیتی ندارد، در صورت پر شدن حافظه سرور به شکلی نرم و کنترل‌شده از کار نمی‌افتد؛ بلکه هسته سیستم‌عامل یک پردازش را به عنوان قربانی انتخاب کرده و آن را می‌کشد (kill می‌کند)، و معمولاً آن قربانی، همان کانتینری نیست که باعث فشار بر حافظه شده است.

پایگاه‌داده‌ای که هر ابزار به شما تحمیل می‌کند

پایگاه‌داده بزرگ‌ترین تفاوت عملیاتی میان این 5 گزینه است. این تصمیم از هر تفاوتی در رابط کاربری مهم‌تر است، زیرا رویه پشتیبان‌گیری و ریسک ارتقای شما را تعیین می‌کند.

استفاده از PostgreSQL برای Miniflux و نسخه رسمی Tiny Tiny RSS الزامی است. این انتخاب قابلیت جستجوی تمام‌متن (full text search) واقعی و نوشتن همزمان ایمن را فراهم می‌کند. هزینه آن، یک کانتینر اضافه، یک volume و یک مشکل تکرارشونده است: ایمیج‌های رسمی PostgreSQL نمی‌توانند داده‌ها را به‌صورت درجا (in-place) بین نسخه‌های اصلی (major versions) مهاجرت دهند. مستندات Tiny Tiny RSS مستقیماً به این موضوع اشاره کرده و هشدار می‌دهد که «کانتینرهای رسمی PostgreSQL هیچ پشتیبانی برای مهاجرت داده بین نسخه‌های اصلی ندارند». گزینه‌های واقع‌بینانه شما این است که نسخه اصلی قدیمی را ثابت نگه دارید (pin)، یا با استفاده از pg_dump و pg_restore عملیات dump و restore را انجام دهید. برای انجام این کار هر یک یا دو سال یک‌بار برنامه‌ریزی کنید.

SQLite گزینه پیش‌فرض FreshRSS و yarr است. یک فایل واحد، بدون نیاز به سرور، پورت یا رمز عبور. این پایگاه‌داده برای یک کاربر با چند صد فید به‌خوبی عمل می‌کند، اما زمانی که چندین کاربر همزمان داده می‌نویسند سرعت آن کاهش می‌یابد؛ این همان نقطه‌ای است که گزینه PostgreSQL در FreshRSS ارزش خود را نشان می‌دهد. ابزار yarr در نسخه v2.7 پشتیبانی اختیاری از PostgreSQL را اضافه کرد، اما استفاده از فایل تعبیه‌شده (embedded) روش معمول اجرای آن است.

پایگاه‌داده H2 گزینه پیش‌فرض و تعبیه‌شده CommaFeed است و پیش از شروع کار، ارزش کمی تأمل دارد، زیرا CommaFeed پایگاه‌داده خود را در زمان ساخت ایمیج انتخاب می‌کند. مهاجرت از H2 به PostgreSQL در مراحل بعدی، صرفاً یک تغییر پیکربندی نیست. این کار نیازمند استفاده از یک ایمیج متفاوت به همراه مهاجرت داده است که باید شخصاً آن را انجام دهید؛ بنابراین پیش از آنکه یک سال تاریخچه مطالعه در سیستم داشته باشید، در این مورد تصمیم‌گیری کنید.

آیا اپلیکیشن موبایل شما کار می‌کند

این پرسش بیش از آنچه تصور می‌شود اهمیت دارد، زیرا رابط وب تنها نیمی از نحوه استفاده از یک خبرخوان (feed reader) است.

Miniflux از API سازگار با Fever و API سازگار با Google Reader پشتیبانی می‌کند، بنابراین اکثر کلاینت‌های iOS و Android به آن متصل می‌شوند. FreshRSS نیز از همین دو API پشتیبانی می‌کند و مستندات آن، این دو را رتبه‌بندی کرده است: API مربوط به Google Reader با پشتیبانی کامل از قابلیت‌ها «بهترین» گزینه است، در حالی که API مربوط به Fever «قابلیت‌های محدود و عملکردی کم‌بازده‌تر» دارد. همچنین FreshRSS پیش از آنکه هر اپلیکیشنی بتواند وارد شود، به دو مرحله نیاز دارد. گزینه "Allow API access (required for mobile apps)" را در بخش Authentication فعال کنید، سپس یک API password در پروفایل کاربری بسازید. نادیده گرفتن تنظیم API password باعث شکست در احراز هویت اپلیکیشن می‌شود، در حالی که ورود از طریق وب همچنان کار می‌کند؛ این موضوع تا زمانی که ندانید باید کجا را بررسی کنید، گیج‌کننده است.

CommaFeed و yarr هر دو فقط API سازگار با Fever را ارائه می‌دهند و هیچ گزینه دیگری ندارند، بنابراین با کلاینت‌های دارای قابلیت Fever کار می‌کنند و با اپلیکیشن‌هایی که فقط از Google Reader پشتیبانی می‌کنند، سازگار نیستند. در مقابل، Tiny Tiny RSS API اختصاصی خود را دارد، به این معنی که شما به کلاینتی نیاز دارید که مخصوص آن نوشته شده باشد. پیش از آنکه 300 فید را در خبرخوان خود وارد کنید، بررسی کنید که آیا اپلیکیشن مورد نظر شما از آن پشتیبانی می‌کند یا خیر.

یک فایل compose کاربردی برای سرور 1 گیگابایتی

این پشته Miniflux است که از نمونه Docker خود پروژه تا اوت 2026 اقتباس شده است. پورت منتشرشده به loopback محدود شده، آدرس گوش‌دادن به‌طور صریح تنظیم شده و هر دو کانتینر دارای محدودیت حافظه هستند.

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 مواجه می‌شوید. مسیر volume یعنی /var/lib/postgresql با PostgreSQL 18 مطابقت دارد؛ نسخه 17 و قبل از آن داده‌ها را در /var/lib/postgresql/data ذخیره می‌کنند و mount کردن مسیر اشتباه به این معنی است که دایرکتوری داده اصلاً روی volume قرار ندارد، بنابراین با بازسازی مجدد کانتینر، همه چیز ناپدید می‌شود. 127.0.0.1:8080:8080 پورت را از اینترنت عمومی دور نگه می‌دارد، زیرا انتشار یک پورت بدون تعیین آدرس، قانونی را در زنجیره‌ای می‌نویسد که ufw آن را مدیریت نمی‌کند. دور زدن ufw توسط پورت‌های Docker این مکانیزم را توضیح می‌دهد و یک reverse proxy از نوع Traefik روشی است که می‌توانید TLS را جلوی آن قرار دهید.

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

docker compose ps باید هر دو سرویس را در حال اجرا نشان دهد، در حالی که دیتابیس با healthy علامت‌گذاری شده است. اولین اجرای Miniflux مهاجرت‌های schema را لاگ می‌کند که همان چیزی است که RUN_MIGRATIONS=1 فعال می‌کند. docker stats --no-stream ستون حافظه زنده را چاپ می‌کند و این عددی است که باید با سقف‌های تعیین‌شده در جدول بالا مقایسه شود. اگر کانتینر Miniflux در یک حلقه مدام restart می‌شود، لاگ آن را بخوانید: connect: connection refused به این معنی است که پیش از آماده‌شدن PostgreSQL برای پذیرش اتصالات شروع شده است، که دقیقاً همان چیزی است که شرط service_healthy از آن جلوگیری می‌کند؛ بنابراین بررسی کنید که آیا این شرط پس از ویرایش‌های شما باقی مانده است یا خیر. اگر Compose برای شما جدید است، مبانی Docker Compose روی VPS ابتدا ساختار فایل را پوشش می‌دهد.

چه مواردی روی یک سرور 1 GB جا نمی‌شوند

سرویس Tiny Tiny RSS گزینه‌ای است که باید از آن صرف‌نظر کنید. پشتهٔ چهار سرویسی رسمی آن روی یک VPS با 1 GB رم تنها در صورتی اجرا می‌شود که آن سرور هیچ کار دیگری انجام ندهد؛ این سرویس در کنار یک برنامهٔ دیگر مبتنی بر دیتابیس و یک reverse proxy اجرا نخواهد شد. چهار سرویس به معنای چهار مجموعه سربار است و یکی از آن‌ها 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: ایمیج جدید را pull کنید. با استفاده از SQLite، موتور پایگاه‌داده‌ای برای ارتقا وجود ندارد، بنابراین خرابی‌های معمول ناشی از افزونه‌های شخص ثالثی است که به‌روزرسانی نشده‌اند.
• CommaFeed: واریانت ایمیجی را pull کنید که با پایگاه‌داده شما مطابقت دارد. تغییر از latest-h2 به latest-postgresql داده‌های شما را منتقل نمی‌کند.
• yarr: فایل باینری را جایگزین کرده و فایل پایگاه‌داده را نگه دارید. از آنجا که از v2.8 در ژوئیه 2024 هیچ نسخه‌ای منتشر نشده (بررسی‌شده در اوت 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 کیلوبایت حجم برای هر پاسخ می‌گذارند. ترافیک واقعی زمانی که سرور به درخواست‌های شرطی پاسخ می‌دهد کمتر، و زمانی که فیدها متن کامل مقالات را حمل می‌کنند بیشتر است.

[
  {
    "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
  }
]

یک بازهٔ 5 دقیقه‌ای برای 100 فید برابر با 864,000 درخواست و تقریباً 34.6 گیگابایت در ماه است. نظرسنجی ساعتی برابر با 72,000 درخواست و حدود 2.9 گیگابایت است. Miniflux با تنظیم POLLING_FREQUENCY روی 60 دقیقه عرضه می‌شود که ردیف آخر آن جدول است و این مقدار پیش‌فرض برای تقریباً همه مناسب است. یک مقاله با درخواست مکرر شما، زودتر از موعد به دستتان نمی‌رسد.

درخواست‌های شرطی همان چیزی هستند که عدد واقعی را کمتر از مقدار محاسباتی نگه می‌دارند. خواننده‌ای که هدرهای ETag و Last-Modified بازگشتی از فید را ذخیره می‌کند، آن‌ها را در قالب If-None-Match و If-Modified-Since به سرور بازمی‌گرداند و سروری که محتوای جدیدی ندارد، با 304 Not Modified و بدون بدنه (body) پاسخ می‌دهد. اتصال همچنان هزینهٔ یک handshake را دارد، اما هزینهٔ payload را خیر. فیدهایی که درخواست‌های شرطی را نادیده می‌گیرند، هر بار کل سند را برای شما می‌فرستند؛ بنابراین چند فید حجیم می‌توانند به تنهایی هزینهٔ انتقال دادهٔ شما را تحت تأثیر قرار دهند.

نظرسنجی شدید (Polling hard) باعث مسدود شدن شما نیز می‌شود. سروری که تشخیص دهد در حال بمباران آن هستید، با 429 Too Many Requests پاسخ می‌دهد و برخی سایت‌ها به جای آن 403 را برمی‌گردانند. Miniflux آخرین خطا را برای خودِ فید ثبت می‌کند، بنابراین وقتی یک فید به‌روزرسانی نمی‌شود اما بقیه به کار خود ادامه می‌دهند، لیست فیدها اولین جایی است که باید بررسی کنید.

فیدها از بین می‌روند و فایل OPML یک نسخه پشتیبان نیست

فیدها سریع‌تر از آنچه تصور می‌کنید دچار فرسودگی می‌شوند. دامنه‌ها منقضی می‌شوند، سایت‌ها به پلتفرم‌هایی بدون فید مهاجرت می‌کنند و URLهایی که قبلاً XML ارائه می‌دادند، شروع به نمایش یک صفحه خطای HTML با وضعیت 200 OK می‌کنند. مورد آخر دردسرساز است: عملیات دریافت (fetch) با موفقیت انجام می‌شود، اما تجزیه (parse) شکست می‌خورد و RSS reader شما به‌جای خطای شبکه، خطای تجزیه ثبت می‌کند. سالی یک‌بار، لیست فیدها را بر اساس آخرین به‌روزرسانی مرتب کنید و مواردی که خاموش شده‌اند را حذف کنید.

خروجی OPML فقط لیست اشتراک‌های شماست. این فایل شامل URL فیدها و نام پوشه‌هاست. این فایل وضعیت خوانده‌شده‌ها، مقالات ستاره‌دار، تنظیمات اختصاصی هر فید، قوانین فیلتر یا متن مقالاتی که ذخیره کرده‌اید را در بر نمی‌گیرد. اگر این OPML را در یک نصب تازه وارد کنید، فیدهای خود را بازمی‌یابید، اما تمام مقالاتی که قبلاً خوانده‌اید دوباره به‌عنوان خوانده‌نشده علامت‌گذاری می‌شوند.

نسخه پشتیبانی که اهمیت دارد، دیتابیس است. برای PostgreSQL، دستور pg_dump که در بالا ذکر شد، تمام کاری است که باید انجام دهید. برای RSS readerهایی که از SQLite استفاده می‌کنند مانند FreshRSS یا yarr، ابتدا فرآیند نوشتن را متوقف کرده و فایل را کپی کنید، یا در حین اجرا از دستور sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" برای تهیه یک کپی منسجم استفاده کنید. یک دستور cp ساده روی دیتابیسی که در حال نوشتن است، ممکن است فایلی تولید کند که بعداً باز نشود، زیرا کپی ممکن است شامل یک عملیات نوشتن نیمه‌کاره باشد. سپس این فایل‌ها را طبق یک زمان‌بندی مشخص از سرور خارج کنید؛ این همان کاری است که پشتیبان‌گیری restic روی VPS برای آن طراحی شده است. حداقل یک‌بار عملیات بازیابی را در یک کانتینر آزمایشی انجام دهید تا مطمئن شوید که فرآیند به‌درستی کار می‌کند.

یک RSS reader یکی از ارزان‌ترین سرویس‌هایی است که می‌توانید شخصاً میزبانی کنید؛ به همین دلیل است که در تمام لیست‌های سرویس‌های ارزشمند برای self-hosting در سال 2026 دیده می‌شود. یک نمونه SearXNG خودمیزبان در کنار آن قرار دهید تا هم مطالعه و هم جستجوی شما روی سخت‌افزاری باقی بماند که کنترل آن در دست خودتان است.

FAQ

کدام RSS reader خودمیزبان (self-hosted) کمترین حافظه را مصرف می‌کند؟

yarr. این برنامه یک فایل باینری واحد به زبان Go است که SQLite در آن کامپایل شده است؛ بنابراین هیچ سرور دیتابیس یا runtime زبان دیگری در کنار آن وجود ندارد و سقف حافظه 128 MB برای آن کاملاً کافی است. هزینهٔ این سادگی، در نگهداری و قابلیت‌هاست: آخرین نسخهٔ آن v2.8 است که در ژوئیه 2024 منتشر شده و فقط از Fever API پشتیبانی می‌کند. اگر به دنبال پروژه‌ای با توسعهٔ فعال و مصرف مشابه هستید، Miniflux به همراه PostgreSQL با مصرف 320 MB گزینهٔ بهتری است.

آیا می‌توانم یک RSS reader خودمیزبان را روی یک VPS با 1 GB رم اجرا کنم؟

بله. Miniflux به همراه PostgreSQL در صورتی که mem_limit را روی هر دو کانتینر تنظیم کنید، در حدود 320 MB جا می‌گیرد و FreshRSS با SQLite نیز در یک کانتینر جای می‌گیرد. موردی که باید روی 1 GB رم از آن اجتناب کنید، stack رسمی Tiny Tiny RSS است که شامل 4 سرویس از جمله PostgreSQL اختصاصی خودش است. همیشه محدودیت حافظه (memory limit) را تنظیم کنید، زیرا اگر یک کانتینر بدون محدودیت روی سروری که حافظه‌اش پر شده اجرا شود، هستهٔ سیستم‌عامل (kernel) یکی از پردازش‌ها را می‌کشد و معمولاً پردازشی که انتخاب می‌شود دیتابیس است، نه اپلیکیشنی که باعث پر شدن حافظه شده است.

کدام‌یک از این‌ها با اپلیکیشن‌های RSS در iOS و Android کار می‌کنند؟

Miniflux و FreshRSS هر دو از API سازگار با Fever و API سازگار با Google Reader پشتیبانی می‌کنند، بنابراین تقریباً هر کلاینت موبایلی به آن‌ها متصل می‌شود. CommaFeed و yarr فقط Fever API را ارائه می‌دهند. Tiny Tiny RSS از API اختصاصی خود استفاده می‌کند، بنابراین به کلاینتی نیاز دارید که برای آن ساخته شده باشد. در FreshRSS باید دسترسی API را در بخش Authentication فعال کنید و یک رمز عبور جداگانه برای API در پروفایل تنظیم کنید، در غیر این صورت اپلیکیشن نمی‌تواند لاگین کند، در حالی که وب‌سایت همچنان کار می‌کند.

آیا خروجی OPML یک نسخه پشتیبان از RSS reader من محسوب می‌شود؟

خیر. OPML فقط شامل URL فیدها و پوشه‌هاست و تنها لیست اشتراک‌های شما را بازسازی می‌کند. وضعیت خوانده‌شده‌ها، آیتم‌های ستاره‌دار، قوانین فیلتر و متن مقالات همگی در دیتابیس ذخیره می‌شوند. برای تهیه نسخه پشتیبان، خودِ دیتابیس را با pg_dump برای PostgreSQL یا دستور .backup برای SQLite بک‌آپ بگیرید و فایل خروجی را از سرور خارج کنید.

آیا Miniflux از SQLite پشتیبانی می‌کند؟

خیر. مستندات پروژه بیان می‌کند که این برنامه «فقط با PostgreSQL کار می‌کند» و قابلیت جستجوی متن کامل (full text search) با استفاده از ویژگی‌های PostgreSQL پیاده‌سازی شده است، بنابراین حالت سبک‌تری برای تغییر وجود ندارد. اگر به دنبال یک feed reader بدون کانتینر دیتابیس هستید، FreshRSS را با backend پیش‌فرض آن یعنی SQLite یا yarr را با فایل تعبیه‌شده‌اش اجرا کنید.