சிறந்த self-hosted RSS reader எது? VPS ஒப்பீடு

சிறிய VPS-க்கு எந்த self-hosted RSS reader பொருத்தமானது

சிறிய VPS-ல் நிறுவுவதற்கு Miniflux சிறந்த self-hosted RSS reader ஆகும். இது PostgreSQL-உடன் இணைந்து இயங்கும் ஒரே ஒரு Go binary கோப்பு மட்டுமே. இது Fever மற்றும் Google Reader API-களை ஆதரிப்பதால், மூன்றாம் தரப்பு மொபைல் செயலிகளை இதனுடன் இணைக்க முடியும். மேலும், ஒரு upgrade செய்வதற்கு docker compose pull கட்டளையைப் பயன்படுத்தினால் போதுமானது. உங்களுக்கு கூடுதல் வசதிகள் (extensions) தேவைப்பட்டால் மற்றும் SQLite-ஐ உள்ளடக்கிய ஒரே ஒரு container-ல் இயங்க வேண்டும் எனில், FreshRSS-ஐத் தேர்ந்தெடுக்கவும்.

VPS-ல் சேமிப்பகத்தை ஒதுக்கத் தகுதியான ஐந்து RSS reader-கள்: Miniflux, FreshRSS, CommaFeed, yarr மற்றும் Tiny Tiny RSS. இந்த பக்கம் அவற்றுக்கிடையேயான உண்மையான வேறுபாடுகளை ஒப்பிடுகிறது: ஒவ்வொன்றும் பயன்படுத்தும் memory அளவு, கட்டாயமாக்கப்படும் database, உங்கள் மொபைல் செயலிக்குத் தேவையான sync API மற்றும் upgrade செய்யும் போது நடப்பவை. இங்குள்ள ஒவ்வொரு புள்ளிவிவரமும் அந்தந்த திட்டத்தால் வெளியிடப்பட்டது அல்லது எளிய கணக்கீட்டின் மூலம் பெறப்பட்டது; எது என்பது உரையில் குறிப்பிடப்பட்டுள்ளது. இதில் எதுவுமே உங்கள் வன்பொருளுக்கான (hardware) benchmark அல்ல, எனவே docker stats மூலம் உங்கள் server-ல் நீங்களே அளவீடு செய்து பார்க்கவும்.

ஐந்து வாசகர்கள், தலா ஒரு பத்தி

Miniflux என்பது Go மொழியில் எழுதப்பட்டது மற்றும் ஒரே statically compiled binary-ஆக வழங்கப்படுகிறது. இதன் ஆவணங்கள் ஒரு முக்கியமான தேவையைத் தெளிவாகக் குறிப்பிடுகின்றன: இது "PostgreSQL-உடன் மட்டுமே இயங்கும்". இதில் SQLite வசதி இல்லை. இது REST API, Fever-உடன் இணக்கமான API மற்றும் Google Reader-உடன் இணக்கமான API ஆகியவற்றை வழங்குகிறது; மேலும் OPML import மற்றும் export வசதிகளும் உண்டு. முழு உரைத் தேடல் (Full text search) PostgreSQL மூலம் கையாளப்படுகிறது, இதனால்தான் database கட்டாயமான ஒன்றாக உள்ளது.

FreshRSS என்பது PHP-ல் இயங்குகிறது மற்றும் web server மற்றும் application இரண்டையும் உள்ளடக்கிய ஒரே container-ஆகச் செயல்படுகிறது. SQLite இதன் இயல்புநிலை database என்பதால் இரண்டாவது service தேவையில்லை; பெரிய அளவிலான நிறுவல்களுக்கு PostgreSQL மற்றும் MySQL ஆதரிக்கப்படுகின்றன. இது Google Reader API மற்றும் Fever API ஆகியவற்றுடன் பேசுகிறது. இதை நிறுவுவது ஏற்கனவே எங்கள் FreshRSS on a VPS வழிகாட்டியில் விவரிக்கப்பட்டுள்ளதால், இந்தப்பக்கம் மீண்டும் நிறுவுவதற்குப் பதிலாக மற்றவற்றுடன் ஒப்பிடுகிறது.

CommaFeed என்பது Quarkus-ல் இயங்கும் Java application ஆகும்; இதன் அமைப்பு Google Reader-ஐப் பிரதிபலிக்கிறது. இதன் database-ஐ run time-ல் அல்லாமல் build time-லேயே தேர்ந்தெடுக்க வேண்டும், எனவே ஒவ்வொரு database-க்கும் தனித்தனி image-ஐ இந்தத் திட்டம் வெளியிடுகிறது: embedded H2 database-க்கு athou/commafeed:latest-h2, PostgreSQL-க்கு athou/commafeed:latest-postgresql, மற்றும் MySQL மற்றும் MariaDB-க்கு கூடுதல் variants. இது REST API மற்றும் Fever-உடன் இணக்கமான API ஆகியவற்றை வழங்குகிறது.

yarr (yet another rss reader) என்பது SQLite-ஐ உள்ளடக்கிய ஒரே Go binary ஆகும், இதற்கு எந்த container-ம் தேவையில்லை. சாதாரண ./yarr என்பது 127.0.0.1:7070-ல் கேட்கிறது (listens). இதன் flags சுருக்கமானவை: -addr 0.0.0.0:7070 -auth alice:secret கடவுச்சொல் மூலம் network-ல் இதை அணுக அனுமதிக்கிறது, மற்றும் -db /data/yarr.db database-ஐ நீங்கள் விரும்பும் இடத்தில் வைக்க உதவுகிறது. இதில் Fever-உடன் இணக்கமான API உள்ளது. இதன் புதிய tagged release v2.8, ஜூலை 2024-ல் வெளியானது, ஆகஸ்ட் 2026-ல் சரிபார்க்கப்பட்டது, எனவே இதைத் தொடர்ந்து மேம்படுத்தப்படும் மென்பொருளாகக் கருதாமல், முடிக்கப்பட்ட மென்பொருளாகக் கருதவும்.

Tiny Tiny RSS என்பது இந்த ஐந்தில் பழமையானது மற்றும் இயங்குவதற்கு அதிக வளம் தேவைப்படுவது. இதன் அதிகாரப்பூர்வ Docker அமைப்பு நான்கு services-ஐக் கொண்டது: ஒரு PostgreSQL container, ஒரு PHP-FPM application container, feeds-ஐப் பெறும் ஒரு தனி updater container, மற்றும் முன்னால் ஒரு nginx container. இந்த அமைப்பு "PostgreSQL-ஐப் பயன்படுத்துகிறது" என்று ஆவணங்கள் தெளிவாகக் கூறுகின்றன. இதற்குச் சொந்தமான JSON API உள்ளது, இதைத்தான் இதன் Android client மற்றும் பல மூன்றாம் தரப்பு செயலிகள் பயன்படுத்துகின்றன. இதில் Fever வசதி இல்லை.

ஒவ்வொரு stack-க்கும் தேவைப்படும் memory அளவு

கீழே கொடுக்கப்பட்டுள்ள எண்கள் அளவீடுகள் அல்ல, இவை ஒதுக்கீடுகள் (budgets) மட்டுமே. சிறிய VPS-ல் ஒவ்வொரு stack-ம் இருக்க வேண்டிய அதிகபட்ச memory அளவு இது. CommaFeed-ன் எண் அந்தத் திட்டத்தின் அதிகாரப்பூர்வ வெளியீட்டில் குறிப்பிடப்பட்டுள்ளது, இது container-ன் அளவை 256 MB-க்குள் கட்டுப்படுத்துகிறது. மற்றவை, feed fetcher-க்குத் தேவையான கூடுதல் இடத்தையும் சேர்த்து கணக்கிடப்பட்ட உச்சவரம்புகள் ஆகும்; ஏனெனில் refresh cycle தொடங்கும் போது அதன் பயன்பாடு திடீரென அதிகரிக்கும்.

[
  {
    "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-ல் இயங்குகிறது. ஏனெனில் இது ஒரே ஒரு binary மற்றும் ஒரு SQLite file-ஐ மட்டுமே கொண்டுள்ளது; இதற்குத் தனி database server-ஓ அல்லது language runtime-ஓ தேவையில்லை. Miniflux-க்கு 2 containers-ல் மொத்தம் 320 MB தேவைப்படுகிறது, இதில் பெரும்பகுதி Miniflux-ஐ விட PostgreSQL-க்கே செலவாகிறது. Tiny Tiny RSS இதில் விதிவிலக்கானது; இது 4 containers-ல் 640 MB-ஐப் பயன்படுத்துகிறது. ஏனெனில் இதில் application, updater, database மற்றும் web server என நான்கு தனித்தனி process-கள் நான்கு தனித்தனி heaps-ஐப் பயன்படுத்துகின்றன.

இவற்றை வெறும் எதிர்பார்ப்புகளாகக் கொள்ளாமல், உண்மையான வரம்புகளாக (limits) அமைக்கவும். Docker Compose-ல் memory வரம்புகள் என்ற பகுதி, இதற்கான syntax மற்றும் ஒரு container அதன் உச்சவரம்பை அடையும் போது என்ன நடக்கும் என்பதை விளக்குகிறது. வரம்பு இல்லாத ஒரு container, memory நிறைந்திருக்கும் போது சரியாகச் செயல்படாது: kernel ஒரு process-ஐத் தேர்ந்தெடுத்து அதை நிறுத்திவிடும் (kill). பெரும்பாலும், அந்தச் சிக்கலை உருவாக்கிய container-ஐ விட, வேறொரு முக்கியமான process-ஐயே kernel நிறுத்திவிடும்.

ஒவ்வொரு reader-ம் உங்கள் மீது திணிக்கும் database

இந்த ஐந்திற்கும் இடையே உள்ள மிகப்பெரிய செயல்பாட்டு வேறுபாடு அதன் database-ல் தான் உள்ளது. பயனர் இடைமுகத்தில் (user interface) உள்ள வேறுபாடுகளை விட இது முக்கியமான முடிவாகும், ஏனெனில் இதுவே உங்கள் backup நடைமுறையையும், upgrade செய்யும் போது ஏற்படும் அபாயத்தையும் தீர்மானிக்கிறது.

Miniflux மற்றும் அதிகாரப்பூர்வ Tiny Tiny RSS அமைப்பு ஆகியவற்றிற்கு PostgreSQL தேவைப்படுகிறது. இது சிறந்த full text search வசதியையும், பாதுகாப்பான concurrent writes-ஐயும் வழங்குகிறது. இதற்கு ஒரு கூடுதல் container, ஒரு volume மற்றும் ஒரு தொடர்ச்சியான சிக்கல் தேவைப்படுகிறது: அதிகாரப்பூர்வ PostgreSQL images-ஆல் major versions-க்கு இடையே தரவுகளை நேரடியாக (in-place) மாற்ற முடியாது. Tiny Tiny RSS ஆவணங்கள் இதை நேரடியாகக் குறிப்பிடுகின்றன, மேலும் "அதிகாரப்பூர்வ PostgreSQL containers-ல் major versions-க்கு இடையே தரவுகளை மாற்றும் வசதி இல்லை" என்று எச்சரிக்கின்றன. உங்களிடம் உள்ள நடைமுறை விருப்பங்கள், பழைய major version-ஐ அப்படியே வைத்திருப்பது அல்லது pg_dump மற்றும் pg_restore மூலம் தரவுகளை dump செய்து restore செய்வது மட்டுமே. இதற்கு ஒன்று அல்லது இரண்டு ஆண்டுகளுக்கு ஒருமுறை திட்டமிடுங்கள்.

FreshRSS மற்றும் yarr ஆகியவற்றின் இயல்புநிலை (default) SQLite ஆகும். இது ஒரே ஒரு கோப்பு, server தேவையில்லை, port தேவையில்லை, password தேவையில்லை. சில நூறு feeds கொண்ட ஒரு நபருக்கு இது நன்றாகச் செயல்படும், ஆனால் பல பயனர்கள் ஒரே நேரத்தில் தரவுகளை எழுதும்போது வேகம் குறையும்; அப்போதுதான் FreshRSS-ன் PostgreSQL விருப்பம் பயனுள்ளதாக இருக்கும். yarr தனது v2.7 பதிப்பில் PostgreSQL ஆதரவை விருப்பத்தேர்வாகச் சேர்த்துள்ளது, ஆனால் embedded கோப்பைப் பயன்படுத்துவதே அதை இயக்குவதற்கான சாதாரண முறையாகும்.

CommaFeed-ன் இயல்புநிலை embedded database H2 ஆகும். நீங்கள் தொடங்குவதற்கு முன் இதைப் பற்றி சிறிது சிந்திக்க வேண்டும், ஏனெனில் CommaFeed-ன் image உருவாக்கப்படும்போதே அதன் database தீர்மானிக்கப்படுகிறது. பிறகு H2-லிருந்து PostgreSQL-க்கு மாறுவது என்பது ஒரு எளிய configuration மாற்றம் அல்ல. இது ஒரு மாறுபட்ட image மற்றும் நீங்களாகவே செய்ய வேண்டிய தரவு இடமாற்றம் (data migration) ஆகும், எனவே ஒரு வருட கால வாசிப்பு வரலாறு (read history) சேமிக்கப்படுவதற்கு முன்பே முடிவெடுங்கள்.

உங்கள் போன் ஆப் வேலை செய்யுமா

இந்தக் கேள்வி மக்கள் எதிர்பார்ப்பதை விட அதிக முக்கியத்துவம் வாய்ந்தது, ஏனெனில் ஒரு feed reader-ன் பயன்பாட்டில் web interface என்பது பாதி மட்டுமே.

Miniflux ஆனது Fever compatible API மற்றும் Google Reader compatible API ஆகிய இரண்டையும் ஆதரிக்கிறது, எனவே பெரும்பாலான iOS மற்றும் Android clients இதனுடன் இணையும். FreshRSS-ம் அதே இரண்டையும் ஆதரிக்கிறது, ஆனால் அதன் ஆவணங்கள் அவற்றை வரிசைப்படுத்துகின்றன: Google Reader API முழுமையான வசதிகளுடன் "சிறந்தது" என்றும், Fever API "குறைந்த வசதிகள் மற்றும் குறைவான செயல்திறன்" கொண்டது என்றும் குறிப்பிடுகின்றன. எந்தவொரு ஆப்பும் login செய்வதற்கு முன்பு FreshRSS-ல் இரண்டு படிகள் தேவை. Authentication பிரிவின் கீழ் "Allow API access (required for mobile apps)" என்பதை enable செய்யவும், பிறகு user profile-ல் ஒரு API password-ஐ உருவாக்கவும். API password-ஐ உருவாக்கத் தவறினால், web login வேலை செய்தாலும் ஆப்பில் authentication failure ஏற்படும்; இது எங்கு பார்க்க வேண்டும் என்று தெரியாதவரை குழப்பத்தை ஏற்படுத்தும்.

CommaFeed மற்றும் yarr ஆகிய இரண்டும் Fever compatible API-ஐ மட்டுமே வழங்குகின்றன, எனவே இவை Fever-ஐ ஆதரிக்கும் clients-ல் மட்டுமே வேலை செய்யும், Google Reader-ஐ மட்டும் ஆதரிக்கும் ஆப்புகளில் வேலை செய்யாது. Tiny Tiny RSS தனக்கென சொந்தமான API-ஐக் கொண்டுள்ளது, எனவே அதற்கென பிரத்யேகமாக எழுதப்பட்ட client தேவைப்படும். 300 feeds-ஐ import செய்வதற்கு முன்பாக, நீங்கள் விரும்பும் ஆப் அந்த reader-ஐ ஆதரிக்கிறதா என்பதைச் சரிபார்க்கவும்.

1 GB RAM கொண்ட server-க்கான ஒரு working compose file

இது Miniflux stack ஆகும். இது ஆகஸ்ட் 2026 நிலவரப்படி அந்தத் திட்டத்தின் அதிகாரப்பூர்வ Docker உதாரணத்திலிருந்து மாற்றியமைக்கப்பட்டது. இதில் published port loopback-உடன் இணைக்கப்பட்டுள்ளது, listen address தெளிவாகக் குறிப்பிடப்பட்டுள்ளது, மேலும் இரண்டு 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:

அந்தக் கோப்பில் உள்ள மூன்று வரிகளைத்தான் பயனர்கள் தவறாகக் கையாள்கிறார்கள். LISTEN_ADDR=0.0.0.0:8080 அமைக்கப்பட்டுள்ளது, ஏனெனில் அந்த binary-ன் ஆவணப்படுத்தப்பட்ட default மதிப்பு 127.0.0.1:8080 ஆகும். container-க்குள் loopback-உடன் இணைக்கப்பட்ட ஒரு process-ஐ published port வழியாக அணுக முடியாது; இதனால் container ஆரோக்கியமாகத் தெரிந்தாலும் connection reset பிழை ஏற்படும். volume path /var/lib/postgresql என்பது PostgreSQL 18-க்கு பொருந்தும்; பதிப்பு 17 மற்றும் அதற்கு முந்தையவை /var/lib/postgresql/data-ல் தரவைச் சேமிக்கும். தவறான path-ஐ mount செய்தால், தரவு அடைவு (data directory) volume-ல் இருக்காது, எனவே container மீண்டும் உருவாக்கப்படும்போது அனைத்து தரவும் அழிந்துவிடும். 127.0.0.1:8080:8080 அந்த port-ஐ பொது இணையத்திலிருந்து (public internet) பாதுகாக்கிறது. ஏனெனில், ஒரு முகவரி இல்லாமல் port-ஐ publish செய்வது, ufw நிர்வகிக்காத ஒரு rule-ஐ chain-ல் எழுதிவிடும். 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 கட்டளையானது இரண்டு service-களும் இயங்குவதையும், database healthy எனக் குறிக்கப்பட்டிருப்பதையும் காட்ட வேண்டும். Miniflux முதல்முறை தொடங்கும்போது அதன் schema migrations-ஐ log செய்யும், இதைத்தான் RUN_MIGRATIONS=1 தூண்டுகிறது. docker stats --no-stream தற்போதைய memory பயன்பாட்டைக் காட்டும், இதை மேலே உள்ள அட்டவணையில் உள்ள வரம்புகளுடன் ஒப்பிட வேண்டும். Miniflux container மீண்டும் மீண்டும் restart ஆனால், அதன் log-ஐப் பார்க்கவும்: connect: connection refused என்பது PostgreSQL இணைப்புகளை ஏற்கத் தயாராகும் முன்பே அது தொடங்கிவிட்டது என்று பொருள். இதைத்தான் service_healthy நிபந்தனை தடுக்கிறது, எனவே அந்த நிபந்தனை உங்கள் மாற்றங்களுக்குப் பிறகும் சரியாக உள்ளதா எனச் சரிபார்க்கவும். உங்களுக்கு Compose புதியது என்றால், Docker Compose basics on a VPS கோப்பின் அமைப்பை முதலில் விளக்குகிறது.

1 GB கொள்ளளவு கொண்ட server-ல் எவை இயங்காது

Tiny Tiny RSS-ஐத் தவிர்ப்பது நல்லது. அதன் அதிகாரப்பூர்வ நான்கு service stack-களும் 1 GB VPS-ல் இயங்க வேண்டுமானால், அந்த VPS-ல் வேறு எந்தப் பணியும் இருக்கக்கூடாது. database சார்ந்த மற்றொரு application மற்றும் reverse proxy-உடன் சேர்த்து இதை இயக்க முடியாது. நான்கு services என்றால் நான்கு மடங்கு overhead; அதில் ஒன்று PostgreSQL.

CommaFeed இயங்கும், ஆனால் H2 image-ஐப் பயன்படுத்தி, திட்டத்தின் உதாரணத்தில் உள்ளபடி 256 MB வரம்பிற்குள் இருந்தால் மட்டுமே இது சாத்தியம். ஒரு சிறிய server-ல் JVM-ஐயும், தனி database server-ஐயும் ஒன்றாக இயக்குவது சிக்கலை ஏற்படுத்தும்; ஏனெனில் JVM தனக்குக் கிடைக்கும் அனைத்து நினைவகத்தையும் (headroom) எடுத்துக்கொள்ளும். CommaFeed-ன் ஆவணங்கள் -Xmx256m-ஐ ஒரு கடினமான வரம்பாகவும், OpenJ9-ஐ "HotSpot JVM-க்கு மாற்றாக நினைவகத்தை சிக்கனமாகப் பயன்படுத்தும் முறை" என்றும் குறிப்பிடுகின்றன. இதன் மூலம் அதன் நினைவகப் பயன்பாடு எங்கு செல்கிறது என்பதை அறியலாம்.

server-ன் நினைவகம் தீர்ந்துவிட்டால், kernel-ல் உள்ள out of memory killer ஒரு process-ஐத் தேர்ந்தெடுத்து அதை நிறுத்திவிடும். dmesg -T-ல் Out of memory: Killed process 1234 (java) போன்ற ஒரு வரியைக் காணலாம். அந்த container docker compose ps-லிருந்து எந்தவித அறிவிப்பும் இன்றி மறைந்துவிடும்; ஏனெனில் application-ஆல் எந்தப் பதிவையும் (log) எழுத முடியாமல் போயிருக்கும்.

ஒவ்வொன்றிலும் மேம்படுத்தல்கள் எவ்வாறு செயல்படுகின்றன

• Miniflux: docker compose pull && docker compose up -d, RUN_MIGRATIONS=1 அமைக்கப்பட்டிருக்கும்போது தொடக்கத்தில் schema migrations தானாகவே நடைபெறும். மேம்படுத்தல் ஆபத்து Miniflux-ல் இல்லை. அதன் அடிப்படையிலுள்ள PostgreSQL-ன் முக்கிய பதிப்பில்தான் (major version) உள்ளது.
• FreshRSS: புதிய image-ஐ pull செய்யவும். SQLite-ஐப் பயன்படுத்தும்போது மேம்படுத்த வேண்டிய database engine எதுவும் இல்லை, எனவே வழக்கமான சிக்கல்கள் புதுப்பிக்கப்படாத third-party extensions-களால் மட்டுமே ஏற்படுகின்றன.
• CommaFeed: உங்கள் database-க்கு ஏற்ற image variant-ஐ pull செய்யவும். latest-h2-லிருந்து latest-postgresql-க்கு மாறும்போது உங்கள் தரவுகள் தானாக இடம்பெயராது.
• yarr: binary-ஐ மாற்றிவிட்டு database கோப்பை அப்படியே வைத்திருக்கவும். ஜூலை 2024-ல் வெளியான v2.8 பதிப்பிற்குப் பிறகு, ஆகஸ்ட் 2026 வரை எந்தப் புதிய பதிப்பும் வெளியாகவில்லை என்பதால், மேம்படுத்த எதுவும் இல்லை.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Schema migrations தானாகவே இயங்கும், மேலும் உறுதிப்படுத்தல் தேவைப்படும்போது interface உங்களை migration திரைக்கு அழைத்துச் செல்லும்.

இவற்றில் எதைச் செய்வதற்கு முன்பும் database dump எடுக்கவும், செய்த பிறகு எடுக்க வேண்டாம்.

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

Refresh interval-ஆல் ஏற்படும் bandwidth செலவு

கீழே உள்ள எண்கள் கணக்கீட்டு முறையிலானவை, அளவீடுகள் அல்ல. இவை 100 feeds, ஒரு இடைவெளிக்கு ஒரு கோரிக்கை (request), மற்றும் ஒரு பதிலுக்கு 40 KB என வைத்து கணக்கிடப்பட்டுள்ளன. ஒரு server conditional requests-ஐ ஏற்கும் போது உண்மையான traffic குறைவாக இருக்கும்; feeds முழுமையான கட்டுரைகளைத் தரும்போது traffic அதிகமாக இருக்கும்.

[
  {
    "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 feeds-க்கு ஐந்து நிமிட இடைவெளி என்பது 864,000 கோரிக்கைகள் மற்றும் மாதத்திற்கு சுமார் 34.6 GB ஆகும். ஒரு மணிநேர polling என்பது 72,000 கோரிக்கைகள் மற்றும் சுமார் 2.9 GB ஆகும். Miniflux, POLLING_FREQUENCY-ஐ 60 நிமிடங்களாக அமைத்து வருகிறது, இது அந்த அட்டவணையின் கடைசி வரிசையாகும். இந்த default அமைப்பு பெரும்பாலான பயனர்களுக்குப் போதுமானது. நீங்கள் அடிக்கடி கோருவதால் ஒரு கட்டுரை விரைவாக வந்துவிடாது.

Conditional requests-தான் உண்மையான எண்ணிக்கையை கணக்கீட்டு அளவை விடக் குறைவாக வைத்திருக்கின்றன. ஒரு feed வழங்கிய ETag மற்றும் Last-Modified headers-ஐச் சேமித்து வைக்கும் reader, அவற்றை மீண்டும் If-None-Match மற்றும் If-Modified-Since ஆக அனுப்பும். புதிய தகவல்கள் இல்லாத server, 304 Not Modified எனப் பதிலளிக்கும், இதில் body இருக்காது. இந்த இணைப்பிற்கு handshake செலவு உண்டு, ஆனால் payload செலவு இல்லை. Conditional requests-ஐப் புறக்கணிக்கும் feeds ஒவ்வொரு முறையும் முழு ஆவணத்தையும் உங்களுக்குத் தரும். எனவே, சில பெரிய feeds உங்கள் transfer கட்டணத்தை அதிகரிக்கக்கூடும்.

அடிக்கடி polling செய்வது உங்களை block செய்யவும் வழிவகுக்கும். நீங்கள் server-ஐத் தொடர்ந்து தொந்தரவு செய்வதாகக் கருதினால், அது 429 Too Many Requests எனப் பதிலளிக்கும்; சில தளங்கள் 403 எனப் பதிலளிக்கும். Miniflux அந்த feed-ன் கடைசிப் பிழையைப் பதிவு செய்யும். எனவே, ஒரு feed மட்டும் புதுப்பிப்பதை நிறுத்திவிட்டு மற்றவை சரியாகச் செயல்பட்டால், முதலில் feed பட்டியலைச் சரிபார்க்கவும்.

Feeds செயலிழக்கின்றன, OPML கோப்பு ஒரு காப்புப்பிரதி (backup) அல்ல

நீங்கள் எதிர்பார்ப்பதை விட Feeds மிக வேகமாகச் சிதைவடைகின்றன. டொமைன்கள் காலாவதியாகின்றன, தளங்கள் Feed வசதி இல்லாத தளங்களுக்கு மாறுகின்றன, மேலும் முன்பு XML-ஐ வழங்கிய URL, இப்போது 200 OK நிலையுடன் கூடிய HTML பிழைப் பக்கத்தை வழங்கத் தொடங்குகிறது. இந்த கடைசிச் சூழல் மிகவும் சிக்கலானது: fetch வெற்றி பெறுகிறது, ஆனால் parse தோல்வியடைகிறது. இதனால் உங்கள் reader, network பிழைக்கு பதிலாக parsing பிழையைப் பதிவு செய்கிறது. ஆண்டுக்கு ஒருமுறை, உங்கள் feed பட்டியலை கடைசியாகப் புதுப்பிக்கப்பட்ட தேதியின் அடிப்படையில் வரிசைப்படுத்தி, செயலிழந்தவற்றை நீக்கிவிடுங்கள்.

OPML export என்பது உங்கள் சந்தா பட்டியல் மட்டுமே. இது feed URL-களையும் கோப்புறைப் பெயர்களையும் மட்டுமே கொண்டிருக்கும். இது நீங்கள் படித்த நிலை, நட்சத்திரமிட்ட கட்டுரைகள், ஒவ்வொரு feed-க்கான அமைப்புகள், வடிகட்டி விதிகள் அல்லது நீங்கள் சேமித்த கட்டுரையின் உரை ஆகியவற்றைச் சேமிக்காது. அந்த OPML-ஐ ஒரு புதிய நிறுவலில் import செய்தால், உங்கள் feeds மீண்டும் கிடைக்கும், ஆனால் நீங்கள் ஏற்கனவே படித்த அனைத்துக் கட்டுரைகளும் மீண்டும் படிக்கப்படாததாகக் (unread) காட்டும்.

முக்கியமான காப்புப்பிரதி என்பது தரவுத்தளம் (database) மட்டுமே. PostgreSQL-க்கு, மேலே உள்ள pg_dump கட்டளையே முழுமையான பணியாகும். FreshRSS அல்லது yarr போன்ற SQLite reader-களுக்கு, writer-ஐ நிறுத்திவிட்டு கோப்பை நகலெடுக்கவும், அல்லது sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" மூலம் அது இயங்கும்போது ஒரு சீரான நகலை எடுக்கவும். தரவுத்தளம் எழுதப்பட்டுக் கொண்டிருக்கும்போது எடுக்கப்படும் சாதாரண cp, பிற்காலத்தில் திறக்க முடியாத கோப்பை உருவாக்கக்கூடும், ஏனெனில் அந்த நகல் பாதியில் நின்ற எழுத்துப் பணியைப் பதிவு செய்துவிடும். எனவே, அந்த கோப்புகளை ஒரு கால அட்டவணையின்படி சர்வரிலிருந்து வெளியேற்றவும். இதற்காகத்தான் restic backups on a VPS பயன்படுகின்றன. செயல்முறை சரியாக வேலை செய்கிறதா என்பதை உறுதிப்படுத்த, ஒருமுறை அதை ஒரு scratch container-ல் restore செய்து பார்க்கவும்.

ஒரு feed reader-ஐ நீங்களே இயக்குவது மிகவும் மலிவான சேவைகளில் ஒன்றாகும். இதனால்தான் things worth self-hosting in 2026 பட்டியலில் இது இடம் பெற்றுள்ளது. அதனுடன் a self-hosted SearXNG instance-ஐயும் சேர்த்தால், உங்கள் வாசிப்பு மற்றும் தேடல் ஆகிய இரண்டுமே உங்கள் கட்டுப்பாட்டில் உள்ள வன்பொருளிலேயே இருக்கும்.

FAQ

குறைந்த நினைவகத்தைப் (memory) பயன்படுத்தும் self-hosted RSS reader எது?

yarr. இது SQLite-ஐ உள்ளடக்கிய ஒரே ஒரு Go binary ஆகும். எனவே, இதற்குத் தனி database server அல்லது கூடுதல் language runtime தேவையில்லை. 128 MB நினைவக வரம்பிற்குள் இது தாராளமாக இயங்கும். ஆனால், பராமரிப்பு மற்றும் வசதிகளில் சில சமரசங்கள் உள்ளன: இதன் சமீபத்திய release ஜூலை 2024-ல் வெளியான v2.8 ஆகும், மேலும் இது Fever API-ஐ மட்டுமே ஆதரிக்கிறது. இதேபோன்ற அளவில் தொடர்ந்து மேம்படுத்தப்படும் ஒரு project தேவைப்பட்டால், 320 MB நினைவகத்தில் இயங்கும் Miniflux மற்றும் PostgreSQL சிறந்த தேர்வாகும்.

1 GB VPS-ல் self-hosted RSS reader-ஐ இயக்க முடியுமா?

ஆம். Miniflux மற்றும் PostgreSQL ஆகியவற்றை இரண்டு containers-லும் mem_limit அமைப்பதன் மூலம் 320 MB நினைவகத்திற்குள் இயக்க முடியும். FreshRSS-ஐ SQLite உடன் ஒரே container-ல் இயக்கலாம். 1 GB VPS-ல் தவிர்க்க வேண்டியது அதிகாரப்பூர்வ Tiny Tiny RSS stack ஆகும், ஏனெனில் இது அதன் சொந்த PostgreSQL உட்பட 4 சேவைகளைக் கொண்டுள்ளது. எப்போதும் memory limits-ஐ அமைக்கவும்; ஏனெனில், வரம்பற்ற container-ல் இயங்கும் ஒரு process-ஐ kernel திடீரென நிறுத்தக்கூடும் (OOM kill). அவ்வாறு நிகழும்போது, தவறு செய்த application-க்கு பதிலாக database process நிறுத்தப்பட அதிக வாய்ப்புள்ளது.

இவற்றில் எவை iOS மற்றும் Android RSS apps-உடன் வேலை செய்யும்?

Miniflux மற்றும் FreshRSS ஆகிய இரண்டும் Fever API மற்றும் Google Reader API ஆகிய இரண்டையும் ஆதரிக்கின்றன, எனவே கிட்டத்தட்ட அனைத்து mobile clients-உம் இவற்றுடன் இணைக்க முடியும். CommaFeed மற்றும் yarr ஆகியவை Fever API-ஐ மட்டுமே வழங்குகின்றன. Tiny Tiny RSS அதன் சொந்த API-ஐப் பயன்படுத்துவதால், அதற்கென பிரத்யேகமாக உருவாக்கப்பட்ட client மட்டுமே தேவைப்படும். FreshRSS-ல், Authentication பகுதிக்குச் சென்று API access-ஐ enable செய்து, profile-ல் தனி API password-ஐ அமைக்க வேண்டும். இல்லையெனில், இணையதளம் வேலை செய்தாலும், mobile app-ல் login செய்ய முடியாது.

OPML export என்பது எனது RSS reader-ன் backup-ஆ?

இல்லை. OPML-ல் feed URLs மற்றும் folders மட்டுமே இருக்கும், எனவே இது உங்கள் subscription பட்டியலை மட்டுமே மீண்டும் உருவாக்கும். வாசித்த நிலை (read state), நட்சத்திரமிட்ட கட்டுரைகள் (starred items), filter விதிகள் மற்றும் கட்டுரையின் உள்ளடக்கம் அனைத்தும் database-ல் மட்டுமே இருக்கும். PostgreSQL-க்கு pg_dump மூலமாகவும், SQLite-க்கு .backup கட்டளை மூலமாகவும் database-ஐ backup எடுத்து, அந்த கோப்பை server-க்கு வெளியே பாதுகாப்பாகச் சேமிக்கவும்.

Miniflux, SQLite-ஐ ஆதரிக்கிறதா?

இல்லை. இந்த project-ன் ஆவணங்களின்படி, இது "PostgreSQL-உடன் மட்டுமே வேலை செய்யும்". மேலும், full text search வசதி PostgreSQL-ன் அம்சங்களைக் கொண்டு செயல்படுத்தப்பட்டுள்ளதால், இதை மாற்ற வேறு எளிய வழிமுறை இல்லை. database container-ஐத் தவிர்க்க விரும்பினால், default SQLite backend-ஐக் கொண்ட FreshRSS-ஐ அல்லது embedded file-ஐப் பயன்படுத்தும் yarr-ஐத் தேர்ந்தெடுக்கவும்.