SSD Nodes Learn Hosting plans →
คู่มือ Matt Connorโดย Matt Connor

เปรียบเทียบ RSS reader แบบ self-hosted บน VPS

เปรียบเทียบ Miniflux, FreshRSS, CommaFeed, yarr และ Tiny Tiny RSS บน VPS วิเคราะห์การใช้หน่วยความจำ ฐานข้อมูล รองรับ Fever API และขั้นตอนการอัปเกรดเพื่อเลือกตัวที่เหมาะสมที่สุด

RSS reader แบบ self-hosted ตัวใดที่เหมาะกับ VPS ขนาดเล็ก

Miniflux คือ RSS reader แบบ self-hosted ที่ควรติดตั้งบน VPS ขนาดเล็ก โดยเป็นไฟล์ Go binary เพียงไฟล์เดียวที่ทำงานร่วมกับ PostgreSQL รองรับ Fever API และ Google Reader API ทำให้สามารถเชื่อมต่อกับแอปพลิเคชันบนมือถือของบุคคลที่สามได้ และการอัปเกรดทำได้ด้วยคำสั่ง docker compose pull หากคุณต้องการส่วนขยาย (extensions) และต้องการใช้ container เพียงตัวเดียวที่มี SQLite ในตัว ให้เลือกใช้ FreshRSS แทน

RSS reader 5 ตัวที่คุ้มค่าต่อการใช้พื้นที่ดิสก์บน VPS ได้แก่ Miniflux, FreshRSS, CommaFeed, yarr และ Tiny Tiny RSS หน้านี้จะเปรียบเทียบความแตกต่างที่สำคัญระหว่างโปรแกรมเหล่านี้ ได้แก่ ปริมาณหน่วยความจำที่แต่ละ stack ต้องการ, ฐานข้อมูลที่แต่ละตัวบังคับใช้, API สำหรับการซิงค์ที่แอปบนมือถือของคุณต้องการ และสิ่งที่เกิดขึ้นในวันที่มีการอัปเกรด ตัวเลขทั้งหมดในที่นี้เป็นข้อมูลที่เผยแพร่โดยโครงการหรือมาจากการคำนวณพื้นฐาน ซึ่งระบุไว้ในเนื้อหาแล้ว ข้อมูลเหล่านี้ไม่ใช่การทดสอบประสิทธิภาพ (benchmark) ของฮาร์ดแวร์ของคุณ ดังนั้นควรวัดผลด้วยเครื่องของคุณเองโดยใช้ docker stats

ผู้อ่านทั้งห้าท่าน กับหนึ่งย่อหน้าต่อหนึ่งโปรแกรม

Miniflux เขียนด้วยภาษา Go และเผยแพร่ในรูปแบบไฟล์ binary ที่คอมไพล์แบบ static เพียงไฟล์เดียว เอกสารประกอบระบุไว้อย่างชัดเจนถึงข้อกำหนดหลักเพียงประการเดียวคือ "ทำงานร่วมกับ PostgreSQL เท่านั้น" โดยไม่มีโหมด SQLite ให้ใช้งาน โปรแกรมนี้มี REST API, API ที่รองรับ Fever และ API ที่รองรับ Google Reader รวมถึงรองรับการนำเข้าและส่งออกไฟล์ OPML การค้นหาข้อความแบบเต็ม (full text search) จะถูกจัดการโดย PostgreSQL ซึ่งเป็นเหตุผลส่วนหนึ่งที่ทำให้ฐานข้อมูลนี้เป็นสิ่งที่ขาดไม่ได้

FreshRSS พัฒนาด้วย PHP และทำงานเป็นคอนเทนเนอร์เดียวที่รวมทั้งเว็บเซิร์ฟเวอร์และตัวแอปพลิเคชันไว้ด้วยกัน โดยมี SQLite เป็นฐานข้อมูลเริ่มต้นซึ่งไม่จำเป็นต้องใช้บริการอื่นเพิ่มเติม ในขณะที่ PostgreSQL และ MySQL ได้รับการรองรับสำหรับการติดตั้งขนาดใหญ่ โปรแกรมนี้รองรับ Google Reader API และ Fever API การติดตั้งได้ถูกอธิบายไว้แล้วใน คู่มือการติดตั้ง FreshRSS บน VPS ของเรา ดังนั้นหน้านี้จึงเป็นการเปรียบเทียบแทนการทำซ้ำขั้นตอนการติดตั้ง

CommaFeed พัฒนาด้วย Java บน Quarkus โดยมีเลย์เอาต์ที่ลอกเลียนแบบมาจาก Google Reader การเลือกฐานข้อมูลต้องทำตั้งแต่ขั้นตอน build ไม่ใช่ตอนรัน ดังนั้นโปรเจกต์จึงเผยแพร่ image แยกตามฐานข้อมูล ได้แก่ athou/commafeed:latest-h2 สำหรับฐานข้อมูล H2 แบบฝัง, athou/commafeed:latest-postgresql สำหรับ PostgreSQL และรุ่นอื่นๆ สำหรับ MySQL และ MariaDB โดยแท็กเหล่านั้นเป็นรุ่นที่คอมไพล์แบบ native และมีคำต่อท้าย -jvm สำหรับรุ่นที่รันบน JVM โปรแกรมนี้เปิดให้ใช้งาน REST API และ API ที่รองรับ Fever และตั้งแต่เวอร์ชัน 7.3.0 (สิงหาคม 2026) เป็นต้นมา ก็ได้เพิ่ม API ที่รองรับ Google Reader เข้ามาด้วย

yarr (yet another rss reader) เป็นไฟล์ binary ภาษา Go เพียงไฟล์เดียวที่ฝัง SQLite มาในตัว และไม่จำเป็นต้องใช้คอนเทนเนอร์ใดๆ เลย โดยปกติ ./yarr จะฟังคำสั่งที่ 127.0.0.1:7070 แฟล็กการตั้งค่ามีขนาดสั้น: -addr 0.0.0.0:7070 -auth alice:secret ใช้เปิดการเข้าถึงผ่านเครือข่ายโดยมีการป้องกันด้วยรหัสผ่าน และ -db /data/yarr.db ใช้กำหนดตำแหน่งจัดเก็บฐานข้อมูลตามต้องการ โปรแกรมนี้มี API ที่รองรับ Fever รุ่นล่าสุดที่ปล่อยออกมาคือ v2.9 เมื่อเดือนกันยายน 2026 ซึ่งตรวจสอบเมื่อเดือนตุลาคม 2026 ต่อจาก v2.7 ในเดือนมิถุนายน และ v2.8 ในเดือนกรกฎาคม แสดงให้เห็นว่าโปรแกรมนี้กำลังถูกพัฒนาอย่างต่อเนื่องอีกครั้ง

Tiny Tiny RSS เป็นโปรแกรมที่เก่าแก่ที่สุดในบรรดาทั้งห้าและใช้ทรัพยากรในการรันมากที่สุด โปรเจกต์ดั้งเดิมที่ tt-rss.org ได้ยุติการพัฒนาไปเมื่อวันที่ 1 พฤศจิกายน 2025 และการพัฒนายังคงดำเนินต่อไปในรูปแบบ community fork ที่ github.com/tt-rss/tt-rss ซึ่งเอกสารประกอบของที่นั่นถือเป็นขั้นตอนการติดตั้งอย่างเป็นทางการในปัจจุบัน การติดตั้งนี้ประกอบด้วยสี่บริการ ได้แก่ คอนเทนเนอร์ PostgreSQL, คอนเทนเนอร์แอปพลิเคชัน PHP-FPM, คอนเทนเนอร์สำหรับอัปเดตข้อมูลที่ทำหน้าที่ดึงฟีด และคอนเทนเนอร์ nginx ที่อยู่ด้านหน้า เอกสารระบุไว้อย่างชัดเจนว่า "การติดตั้งนี้ใช้ PostgreSQL" โปรแกรมมี JSON API ของตนเอง ซึ่งไคลเอนต์ Android และแอปพลิเคชันจากภายนอกหลายตัวรองรับการใช้งาน แต่ไม่มีการรองรับ Fever ในตัวโปรแกรม

ปริมาณหน่วยความจำที่แต่ละ stack ต้องการ

ตัวเลขด้านล่างนี้เป็นงบประมาณ ไม่ใช่ค่าที่วัดได้จริง โดยเป็นเพดานหน่วยความจำที่แต่ละ stack ควรใช้บน VPS ขนาดเล็ก ตัวเลขของ CommaFeed เป็นตัวอย่างที่โครงการเผยแพร่ไว้เอง ซึ่งจำกัด container ไว้ที่ 256 MB ส่วนค่าอื่นๆ เป็นเพดานที่เผื่อพื้นที่ไว้สำหรับตัวดึงข้อมูล (feed fetcher) ซึ่งเป็นส่วนที่ใช้ทรัพยากรสูงขึ้นเมื่อเริ่มรอบการรีเฟรช

แผนภูมิMemory ceiling per reader stack, in MB
ข้อมูลเบื้องหลังแผนภูมินี้
[
  {
    "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 หนึ่งไฟล์ โดยไม่มี database server หรือ language runtime อื่นรองรับ Miniflux ต้องการ 320 MB สำหรับ 2 containers ซึ่งส่วนใหญ่เป็นของ PostgreSQL ไม่ใช่ของ Miniflux ส่วน Tiny Tiny RSS เป็นกรณีพิเศษที่ 640 MB สำหรับ 4 containers เนื่องจากตัวแอปพลิเคชัน, ตัวอัปเดต, ฐานข้อมูล และเว็บเซิร์ฟเวอร์ เป็นสี่กระบวนการแยกกันที่มี heap แยกกัน

ให้กำหนดค่าเหล่านี้เป็นขีดจำกัดจริง ไม่ใช่แค่ความคาดหวัง การจำกัดหน่วยความจำใน Docker Compose ครอบคลุมถึงไวยากรณ์และสิ่งที่ container จะทำเมื่อถึงเพดานที่กำหนด หาก container ไม่มีการจำกัดหน่วยความจำและเครื่องเต็ม ระบบจะไม่หยุดทำงานอย่างเป็นระเบียบ แต่ kernel จะเลือกกระบวนการหนึ่งมาสังหารทิ้ง ซึ่งบ่อยครั้งกระบวนการที่ถูกเลือกไม่ใช่ container ที่เป็นต้นเหตุของปัญหาหน่วยความจำล้น

ฐานข้อมูลที่ตัวอ่านแต่ละตัวบังคับให้คุณใช้

ฐานข้อมูลคือความแตกต่างด้านการปฏิบัติงานที่ใหญ่ที่สุดระหว่างทั้ง 5 ตัวนี้ ซึ่งเป็นการตัดสินใจที่สำคัญกว่าความแตกต่างของส่วนติดต่อผู้ใช้ เพราะเป็นตัวกำหนดขั้นตอนการสำรองข้อมูลและความเสี่ยงในการอัปเกรดของคุณ

PostgreSQL เป็นสิ่งที่ Miniflux และการติดตั้ง Tiny Tiny RSS แบบทางการต้องการ มันช่วยให้คุณได้ระบบค้นหาข้อความแบบเต็มรูปแบบ (full text search) และการเขียนข้อมูลพร้อมกันที่ปลอดภัย แต่ต้องแลกมาด้วยการเพิ่มคอนเทนเนอร์อีกหนึ่งตัว, การใช้ volume และปัญหาที่เกิดขึ้นซ้ำซากคือ อิมเมจ PostgreSQL แบบทางการไม่สามารถย้ายข้อมูลระหว่างเวอร์ชันหลัก (major version) ในที่เดิมได้ เอกสารของ Tiny Tiny RSS ระบุเรื่องนี้ไว้อย่างชัดเจนและเตือนว่า "คอนเทนเนอร์ PostgreSQL แบบทางการไม่มีการรองรับการย้ายข้อมูลระหว่างเวอร์ชันหลัก" สำหรับตัวอ่านฟีด ตัวเลือกที่เป็นไปได้จริงของคุณคือการล็อกเวอร์ชันหลักเดิมไว้ หรือทำการ dump และ restore ด้วย pg_dump และ pg_restore นอกจากนี้ PostgreSQL ยังมีเอกสารเกี่ยวกับ pg_upgrade และการอัปเกรดแบบ replication ซึ่งคุ้มค่ากับการตั้งค่าที่ซับซ้อนขึ้นสำหรับฐานข้อมูลขนาดใหญ่ที่ต้องการลดเวลาหยุดทำงาน (downtime) แต่ฐานข้อมูลของตัวอ่านฟีดมักไม่เข้าข่ายนั้น ให้วางแผนรับมือเรื่องนี้ทุกๆ 1 หรือ 2 ปี

SQLite เป็นค่าเริ่มต้นของ FreshRSS และ yarr โดยมีไฟล์เดียว ไม่ต้องมีเซิร์ฟเวอร์ ไม่ต้องใช้พอร์ต และไม่ต้องใช้รหัสผ่าน มันทำงานได้ดีสำหรับผู้ใช้คนเดียวที่มีฟีดไม่กี่ร้อยรายการ และจะทำงานช้าลงเมื่อผู้ใช้หลายคนเขียนข้อมูลพร้อมกัน ซึ่งเป็นจุดที่ตัวเลือก PostgreSQL ของ FreshRSS เริ่มแสดงความคุ้มค่าออกมา yarr ได้เพิ่มการรองรับ PostgreSQL เป็นทางเลือกใน v2.7 แต่การใช้ไฟล์แบบฝังตัว (embedded file) ยังคงเป็นวิธีปกติในการใช้งาน

H2 เป็นค่าเริ่มต้นแบบฝังตัวของ CommaFeed และเป็นสิ่งที่ควรพิจารณาก่อนเริ่มใช้งาน เพราะ CommaFeed จะเลือกฐานข้อมูลตั้งแต่ตอนสร้างอิมเมจ การย้ายจาก H2 ไปยัง PostgreSQL ในภายหลังไม่ใช่แค่การเปลี่ยนการตั้งค่า แต่เป็นการเปลี่ยนอิมเมจพร้อมกับการย้ายข้อมูลที่คุณต้องทำด้วยตัวเอง ดังนั้นควรตัดสินใจให้ดีก่อนที่คุณจะมีประวัติการอ่านสะสมอยู่ในระบบนานเป็นปี

แอปบนโทรศัพท์ของคุณจะใช้งานได้หรือไม่

คำถามนี้มีความสำคัญมากกว่าที่หลายคนคาดคิด เนื่องจากอินเทอร์เฟซบนเว็บเป็นเพียงส่วนหนึ่งของการใช้งานโปรแกรมอ่านฟีดเท่านั้น

Miniflux รองรับ API ที่เข้ากันได้กับ Fever และ 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 รองรับ API ทั้งสองตัวเช่นกัน โดยรองรับ API ที่เข้ากันได้กับ Fever มานานแล้ว และในเวอร์ชัน 7.3.0 ได้เพิ่ม API ที่เข้ากันได้กับ Google Reader สำหรับแอปที่ไม่รองรับ Fever ดังนั้นหากแอปของคุณรองรับเฉพาะ Google Reader ให้ใช้งานเวอร์ชัน 7.3.0 ขึ้นไป ส่วน yarr นั้นรองรับเฉพาะ API ที่เข้ากันได้กับ Fever เท่านั้น จึงใช้งานได้กับไคลเอนต์ที่รองรับ Fever แต่ไม่สามารถใช้กับแอปที่รองรับเฉพาะ Google Reader ได้ สำหรับ Tiny Tiny RSS นั้นมี API เป็นของตนเอง ซึ่งหมายความว่าคุณจำเป็นต้องใช้ไคลเอนต์ที่ถูกเขียนขึ้นมาเพื่อรองรับโปรแกรมนี้โดยเฉพาะ โปรดตรวจสอบให้แน่ใจว่าแอปที่คุณต้องการใช้งานรองรับโปรแกรมอ่านฟีดนั้นๆ ก่อนที่คุณจะนำเข้าฟีดจำนวน 300 รายการเข้าไป

ไฟล์ compose ที่ใช้งานได้สำหรับเซิร์ฟเวอร์ขนาด 1 GB

นี่คือ stack ของ Miniflux ซึ่งปรับปรุงมาจากตัวอย่าง Docker ของโปรเจกต์เอง ณ เดือนตุลาคม 2026 พอร์ตที่เปิดใช้งานถูกผูกไว้กับ loopback, มีการกำหนด listen address ไว้อย่างชัดเจน และคอนเทนเนอร์ทั้งสองรายการมีการจำกัดการใช้หน่วยความจำไว้

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 เป็นการระบุซ้ำสิ่งที่ image หลักกำหนดไว้ใน Dockerfile อยู่แล้ว ดังนั้นการใช้ miniflux/miniflux จึงเป็นเพียงมาตรการป้องกันที่ไม่ส่งผลเสียมากกว่าจะเป็นการแก้ไขปัญหา มันจะมีความสำคัญเมื่อคุณ build image ของตัวเองหรือรัน binary ที่แพ็กมา เพราะค่าเริ่มต้นตามเอกสารของ binary คือ 127.0.0.1:8080 และกระบวนการที่ผูกกับ loopback ภายในคอนเทนเนอร์จะไม่สามารถเข้าถึงได้ผ่านพอร์ตที่เปิดไว้ ส่งผลให้คุณได้รับข้อผิดพลาด connection reset ทั้งที่คอนเทนเนอร์ดูเหมือนทำงานปกติ path ของ volume /var/lib/postgresql นั้นตรงกับ PostgreSQL 18; สำหรับเวอร์ชัน 17 และเก่ากว่าจะเก็บข้อมูลไว้ใน /var/lib/postgresql/data และการ mount path ที่ผิดหมายความว่าไดเรกทอรีข้อมูลไม่ได้อยู่บน volume จริง ทำให้ข้อมูลทั้งหมดหายไปในครั้งถัดไปที่คอนเทนเนอร์ถูกสร้างใหม่ 127.0.0.1:8080:8080 ช่วยป้องกันไม่ให้พอร์ตเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ เพราะการเปิดพอร์ตโดยไม่ระบุ address จะเป็นการเขียนกฎลงใน chain ที่ 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 จะแสดง log ของการทำ schema migrations ซึ่งเป็นสิ่งที่ RUN_MIGRATIONS=1 เป็นตัวกระตุ้น docker stats --no-stream จะแสดงคอลัมน์หน่วยความจำที่ใช้งานจริง ซึ่งเป็นตัวเลขที่ควรนำไปเปรียบเทียบกับเพดานที่กำหนดไว้ในตารางด้านบน หากคอนเทนเนอร์ Miniflux รีสตาร์ทวนซ้ำ ให้ตรวจสอบ log ของมัน: connect: connection refused หมายความว่ามันเริ่มทำงานก่อนที่ PostgreSQL จะพร้อมรับการเชื่อมต่อ ซึ่งเป็นสิ่งที่เงื่อนไข service_healthy ป้องกันไว้ ดังนั้นให้ตรวจสอบว่าเงื่อนไขดังกล่าวยังคงอยู่หลังจากการแก้ไขของคุณ หากคุณยังใหม่กับ Compose Docker Compose basics on a VPS จะครอบคลุมเรื่องโครงสร้างไฟล์เป็นอันดับแรก

สิ่งที่อาจไม่สามารถทำงานบนเซิร์ฟเวอร์ขนาด 1 GB ได้

Tiny Tiny RSS เป็นบริการที่ควรหลีกเลี่ยง สแต็กมาตรฐาน 4 บริการของมันสามารถทำงานบน VPS ขนาด 1 GB ได้หาก VPS นั้นไม่ได้รันงานอื่นเลย แต่จะไม่สามารถทำงานร่วมกับแอปพลิเคชันอื่นที่ต้องใช้ฐานข้อมูลและ reverse proxy ได้ การมี 4 บริการหมายถึงภาระงาน (overhead) ที่เพิ่มขึ้น 4 ชุด และหนึ่งในนั้นคือ PostgreSQL

CommaFeed สามารถทำงานได้ แต่ต้องใช้ image รุ่น H2 และจำกัดหน่วยความจำไว้ที่ 256 MB ตามตัวอย่างที่โครงการกำหนดไว้ การจับคู่ที่ทำให้เซิร์ฟเวอร์ขนาดเล็กทำงานไม่ได้คือการรัน CommaFeed ควบคู่ไปกับเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหาก และการใช้ image รุ่น -jvm จะยิ่งทำให้แย่ลง เนื่องจากเอกสารของโครงการเตือนว่า JVM มักจะใช้หน่วยความจำอย่างสิ้นเปลืองโดยค่าเริ่มต้นและไม่คืนหน่วยความจำที่ไม่ได้ใช้ให้กับระบบปฏิบัติการ แท็ก latest-h2 และ latest-postgresql เป็นรุ่นที่คอมไพล์แบบ native ซึ่งโครงการแนะนำให้ใช้เนื่องจากใช้หน่วยความจำน้อยกว่า ดังนั้นควรใช้แท็กเหล่านี้เว้นแต่คุณจะมีเหตุผลจำเป็นที่ต้องรันบน JVM

เมื่อเซิร์ฟเวอร์หน่วยความจำเต็ม kernel out of memory killer จะเลือกกระบวนการทำงานหนึ่งขึ้นมาและยุติการทำงานนั้น dmesg -T จะแสดงบรรทัดข้อความในลักษณะ Out of memory: Killed process 1234 (java) และคอนเทนเนอร์จะหายไปจาก docker compose ps โดยไม่มีข้อความแจ้งเตือนใน log ของแอปพลิเคชัน เนื่องจากแอปพลิเคชันไม่เคยมีโอกาสได้เขียนข้อความเหล่านั้นลงไป

พฤติกรรมการอัปเกรดของแต่ละบริการ

  • Miniflux: docker compose pull && docker compose up -d โดยจะมีการทำ schema migration เมื่อเริ่มต้นทำงานหากมีการตั้งค่า RUN_MIGRATIONS=1 ไว้ ความเสี่ยงในการอัปเกรดไม่ได้อยู่ที่ตัว Miniflux แต่อยู่ที่เวอร์ชันหลักของ PostgreSQL ที่ใช้งานอยู่เบื้องหลัง
  • FreshRSS: ให้ดึง image ใหม่มาใช้งาน สำหรับกรณีที่ใช้ SQLite จะไม่มีตัวจัดการฐานข้อมูลให้ต้องอัปเกรด ดังนั้นปัญหาที่มักพบจึงเกิดจากส่วนขยาย (extension) ของบุคคลที่สามที่ไม่ได้รับการปรับปรุงให้ทันสมัย
  • CommaFeed: ให้ดึง image รุ่นที่ตรงกับฐานข้อมูลของคุณ การเปลี่ยนจาก latest-h2 ไปเป็น latest-postgresql จะไม่ย้ายข้อมูลเดิมของคุณไปด้วย
  • yarr: ให้แทนที่ไฟล์ binary เดิมและเก็บไฟล์ฐานข้อมูลไว้ โดยมีการออกรุ่นในเดือนมิถุนายน กรกฎาคม และกันยายน 2026 และ v2.9 เป็นเวอร์ชันล่าสุด ณ เดือนตุลาคม 2026 ดังนั้นควรตรวจสอบหน้าแจ้งเตือนการออกรุ่นเป็นระยะ
  • Tiny Tiny RSS: docker compose pull && docker compose up -d ตัว container ของแอปพลิเคชันจะอัปเดตตัวเองเมื่อเริ่มต้นทำงาน และ FAQ ของโครงการระบุว่าข้อผิดพลาดในการอัปเดต schema มักเกิดจาก volume ที่เสียหายหรือการตั้งค่า override ที่ผิดพลาด ดังนั้นให้ตรวจสอบส่วนนี้ก่อนหากพบปัญหา หากไฟล์ compose ของคุณยังคงดึง image จากโครงการ tt-rss.org ที่เลิกใช้งานไปแล้ว ให้เปลี่ยนไปใช้ image ของโครงการที่แยกออกมา (supahgreg/tt-rss บน Docker Hub หรือ ghcr.io/tt-rss/tt-rss)

ให้สำรองข้อมูลฐานข้อมูลก่อนดำเนินการเหล่านี้เสมอ ไม่ใช่หลังจากดำเนินการเสร็จสิ้น

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

ต้นทุนด้านแบนด์วิดท์ของช่วงเวลาการรีเฟรช

ตัวเลขด้านล่างนี้เป็นการคำนวณทางคณิตศาสตร์ ไม่ใช่การวัดผลจริง โดยสมมติว่ามีฟีด 100 รายการ มีการร้องขอหนึ่งครั้งต่อฟีดในแต่ละช่วงเวลา และขนาดการตอบกลับอยู่ที่ 40 KB ต่อครั้ง ปริมาณการใช้งานจริงจะต่ำกว่านี้เมื่อเซิร์ฟเวอร์รองรับการร้องขอแบบมีเงื่อนไข (conditional requests) และจะสูงขึ้นเมื่อฟีดมีเนื้อหาบทความฉบับเต็ม

แผนภูมิMonthly fetches and bandwidth for 100 feeds at 40 KB per response
ข้อมูลเบื้องหลังแผนภูมินี้
[
  {
    "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 GB ต่อเดือน หากตั้งค่าการดึงข้อมูลรายชั่วโมงจะอยู่ที่ 72,000 ครั้ง และประมาณ 2.9 GB Miniflux มาพร้อมกับการตั้งค่า POLLING_FREQUENCY ไว้ที่ 60 นาที ซึ่งเป็นแถวสุดท้ายของตารางดังกล่าว และค่าเริ่มต้นนี้เหมาะสมสำหรับผู้ใช้ส่วนใหญ่ บทความไม่ได้มาถึงเร็วขึ้นเพียงเพราะคุณร้องขอถี่ขึ้น

การร้องขอแบบมีเงื่อนไขคือสิ่งที่ช่วยให้ตัวเลขจริงต่ำกว่าการคำนวณทางคณิตศาสตร์ โปรแกรมอ่านฟีดที่จัดเก็บ header ETag และ Last-Modified ที่ได้รับจากฟีด จะส่งข้อมูลเหล่านั้นกลับไปในรูปแบบ If-None-Match และ If-Modified-Since หากเซิร์ฟเวอร์ไม่มีข้อมูลใหม่ก็จะตอบกลับด้วย 304 Not Modified โดยไม่มีเนื้อหา (body) การเชื่อมต่อยังคงต้องเสียค่าใช้จ่ายในการทำ handshake แต่ไม่ต้องเสียค่า payload ฟีดที่เพิกเฉยต่อการร้องขอแบบมีเงื่อนไขจะส่งเอกสารทั้งหมดมาให้คุณทุกครั้ง ดังนั้นฟีดขนาดใหญ่เพียงไม่กี่รายการอาจทำให้ค่าใช้จ่ายในการรับส่งข้อมูลของคุณสูงขึ้นมาก

การดึงข้อมูลถี่เกินไปอาจทำให้คุณถูกบล็อกได้ เซิร์ฟเวอร์ที่ตัดสินว่าคุณกำลังรบกวนระบบจะตอบกลับด้วย 429 Too Many Requests และบางเว็บไซต์อาจตอบกลับด้วย 403 แทน Miniflux จะบันทึกข้อผิดพลาดล่าสุดไว้ที่ตัวฟีดนั้นๆ ดังนั้นรายการฟีดจึงเป็นจุดแรกที่คุณควรตรวจสอบเมื่อฟีดรายการใดรายการหนึ่งหยุดอัปเดตในขณะที่รายการอื่นยังคงทำงานได้ตามปกติ

ฟีดข้อมูลมีวันตาย และไฟล์ OPML ไม่ใช่การสำรองข้อมูล

ฟีดข้อมูลเสื่อมสภาพเร็วกว่าที่คุณคาดคิด โดเมนหมดอายุ เว็บไซต์ย้ายไปใช้แพลตฟอร์มที่ไม่มีฟีด และ URL ที่เคยให้บริการ XML กลับกลายเป็นหน้าแสดงข้อผิดพลาด HTML พร้อมสถานะ 200 OK กรณีหลังนี้เป็นปัญหาที่น่ารำคาญที่สุด เพราะการดึงข้อมูลสำเร็จแต่การแยกวิเคราะห์ (parse) ล้มเหลว ทำให้โปรแกรมอ่านฟีดของคุณบันทึกว่าเป็นข้อผิดพลาดในการแยกวิเคราะห์แทนที่จะเป็นข้อผิดพลาดของเครือข่าย ให้คุณจัดเรียงรายการฟีดตามการอัปเดตล่าสุดปีละครั้ง และลบฟีดที่เงียบหายไปออก

การส่งออกไฟล์ OPML คือรายการสมัครรับข้อมูลของคุณ ไฟล์ OPML มาตรฐานจะเก็บ URL ของฟีดและชื่อโฟลเดอร์ไว้ FreshRSS เพิ่ม XML namespace ของตนเองซึ่งเก็บการตั้งค่าเฉพาะฟีด เช่น ช่วงเวลาการรีเฟรช, XPath scraping selectors และตัวกรองการอ่านอัตโนมัติ แต่การส่งออก OPML ไม่มีการเก็บสถานะการอ่าน, บทความที่ติดดาว หรือเนื้อหาบทความที่คุณบันทึกไว้ หากคุณนำเข้า OPML นั้นไปยังการติดตั้งใหม่ คุณจะได้ฟีดกลับมาทั้งหมด แต่บทความที่คุณเคยอ่านไปแล้วจะถูกทำเครื่องหมายว่ายังไม่ได้อ่านอีกครั้ง

การสำรองข้อมูลที่สำคัญคือฐานข้อมูล สำหรับ PostgreSQL คำสั่ง pg_dump ด้านบนคือทั้งหมดที่ต้องทำ สำหรับโปรแกรมอ่านฟีดที่ใช้ SQLite เช่น FreshRSS หรือ yarr ให้หยุดการเขียนข้อมูลแล้วคัดลอกไฟล์ หรือคัดลอกไฟล์ในขณะที่โปรแกรมทำงานอยู่ด้วย sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" การใช้ cp คัดลอกฐานข้อมูลที่กำลังมีการเขียนข้อมูลอยู่โดยตรงอาจทำให้ได้ไฟล์ที่ไม่สามารถเปิดได้ในภายหลัง เนื่องจากการคัดลอกอาจเก็บข้อมูลที่เขียนยังไม่เสร็จสมบูรณ์ จากนั้นให้ส่งไฟล์เหล่านั้นออกจากเซิร์ฟเวอร์ตามกำหนดเวลา ซึ่งเป็นสิ่งที่ การสำรองข้อมูลด้วย restic บน VPS มีไว้เพื่อการนี้ และควรลองกู้คืนข้อมูลลงในคอนเทนเนอร์ทดสอบอย่างน้อยหนึ่งครั้งเพื่อให้มั่นใจว่าขั้นตอนการทำงานนั้นใช้ได้จริง

โปรแกรมอ่านฟีดเป็นหนึ่งในบริการที่ประหยัดที่สุดในการดูแลด้วยตนเอง ซึ่งเป็นเหตุผลว่าทำไมมันจึงปรากฏอยู่ในทุกรายการของ สิ่งที่คุ้มค่าแก่การ self-host ในปี 2026 ลองติดตั้ง อินสแตนซ์ SearXNG ที่คุณดูแลเอง ไว้ข้างๆ กัน เพื่อให้ทั้งการอ่านและการค้นหาของคุณอยู่บนฮาร์ดแวร์ที่คุณควบคุมได้เอง

FAQ

RSS reader แบบ self-hosted ตัวไหนใช้หน่วยความจำน้อยที่สุด?

yarr เป็นตัวเลือกที่ประหยัดที่สุด เนื่องจากเป็นไฟล์ binary ภาษา Go เพียงไฟล์เดียวที่รวม SQLite มาในตัว จึงไม่ต้องใช้ database server หรือ runtime อื่นเพิ่มเติม และสามารถทำงานได้ดีภายใต้ข้อจำกัดหน่วยความจำที่ 128 MB สิ่งที่ต้องแลกคือฟีเจอร์ เพราะรองรับเฉพาะ Fever API เท่านั้น และรุ่นล่าสุดคือ v2.9 เมื่อเดือนกันยายน 2026 หากคุณต้องการรองรับ Google Reader API และการค้นหาข้อความแบบเต็ม (full text search) ในระดับการใช้ทรัพยากรที่ใกล้เคียงกัน Miniflux ร่วมกับ PostgreSQL ที่ 320 MB จะเป็นคำตอบที่ดีกว่า

ฉันสามารถรัน RSS reader แบบ self-hosted บน VPS ขนาด 1 GB ได้หรือไม่?

ได้ Miniflux ร่วมกับ PostgreSQL สามารถทำงานได้ภายในหน่วยความจำประมาณ 320 MB เมื่อคุณตั้งค่า mem_limit บน container ทั้งสองตัว ส่วน FreshRSS ที่ใช้ SQLite สามารถทำงานได้ใน container เดียว ตัวที่ควรหลีกเลี่ยงบน VPS ขนาด 1 GB คือ Tiny Tiny RSS stack แบบมาตรฐาน ซึ่งประกอบด้วยบริการจำนวน 4 รายการ รวมถึง PostgreSQL ของตัวเอง คุณควรตั้งค่าจำกัดหน่วยความจำเสมอ เพราะหาก container ไม่จำกัดการใช้งานและหน่วยความจำเต็ม kernel จะสั่ง kill process ทิ้ง ซึ่งมักจะเลือก kill ตัว database แทนที่จะเป็นตัวแอปพลิเคชันที่เป็นต้นเหตุ

ตัวไหนบ้างที่ใช้งานร่วมกับแอป RSS บน iOS และ Android ได้?

Miniflux, FreshRSS และ CommaFeed รุ่น 7.3.0 ขึ้นไป รองรับทั้ง Fever API และ Google Reader API ทำให้สามารถเชื่อมต่อกับ client บนมือถือได้เกือบทุกตัว ส่วน yarr รองรับเฉพาะ Fever API เท่านั้น สำหรับ Tiny Tiny RSS จะใช้ API ของตัวเอง คุณจึงต้องใช้ client ที่พัฒนามาเพื่อรองรับโดยเฉพาะ สำหรับ FreshRSS คุณต้องเปิดใช้งาน API access ในเมนู Authentication และตั้งค่า API password แยกต่างหากในหน้าโปรไฟล์ มิฉะนั้นแอปจะไม่สามารถล็อกอินได้แม้ว่าการเข้าใช้งานผ่านเว็บไซต์จะยังคงทำงานได้ปกติก็ตาม

การ export ไฟล์ OPML ถือเป็นการสำรองข้อมูล RSS reader ของฉันหรือไม่?

ไม่ OPML เป็นเพียงการสร้างรายการ subscription ของคุณขึ้นมาใหม่ แม้ว่าการ export แบบขยายของ FreshRSS จะรวมการตั้งค่าราย feed และตัวกรองมาด้วย แต่สถานะการอ่าน (read state), รายการที่ติดดาว (starred items) และเนื้อหาบทความทั้งหมดจะถูกเก็บอยู่ในฐานข้อมูล คุณต้องสำรองข้อมูลตัวฐานข้อมูลเองโดยใช้ pg_dump สำหรับ PostgreSQL หรือใช้คำสั่ง .backup สำหรับ SQLite แล้วคัดลอกไฟล์ผลลัพธ์ออกจากเซิร์ฟเวอร์

Miniflux รองรับ SQLite หรือไม่?

ไม่ เอกสารประกอบของโปรเจกต์ระบุว่า "ทำงานร่วมกับ PostgreSQL เท่านั้น" และฟีเจอร์การค้นหาข้อความแบบเต็มถูกพัฒนาโดยใช้ความสามารถเฉพาะของ PostgreSQL จึงไม่มีโหมดที่เบากว่านี้ให้เลือกใช้ หากคุณต้องการ feed reader ที่ไม่มี container ฐานข้อมูลเลย ให้เลือกใช้ FreshRSS โดยตั้งค่าเป็น SQLite backend ตามค่าเริ่มต้น หรือใช้ yarr ที่เก็บข้อมูลในไฟล์แบบ embedded แทน

#rss#self-hosted#docker#miniflux#freshrss