ছোট 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 ব্যবহার করে পরিমাপ করুন।

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

Miniflux Go ভাষায় লেখা এবং একটি একক statically compiled binary হিসেবে release করা হয়। এর documentation একটি কঠোর dependency স্পষ্টভাবে উল্লেখ করে: এটি “শুধু PostgreSQL-এর সঙ্গে কাজ করে”। SQLite mode নেই। এতে একটি REST API, একটি Fever compatible API এবং একটি Google Reader compatible API রয়েছে। পাশাপাশি OPML import ও export করা যায়। Full text search PostgreSQL-এর ওপর নির্ভর করে। এ কারণেই database ঐচ্ছিক নয়।

FreshRSS PHP-তে লেখা এবং একটি container হিসেবে চলে, যেখানে web server ও application দুটিই থাকে। SQLite default database; এর জন্য দ্বিতীয় কোনো service প্রয়োজন হয় না। বড় installation-এর জন্য PostgreSQL ও MySQL সমর্থিত। এটি Google Reader API এবং Fever API ব্যবহার করে। এটি install করার পদ্ধতি আমাদের VPS-এ FreshRSS চালানোর নির্দেশিকায় ইতিমধ্যে দেখানো হয়েছে। তাই এখানে installation পুনরাবৃত্তি না করে এর তুলনা করা হয়েছে।

CommaFeed Quarkus-এর ওপর Java-তে লেখা এবং এর layout Google Reader-এর অনুকরণে তৈরি। Database run time-এ নয়, build time-এ নির্বাচন করা হয়। তাই project প্রতিটি database-এর জন্য আলাদা image প্রকাশ করে: embedded H2 database-এর জন্য athou/commafeed:latest-h2, PostgreSQL-এর জন্য athou/commafeed:latest-postgresql এবং MySQL ও MariaDB-এর জন্য আরও কিছু variant। এগুলো natively compiled build। -jvm suffix থাকলে বোঝায় যে variant-টি JVM-এ চলে। এতে একটি REST API এবং একটি Fever compatible API রয়েছে। এছাড়া version 7.3.0 থেকে (August 2026) একটি Google Reader compatible API-ও রয়েছে।

yarr (yet another rss reader) SQLite embedded থাকা একটি Go binary। এর জন্য কোনো container প্রয়োজন হয় না। সাধারণ ./yarr 127.0.0.1:7070-এ listen করে। Flag-গুলো সংক্ষিপ্ত: -addr 0.0.0.0:7070 -auth alice:secret ব্যবহার করলে password-এর আড়ালে network access চালু হয়, আর -db /data/yarr.db ব্যবহার করলে database-এর অবস্থান নির্ধারণ করা যায়। এতে একটি Fever compatible API রয়েছে। এর সর্বশেষ tagged release v2.9, প্রকাশিত হয়েছে September 2026-এ এবং October 2026-এ যাচাই করা হয়েছে। এর আগে v2.7 June-এ এবং v2.8 July-এ প্রকাশিত হয়েছিল। তাই project-টির active development আবার শুরু হয়েছে।

Tiny Tiny RSS পাঁচটির মধ্যে সবচেয়ে পুরোনো এবং চালানোও সবচেয়ে resource-intensive। tt-rss.org-এর মূল project 1 November 2025-এ retired হয়। Development এখন github.com/tt-rss/tt-rss-এ থাকা একটি community fork-এ চলছে। ওই fork-এর documentation-ই বর্তমানে official setup নির্দেশনা। Setup-এ চারটি service রয়েছে: একটি PostgreSQL container, একটি PHP-FPM application container, feed fetch করার জন্য একটি আলাদা updater container এবং সামনে একটি nginx container। Documentation স্পষ্টভাবে বলছে, “এই setup PostgreSQL ব্যবহার করে”। এর নিজস্ব JSON API রয়েছে, যা এর Android client এবং কয়েকটি third-party app ব্যবহার করে। 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) করে দেয়, এবং প্রায়শই সেই ভিকটিম প্রসেসটি সেই কন্টেইনার হয় না যা মেমোরির ওপর চাপ সৃষ্টি করেছিল।

প্রতিটি পাঠক কোন database আপনার ওপর বাধ্যতামূলক করে

এই পাঁচটির মধ্যে database-ই সবচেয়ে বড় operational পার্থক্য। User interface-এর যেকোনো পার্থক্যের চেয়ে এটি বড় সিদ্ধান্ত, কারণ আপনার backup procedure এবং upgrade risk database-এর ওপর নির্ভর করে।

Miniflux এবং official Tiny Tiny RSS setup-এর জন্য PostgreSQL বাধ্যতামূলক। এর সুবিধা হলো প্রকৃত full text search এবং নিরাপদ concurrent write। এর জন্য দ্বিতীয় container, একটি volume এবং একটি নিয়মিত সমস্যা সামলাতে হয়: official PostgreSQL image-গুলো major version-এর মধ্যে in-place data migration সমর্থন করে না। 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 upgrade-ও নথিবদ্ধ করেছে। বড় database-এ downtime গুরুত্বপূর্ণ হলে অতিরিক্ত setup-এর এই পদ্ধতিগুলো যুক্তিযুক্ত, কিন্তু feed reader-এর database সাধারণত সে পর্যায়ের হয় না। প্রতি এক বা দুই বছরে একবার এটি করার পরিকল্পনা রাখুন।

SQLite হলো FreshRSS এবং yarr-এর default। একটি file, কোনো server নয়, কোনো port নয়, কোনো password নয়। কয়েকশো feed নিয়ে একজন ব্যবহারকারীর ক্ষেত্রে এটি ভালোভাবে কাজ করে। একসঙ্গে একাধিক user write করলে এটি ধীর হয়ে যায়। তখন FreshRSS-এর PostgreSQL option কার্যকর হতে শুরু করে। yarr v2.7-এ optional PostgreSQL support যোগ করেছে, কিন্তু এটি চালানোর স্বাভাবিক পদ্ধতি হলো embedded file ব্যবহার করা।

H2 হলো CommaFeed-এর embedded default। শুরু করার আগে এটি নিয়ে কিছুক্ষণ ভাবা উচিত, কারণ image build করার সময় CommaFeed database নির্বাচন করে। পরে H2 থেকে PostgreSQL-এ যাওয়া configuration change নয়। এটি একটি ভিন্ন image এবং এমন একটি data migration, যা আপনাকেই সম্পন্ন করতে হবে। তাই box-এ এক বছরের read history জমার আগে সিদ্ধান্ত নিন।

আপনার ফোনের অ্যাপ কি কাজ করবে

এই প্রশ্নটি অনেকের প্রত্যাশার চেয়ে বেশি গুরুত্বপূর্ণ, কারণ একটি feed reader ব্যবহারের পদ্ধতির মাত্র অর্ধেক হলো web interface।

Miniflux একটি Fever compatible API এবং একটি Google Reader compatible API সমর্থন করে। তাই অধিকাংশ iOS এবং Android client এতে সংযোগ করতে পারে। FreshRSS-ও একই দুটি API সমর্থন করে এবং নিজস্ব documentation-এ এগুলোর অগ্রাধিকার উল্লেখ করেছে: সম্পূর্ণ feature support থাকায় Google Reader API হলো "best", আর Fever API-এর আচরণে "limited features and less efficient"। যেকোনো app লগ ইন করার আগে FreshRSS-এ আরও দুটি ধাপ সম্পন্ন করতে হয়। Authentication-এর অধীনে "Allow API access (required for mobile apps)" সক্রিয় করুন। এরপর user profile-এ একটি API password তৈরি করুন। API password বাদ দিলে app-এ authentication failure দেখা যায়, কিন্তু web login কাজ করতে থাকে। কোথায় সমস্যা খুঁজতে হবে জানা না থাকলে এটি বিভ্রান্তিকর হতে পারে।

CommaFeed এখন উভয় API-ই সমর্থন করে। এতে দীর্ঘদিন ধরে Fever compatible API ছিল। আর Fever সমর্থন করে না এমন app-এর জন্য version 7.3.0-এ Google Reader compatible API যোগ করা হয়েছে। তাই আপনার app যদি শুধু Google Reader সমর্থন করে, তাহলে 7.3.0 বা পরবর্তী version ব্যবহার করুন। yarr একটি Fever compatible API প্রকাশ করে এবং অন্য কোনো API নয়। তাই এটি Fever সমর্থনকারী client-এর সঙ্গে কাজ করে, কিন্তু শুধু Google Reader সমর্থনকারী app-এর সঙ্গে কাজ করে না। Tiny Tiny RSS-এর নিজস্ব API আছে। তাই এর জন্য তৈরি client ব্যবহার করতে হবে। এতে 300টি feed import করার আগে আপনার পছন্দের app reader-টিকে সমর্থন করে কি না যাচাই করুন।

1 GB-এর সার্ভারের জন্য কার্যকর compose ফাইল

এটি Miniflux stack। অক্টোবর 2026 অনুযায়ী এটি প্রকল্পটির নিজস্ব Docker উদাহরণ থেকে অভিযোজিত। প্রকাশিত port-টি loopback-এ bind করা হয়েছে, listen address স্পষ্টভাবে নির্ধারণ করা হয়েছে, এবং উভয় container-এ 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:

এই ফাইলের তিনটি লাইনেই মানুষ সাধারণত ভুল করে। LISTEN_ADDR=0.0.0.0:8080 official image তার Dockerfile-এ আগে থেকেই যে মান নির্ধারণ করে, সেটিই পুনরাবৃত্তি করে। তাই miniflux/miniflux-এর সঙ্গে এটি সমাধান নয়, শুধু একটি harmless safeguard। আপনি নিজের image তৈরি করলে বা packaged binary চালালে এটি গুরুত্বপূর্ণ। কারণ binary-টির নথিভুক্ত default হলো 127.0.0.1:8080। Container-এর ভেতরে loopback-এ bind করা কোনো process published port-এর মাধ্যমে পৌঁছানো যায় না। ফলে container-কে সুস্থ দেখালেও connection reset হয়। /var/lib/postgresql volume path-টি PostgreSQL 18-এর সঙ্গে মেলে। Version 17 এবং তার আগের version-গুলোতে data থাকে /var/lib/postgresql/data-এ। ভুল path mount করলে data directory volume-এর মধ্যে থাকে না। তাই পরেরবার container recreate হলে সব data হারিয়ে যায়। 127.0.0.1:8080:8080 port-টিকে public Internet থেকে আড়ালে রাখে। কারণ address ছাড়া port publish করলে এমন একটি chain-এ rule লেখা হয়, যেটি ufw পরিচালনা করে না। Docker port কীভাবে ufw বাইপাস করে এই প্রক্রিয়াটি ব্যাখ্যা করে। আর Traefik reverse proxy ব্যবহার করে এর সামনে TLS বসানো যায়।

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

docker compose ps-এ উভয় service-কে running হিসেবে দেখানো উচিত এবং database-কে healthy হিসেবে চিহ্নিত থাকা উচিত। Miniflux প্রথমবার চালু হলে তার schema migration-এর log লেখা হয়। RUN_MIGRATIONS=1 সেটিই শুরু করে। docker stats --no-stream বর্তমান memory column দেখায়। উপরের chart-এর limit-এর সঙ্গে তুলনা করার জন্য এই সংখ্যাটিই ব্যবহার করুন। Miniflux container বারবার restart হলে তার log দেখুন। connect: connection refused-এর অর্থ হলো PostgreSQL connection গ্রহণের জন্য প্রস্তুত হওয়ার আগেই এটি শুরু হয়েছিল। service_healthy condition ঠিক এই সমস্যাটিই প্রতিরোধ করে। তাই আপনার edit-এর পর condition-টি অপরিবর্তিত আছে কি না পরীক্ষা করুন। Compose আপনার কাছে নতুন হলে, VPS-এ Docker Compose-এর মৌলিক বিষয় প্রথমে file layout ব্যাখ্যা করে।

1 GB-এর সার্ভারে যা চালানো যাবে না

Tiny Tiny RSS এড়িয়ে চলুন। এর অফিসিয়াল চারটি service নিয়ে তৈরি stack একটি 1 GB VPS-এ চলে, যদি VPS-এ অন্য কোনো কাজ না থাকে। কিন্তু একই VPS-এ আরেকটি database-নির্ভর application এবং একটি reverse proxy থাকলে এটি চলবে না। চারটি service মানে চার সেট overhead, যার একটি PostgreSQL।

CommaFeed চালানো যায়, তবে শুধু H2 image এবং প্রকল্পটির নিজস্ব উদাহরণে নির্ধারিত 256 MB সীমার মধ্যে। ছোট সার্ভারের জন্য যে সমন্বয়টি সমস্যা তৈরি করে, তা হলো আলাদা database server-এর পাশাপাশি CommaFeed চালানো। -jvm image variant ব্যবহার করলে সমস্যা আরও বাড়ে, কারণ প্রকল্পের documentation সতর্ক করে যে JVM ডিফল্টভাবে অতিরিক্ত memory ব্যবহার করে এবং অব্যবহৃত memory operating system-কে ফিরিয়ে দেয় না। latest-h2 এবং latest-postgresql tag native build বোঝায়। কম memory ব্যবহারের জন্য প্রকল্পটি এগুলো ব্যবহারের পরামর্শ দেয়। তাই JVM চালানোর নির্দিষ্ট কারণ না থাকলে এগুলোতেই থাকুন।

কোনো সার্ভারের memory শেষ হয়ে গেলে kernel-এর out of memory killer একটি process বেছে নিয়ে সেটি terminate করে। dmesg -T-এ Out of memory: Killed process 1234 (java)-এর মতো একটি line দেখা যায়। এরপর application log-এ কোনো message না লিখেই container docker compose ps থেকে অদৃশ্য হয়ে যায়, কারণ application message লেখার সুযোগই পায়নি।

প্রতিটির আপগ্রেড যেভাবে কাজ করে

• Miniflux: docker compose pull && docker compose up -d, এবং RUN_MIGRATIONS=1 সেট করা থাকলে স্টার্টের সময় schema migration প্রয়োগ করা হয়। আপগ্রেডের ঝুঁকি Miniflux নয়। এর নিচে ব্যবহৃত PostgreSQL-এর major version-ই ঝুঁকির বিষয়।
• FreshRSS: নতুন image pull করুন। SQLite ব্যবহার করলে আপগ্রেড করার মতো কোনো database engine থাকে না। তাই সাধারণত সমস্যা হয় এমন third-party extension থেকে, যেগুলো নতুন সংস্করণের সঙ্গে সামঞ্জস্যপূর্ণ রাখা হয়নি।
• CommaFeed: আপনার database-এর সঙ্গে মেলে এমন image variant pull করুন। latest-h2 থেকে latest-postgresql-এ পরিবর্তন করলে আপনার data স্থানান্তরিত হবে না।
• yarr: binary প্রতিস্থাপন করুন এবং database file রেখে দিন। 2026 সালের June, July এবং September-এ release প্রকাশিত হয়েছে। October 2026 অনুযায়ী v2.9 সর্বশেষ। তাই সময়ে সময়ে release page পরীক্ষা করুন।
• Tiny Tiny RSS: docker compose pull && docker compose up -d। Application container স্টার্টের সময় নিজে আপডেট হয়। প্রকল্পটির FAQ অনুযায়ী schema update error-এর কারণ সাধারণত নষ্ট volume বা ভুল override setup। এমন error দেখা দিলে প্রথমে এগুলো পরীক্ষা করুন। আপনার compose file যদি এখনও অবসরপ্রাপ্ত tt-rss.org প্রকল্পের image pull করে, তাহলে সেটিকে fork-এর image-এ পরিবর্তন করুন (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 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 ফাইল backup নয়

আপনার ধারণার চেয়ে দ্রুত ফিড নষ্ট হয়ে যায়। Domain-এর মেয়াদ শেষ হয়, সাইট এমন platform-এ চলে যায় যেখানে feed নেই, এবং আগে XML সরবরাহ করা URL পরে 200 OK status-সহ একটি HTML error page সরবরাহ করতে শুরু করে। শেষের ঘটনাটিই সমস্যাজনক: fetch সফল হয়, parse ব্যর্থ হয়, এবং আপনার reader network error-এর বদলে parsing error রেকর্ড করে। বছরে একবার feed list-কে last updated অনুযায়ী সাজিয়ে দীর্ঘ সময় ধরে কোনো update না হওয়া feed মুছে দিন।

OPML export হলো আপনার subscription list। একটি standard OPML ফাইলে feed URL এবং folder name থাকে। FreshRSS নিজস্ব XML namespace যোগ করে, যেখানে প্রতিটি feed-এর refresh interval, XPath scraping selector এবং auto-read filter-এর মতো setting-ও থাকে। তবে কোনো OPML export-এ read state, starred article বা আপনার সংরক্ষণ করা article text থাকে না। সেই OPML নতুন installation-এ import করলে আপনার feed ফিরে পাবেন, কিন্তু আপনি আগে পড়া প্রতিটি article আবার unread হিসেবে চিহ্নিত হবে।

গুরুত্বপূর্ণ backup হলো database। PostgreSQL-এর ক্ষেত্রে, উপরের pg_dump command-ই সম্পূর্ণ কাজ। FreshRSS বা yarr-এর মতো SQLite reader-এর জন্য writer বন্ধ করে file copy করুন, অথবা reader চলার সময় sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" ব্যবহার করে একটি consistent copy নিন। লেখার কাজ চলমান database-এর সাধারণ cp করলে এমন file তৈরি হতে পারে যা পরে open হবে না, কারণ copy-তে অসম্পূর্ণ write ধরা পড়ে। এরপর schedule অনুযায়ী file-গুলো server-এর বাইরে পাঠান। VPS-এ restic backup করার উদ্দেশ্য এটাই। অন্তত একবার একটি scratch container-এ একটি backup restore করুন, যাতে নিশ্চিত হতে পারেন যে প্রক্রিয়াটি কাজ করে।

নিজে চালানোর জন্য feed reader সবচেয়ে কম খরচের service-গুলোর একটি। তাই এটি 2026 সালে নিজে চালানোর মতো service-এর তালিকা-তে প্রায় সবসময় থাকে। এর পাশে নিজে চালানো SearXNG instance রাখলে reading এবং searching—দুটিই আপনার নিয়ন্ত্রণাধীন hardware-এ থাকে।

FAQ

কোন self-hosted RSS reader সবচেয়ে কম memory ব্যবহার করে?

yarr। এটি SQLite-সহ compile করা একটি একক Go binary। তাই আলাদা database server বা language runtime প্রয়োজন হয় না, এবং 128 MB ceiling এতে স্বচ্ছন্দে রাখা যায়। তবে feature সীমিত। এটি শুধু Fever API সমর্থন করে, এবং এর সর্বশেষ release হলো September 2026-এর v2.9। একই ধরনের footprint-এ Google Reader API support এবং full text search চাইলে 320 MB-এ PostgreSQL-সহ Miniflux ভালো পছন্দ।

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

হ্যাঁ। উভয় container-এ mem_limit সেট করলে PostgreSQL-সহ Miniflux প্রায় 320 MB-এর মধ্যে চলে। SQLite-সহ FreshRSS একটি container-এর মধ্যেই চলে। 1 GB-এ official Tiny Tiny RSS stack এড়িয়ে চলুন। এতে নিজস্ব PostgreSQL-সহ 4টি service থাকে। সব সময় memory limit সেট করুন। কারণ পূর্ণ server-এ unlimited container থাকলে kernel কোনো process বন্ধ করে দিতে পারে। প্রায়ই সমস্যাযুক্ত application-এর বদলে database process-ই নির্বাচিত হয়।

এগুলোর কোনগুলো iOS এবং Android RSS app-এর সঙ্গে কাজ করে?

Miniflux, FreshRSS এবং CommaFeed 7.3.0 বা পরবর্তী সংস্করণ Fever compatible API এবং Google Reader compatible API—উভয়ই সমর্থন করে। তাই প্রায় যেকোনো mobile client সংযোগ করতে পারে। yarr শুধু Fever API দেয়। Tiny Tiny RSS নিজস্ব API ব্যবহার করে। তাই এর জন্য তৈরি client প্রয়োজন। FreshRSS-এ Authentication-এর অধীনে API access সক্রিয় করতে হবে এবং profile-এ আলাদা API password সেট করতে হবে। তা না হলে 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 ব্যবহার করুন। এরপর backup ফলাফল server-এর বাইরে কপি করুন।

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

না। Project documentation-এ বলা হয়েছে, এটি “শুধু PostgreSQL-এর সঙ্গে কাজ করে”। Full text search PostgreSQL-এর feature ব্যবহার করে। তাই অন্য কোনো হালকা mode-এ switch করার সুযোগ নেই। একেবারেই database container ছাড়া feed reader চাইলে default SQLite backend-সহ FreshRSS অথবা embedded file-সহ yarr চালান।