ছোট 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। যদি আপনার এক্সটেনশন এবং SQLite-সহ একটি কন্টেইনার প্রয়োজন হয়, তবে FreshRSS বেছে নিন।

VPS-এর ডিস্ক স্পেস ব্যবহারের যোগ্য পাঁচটি RSS reader হলো: Miniflux, FreshRSS, CommaFeed, yarr এবং Tiny Tiny RSS। এই পৃষ্ঠায় তাদের মূল পার্থক্যগুলো তুলনা করা হয়েছে: প্রতিটি স্ট্যাকের জন্য প্রয়োজনীয় মেমোরি, তাদের বাধ্যতামূলক ডাটাবেস, আপনার ফোন অ্যাপের জন্য প্রয়োজনীয় সিঙ্ক API এবং আপগ্রেডের সময় কী ঘটে। এখানে দেওয়া প্রতিটি সংখ্যা হয় প্রজেক্টের নিজস্ব প্রকাশনা থেকে নেওয়া অথবা সাধারণ গাণিতিক হিসাব, এবং টেক্সটে তা উল্লেখ করা হয়েছে। এটি আপনার হার্ডওয়্যারের কোনো বেঞ্চমার্ক নয়, তাই আপনার নিজের সার্ভারে docker stats ব্যবহার করে পরিমাপ করুন।

পাঁচটি রিডার, প্রতিটি একটি অনুচ্ছেদে

Miniflux Go ভাষায় লেখা এবং এটি একটি একক statically compiled binary হিসেবে রিলিজ হয়। এর ডকুমেন্টেশনে একটি হার্ড ডিপেন্ডেন্সি সম্পর্কে স্পষ্টভাবে বলা আছে: এটি "শুধুমাত্র PostgreSQL-এর সাথে কাজ করে"। এতে কোনো SQLite মোড নেই। এটি একটি REST API, Fever compatible API এবং Google Reader compatible API অফার করে, পাশাপাশি OPML ইমপোর্ট ও এক্সপোর্টের সুবিধা দেয়। ফুল টেক্সট সার্চের দায়িত্ব PostgreSQL-এর ওপর ন্যস্ত, আর এই কারণেই ডাটাবেসটি ঐচ্ছিক নয়।

FreshRSS হলো PHP-ভিত্তিক এবং এটি একটি একক কন্টেইনারে চলে যা ওয়েব সার্ভার ও অ্যাপ্লিকেশন উভয়কেই ধারণ করে। 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 binary যাতে SQLite এমবেড করা থাকে এবং এর কোনো কন্টেইনারের প্রয়োজন হয় না। সাধারণ ./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-এ যাচাইকৃত; তাই এটিকে সক্রিয়ভাবে ডেভেলপ হওয়া সফটওয়্যারের পরিবর্তে একটি সম্পন্ন সফটওয়্যার হিসেবে গণ্য করুন।

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 মেমোরি ব্যবহার করে। কারণ অ্যাপ্লিকেশন, আপডেটার, ডেটাবেস এবং ওয়েব সার্ভার—এই চারটি আলাদা প্রসেসের জন্য চারটি আলাদা হিপ (heap) মেমোরি প্রয়োজন হয়।

এগুলোকে কেবল প্রত্যাশা হিসেবে না রেখে বাস্তব সীমা হিসেবে সেট করুন। 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 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 password তৈরি করুন। API password তৈরি না করলে অ্যাপে authentication failure দেখাবে, যদিও ওয়েব লগইন ঠিকঠাক কাজ করবে; এটি বিভ্রান্তিকর হতে পারে যদি না আপনি জানেন কোথায় সমস্যাটি খুঁজতে হবে।

CommaFeed এবং yarr উভয়ই শুধুমাত্র Fever compatible API প্রকাশ করে, তাই এগুলো কেবল Fever সমর্থনকারী ক্লায়েন্টদের সাথেই কাজ করে, যেসব অ্যাপ শুধুমাত্র Google Reader সমর্থন করে সেগুলোতে কাজ করে না। Tiny Tiny RSS-এর নিজস্ব API রয়েছে, যার মানে হলো আপনাকে এর জন্য বিশেষভাবে তৈরি ক্লায়েন্ট ব্যবহার করতে হবে। 300টি ফিড ইমপোর্ট করার আগেই নিশ্চিত হয়ে নিন যে আপনার পছন্দের অ্যাপটি এই রিডারকে সমর্থন করে কি না।

1 জিবি র‍্যামের সার্ভারের জন্য একটি কার্যকর compose ফাইল

এটি Miniflux স্ট্যাক, যা আগস্ট 2026 পর্যন্ত প্রজেক্টটির নিজস্ব Docker উদাহরণ থেকে নেওয়া হয়েছে। প্রকাশিত পোর্টটি লুপব্যাক (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, আর কন্টেইনারের ভেতরে লুপব্যাক ইন্টারফেসে বাইন্ড করা কোনো প্রসেস সরাসরি প্রকাশিত পোর্টের মাধ্যমে অ্যাক্সেস করা যায় না। ফলে কন্টেইনারটি সচল দেখালেও কানেকশন রিসেট হয়ে যায়। ভলিউম পাথ /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-এ অন্য কোনো কাজ থাকে না। অন্য কোনো ডাটাবেস-চালিত অ্যাপ্লিকেশন এবং রিভার্স প্রক্সির সাথে এটি সেখানে চালানো সম্ভব নয়। চারটি সার্ভিসের মানে হলো চার ধরনের ওভারহেড, যার একটি হলো 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: বাইনারি ফাইলটি প্রতিস্থাপন করুন এবং ডাটাবেস ফাইলটি রেখে দিন। জুলাই 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 request গ্রহণ করে তখন প্রকৃত ট্রাফিক এর চেয়ে কম হয়, আর ফিডে পুরো আর্টিকেলের টেক্সট থাকলে ট্রাফিক বেশি হয়।

[
  {
    "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 request-এর কারণেই প্রকৃত ডেটা ব্যবহারের পরিমাণ গাণিতিক হিসাবের চেয়ে কম থাকে। কোনো রিডার যখন ফিড থেকে আসা ETag এবং Last-Modified হেডারগুলো সংরক্ষণ করে, তখন পরবর্তী রিকোয়েস্টে সেগুলো If-None-Match এবং If-Modified-Since হিসেবে পাঠিয়ে দেয়। সার্ভারে নতুন কোনো তথ্য না থাকলে তা 304 Not Modified রেসপন্স দেয় এবং কোনো বডি পাঠায় না। এতে কানেকশনের জন্য হ্যান্ডশেক করতে হলেও পেলোড বা ডেটা আদান-প্রদান করতে হয় না। যে ফিডগুলো conditional request উপেক্ষা করে, সেগুলো প্রতিবার পুরো ডকুমেন্ট পাঠিয়ে দেয়; ফলে কয়েকটি বড় ফিড আপনার মোট ডেটা খরচের বড় অংশ দখল করে নিতে পারে।

অতিরিক্ত পোলিং করলে আপনাকে ব্লক করা হতে পারে। কোনো সার্ভার যদি মনে করে আপনি তাদের ওপর চাপ সৃষ্টি করছেন, তবে তারা 429 Too Many Requests রেসপন্স দেয়, আবার কিছু সাইট 403 রেসপন্স দিয়ে থাকে। Miniflux প্রতিটি ফিডের সর্বশেষ ত্রুটি রেকর্ড করে রাখে। তাই কোনো একটি ফিড আপডেট হওয়া বন্ধ হয়ে গেলে এবং বাকিগুলো ঠিকঠাক কাজ করলে, প্রথমেই ফিড লিস্ট চেক করা উচিত।

ফিড অকেজো হয়ে যায় এবং একটি OPML ফাইল কোনো ব্যাকআপ নয়

ফিড আপনার প্রত্যাশার চেয়ে দ্রুত নষ্ট হয়ে যায়। ডোমেইনের মেয়াদ শেষ হয়ে যায়, সাইটগুলো এমন প্ল্যাটফর্মে চলে যায় যেখানে কোনো ফিড নেই, এবং যে URL আগে XML প্রদান করত তা এখন একটি 200 OK স্ট্যাটাস কোডসহ HTML এরর পেজ দেখাতে শুরু করে। শেষের ঘটনাটি বেশ ঝামেলাপূর্ণ: ফেচ (fetch) সফল হয়, কিন্তু পার্স (parse) ব্যর্থ হয়, ফলে আপনার রিডার নেটওয়ার্ক এররের পরিবর্তে পার্সিং এরর রেকর্ড করে। বছরে অন্তত একবার আপনার ফিড লিস্টকে সর্বশেষ আপডেটের সময় অনুযায়ী সাজান এবং যেসব ফিড নীরব হয়ে গেছে সেগুলো মুছে ফেলুন।

একটি OPML এক্সপোর্ট হলো আপনার সাবস্ক্রিপশন লিস্ট। এতে কেবল ফিড URL এবং ফোল্ডারের নাম থাকে। এতে পড়ার অবস্থা (read state), স্টার করা আর্টিকেল, ফিড-ভিত্তিক সেটিংস, ফিল্টার রুল বা আপনার সেভ করা আর্টিকেলের টেক্সট থাকে না। নতুন কোনো ইনস্টলেশনে সেই OPML ইমপোর্ট করলে আপনি আপনার ফিডগুলো ফিরে পাবেন ঠিকই, কিন্তু আপনার পড়া সব আর্টিকেল আবার অপঠিত (unread) হিসেবে চিহ্নিত হয়ে থাকবে।

যে ব্যাকআপটি আসলে গুরুত্বপূর্ণ তা হলো ডাটাবেস। PostgreSQL-এর ক্ষেত্রে, উপরের pg_dump কমান্ডটিই পুরো কাজ সম্পন্ন করে। FreshRSS বা yarr-এর মতো SQLite রিডারের ক্ষেত্রে, রাইটার বন্ধ করে ফাইলটি কপি করুন, অথবা 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 কম্পাইল করা থাকে। তাই আলাদা কোনো database server বা runtime-এর প্রয়োজন হয় না এবং 128 MB মেমরি বাজেট এর জন্য যথেষ্ট। তবে এর বিনিময়ে রক্ষণাবেক্ষণ ও ফিচারের সীমাবদ্ধতা মেনে নিতে হবে: এর সর্বশেষ রিলিজ হলো 2024 সালের জুলাই মাসের v2.8 এবং এটি শুধুমাত্র Fever API সমর্থন করে। আপনি যদি একই রকম মেমরি ফুটপ্রিন্টে নিয়মিত আপডেট হওয়া কোনো প্রজেক্ট চান, তবে 320 MB মেমরিতে চলা Miniflux এবং PostgreSQL-এর সমন্বয়টি ভালো বিকল্প।

আমি কি 1 GB RAM-এর VPS-এ self-hosted RSS reader চালাতে পারি?

হ্যাঁ। আপনি যদি উভয় কন্টেইনারে mem_limit সেট করেন, তবে Miniflux এবং PostgreSQL প্রায় 320 MB মেমরির মধ্যে চলে আসে। এছাড়া FreshRSS-কে SQLite-এর সাথে একটি মাত্র কন্টেইনারে চালানো সম্ভব। 1 GB RAM-এর সার্ভারে অফিশিয়াল Tiny Tiny RSS stack ব্যবহার করা এড়িয়ে চলুন, কারণ এতে নিজস্ব PostgreSQL সহ মোট 4 টি সার্ভিস থাকে। সবসময় মেমরি লিমিট সেট করুন, কারণ লিমিট না থাকলে সার্ভারের মেমরি পূর্ণ হয়ে গেলে কার্নেল কোনো একটি প্রসেস বন্ধ করে দেয়, এবং প্রায়ই অ্যাপ্লিকেশনের পরিবর্তে ডাটাবেস প্রসেসটি বন্ধ হয়ে যায়।

এগুলোর মধ্যে কোনটি iOS এবং Android RSS অ্যাপের সাথে কাজ করে?

Miniflux এবং FreshRSS উভয়ই Fever compatible API এবং Google Reader compatible API সমর্থন করে, তাই প্রায় যেকোনো মোবাইল ক্লায়েন্ট এগুলোর সাথে সংযুক্ত হতে পারে। CommaFeed এবং yarr শুধুমাত্র Fever API অফার করে। Tiny Tiny RSS নিজস্ব API ব্যবহার করে, তাই এর জন্য নির্দিষ্ট ক্লায়েন্ট প্রয়োজন। FreshRSS-এর ক্ষেত্রে আপনাকে অবশ্যই Authentication সেকশন থেকে API access চালু করতে হবে এবং প্রোফাইলে আলাদা একটি API password সেট করতে হবে, অন্যথায় ওয়েবসাইট কাজ করলেও অ্যাপে লগইন করা যাবে না।

OPML export কি আমার RSS reader-এর ব্যাকআপ?

না। OPML-এ শুধুমাত্র ফিড URL এবং ফোল্ডার থাকে, যা দিয়ে আপনি আপনার সাবস্ক্রিপশন তালিকা পুনরুদ্ধার করতে পারবেন। কিন্তু পড়ার অবস্থা (read state), তারকাচিহ্নিত আইটেম, ফিল্টার রুল এবং আর্টিকেলের মূল টেক্সট ডাটাবেসে থাকে। PostgreSQL-এর জন্য pg_dump ব্যবহার করে অথবা SQLite-এর জন্য .backup কমান্ড ব্যবহার করে ডাটাবেসের ব্যাকআপ নিন এবং সেই ফাইলটি সার্ভারের বাইরে কপি করে রাখুন।

Miniflux কি SQLite সমর্থন করে?

না। প্রজেক্টের ডকুমেন্টেশন অনুযায়ী এটি "শুধুমাত্র PostgreSQL-এর সাথে কাজ করে"। এর ফুল টেক্সট সার্চ ফিচারটি PostgreSQL-এর বিভিন্ন ফিচারের ওপর নির্ভরশীল, তাই এটি অন্য কোনো হালকা ডাটাবেসে রূপান্তর করা সম্ভব নয়। আপনি যদি ডাটাবেস কন্টেইনার ছাড়া কোনো ফিড রিডার চান, তবে FreshRSS-কে এর ডিফল্ট SQLite backend-এর সাথে অথবা yarr-কে এর এমবেডেড ফাইল সিস্টেমের সাথে ব্যবহার করুন।