SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor

So sánh trình đọc RSS self-host trên VPS nhỏ

So sánh Miniflux, FreshRSS, CommaFeed, yarr và Tiny Tiny RSS về memory, database, API Fever, Google Reader và cách nâng cấp trên VPS.

Trình đọc RSS self-host nào phù hợp với VPS nhỏ

Miniflux là trình đọc RSS self-host phù hợp để chạy trên VPS nhỏ. Nó chỉ gồm một binary Go và PostgreSQL. Miniflux hỗ trợ API Fever và Google Reader, nên các ứng dụng điện thoại của bên thứ ba có thể kết nối. Khi nâng cấp, bạn chỉ cần một docker compose pull. Hãy chọn FreshRSS nếu bạn cần extension và muốn chạy mọi thứ trong một container có SQLite bên trong.

Có 5 trình đọc đáng dành dung lượng đĩa trên VPS: Miniflux, FreshRSS, CommaFeed, yarr và Tiny Tiny RSS. Trang này so sánh những điểm thực sự khác nhau giữa chúng: mỗi stack cần bao nhiêu memory, mỗi ứng dụng bắt buộc bạn dùng database nào, ứng dụng điện thoại cần API đồng bộ nào và quá trình nâng cấp diễn ra ra sao. Mỗi con số ở đây đều do project công bố hoặc được tính bằng phép tính đơn giản, và nội dung sẽ nói rõ nguồn nào được dùng. Đây không phải benchmark cho phần cứng của bạn, vì vậy hãy đo trên máy của bạn bằng docker stats.

Năm trình đọc, mỗi trình một đoạn

Miniflux được viết bằng Go và phát hành dưới dạng một binary duy nhất, được biên dịch tĩnh. Tài liệu của dự án nói rõ về dependency bắt buộc duy nhất: ứng dụng “chỉ hoạt động với PostgreSQL”. Không có chế độ SQLite. Ứng dụng cung cấp REST API, API tương thích với Fever và API tương thích với Google Reader, cùng chức năng import và export OPML. PostgreSQL đảm nhiệm full-text search. Đây cũng là một lý do database không phải là tùy chọn.

FreshRSS được viết bằng PHP và chạy trong một container chứa cả web server lẫn ứng dụng. SQLite là database mặc định và không cần service thứ hai. PostgreSQL và MySQL cũng được hỗ trợ cho các cài đặt lớn hơn. Ứng dụng hỗ trợ Google Reader API và Fever API. Phần cài đặt đã được trình bày trong hướng dẫn chạy FreshRSS trên VPS của chúng tôi, nên trang này chỉ so sánh thay vì lặp lại phần cài đặt.

CommaFeed được viết bằng Java trên Quarkus, với giao diện mô phỏng Google Reader. Database được chọn lúc build, không phải lúc chạy. Vì vậy, dự án phát hành một image cho từng database: athou/commafeed:latest-h2 cho database H2 nhúng sẵn, athou/commafeed:latest-postgresql cho PostgreSQL và các biến thể khác cho MySQL và MariaDB. Các tag đó là các bản build được biên dịch native. Hậu tố -jvm đánh dấu các biến thể chạy trên JVM. Ứng dụng cung cấp REST API và API tương thích với Fever. Từ version 7.3.0 (August 2026), ứng dụng cũng cung cấp API tương thích với Google Reader.

yarr (yet another rss reader) là một binary Go duy nhất, nhúng SQLite và không cần container. Lệnh ./yarr mặc định lắng nghe trên 127.0.0.1:7070. Các flag khá ngắn: -addr 0.0.0.0:7070 -auth alice:secret mở ứng dụng cho network phía sau một password, còn -db /data/yarr.db đặt database vào vị trí bạn muốn. Ứng dụng có Fever compatible API. Bản release mới nhất được tag là v2.9, phát hành vào September 2026 và được kiểm tra vào October 2026, sau v2.7 vào June và v2.8 vào July. Điều này cho thấy dự án đã được phát triển tích cực trở lại.

Tiny Tiny RSS là ứng dụng lâu đời nhất trong năm trình đọc và cũng nặng nhất khi vận hành. Dự án gốc tại tt-rss.org đã ngừng hoạt động vào 1 November 2025. Việc phát triển tiếp tục trong một community fork tại github.com/tt-rss/tt-rss. Tài liệu của fork này hiện là tài liệu setup chính thức. Setup gồm bốn service: một PostgreSQL container, một PHP-FPM application container, một updater container riêng để fetch feed và một nginx container ở phía trước. Tài liệu nói rõ rằng “setup này sử dụng PostgreSQL”. Ứng dụng có JSON API riêng. Android client của dự án và một số app bên thứ ba sử dụng API này. Fever không được hỗ trợ.

Mỗi stack cần bao nhiêu memory

Các con số dưới đây là ngân sách, không phải số đo thực tế: đây là mức trần memory mà mỗi stack nên nằm dưới khi chạy trên một VPS nhỏ. Con số của CommaFeed là ví dụ do chính dự án công bố, trong đó container bị giới hạn ở mức 256 MB. Các stack còn lại dùng mức trần có chừa headroom cho feed fetcher, vì thành phần này tăng memory đột biến khi bắt đầu một chu kỳ refresh.

Biểu đồMemory ceiling per reader stack, in MB
Dữ liệu đằng sau biểu đồ này
[
  {
    "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 dùng ít memory nhất, ở mức 128 MB, vì nó chỉ gồm một binary và một file SQLite, không có database server hay language runtime bên dưới. Miniflux cần 320 MB cho 2 container, trong đó phần lớn thuộc về PostgreSQL chứ không phải Miniflux. Tiny Tiny RSS là trường hợp khác biệt, ở mức 640 MB cho 4 container, vì application, updater, database và web server là 4 process riêng biệt với 4 heap riêng biệt.

Hãy đặt đây là các giới hạn thực tế, thay vì chỉ hy vọng. Giới hạn memory trong Docker Compose giải thích cú pháp và điều gì xảy ra khi container chạm mức trần. Container không có giới hạn sẽ không dừng một cách an toàn khi máy đã hết memory: kernel sẽ chọn một process để kill, và process đó thường không phải container gây ra tình trạng thiếu memory.

Mỗi trình đọc buộc bạn dùng database nào

Database là khác biệt lớn nhất về vận hành giữa 5 lựa chọn này. Đây là quyết định quan trọng hơn mọi khác biệt về giao diện người dùng, vì nó quyết định quy trình backup và rủi ro khi upgrade.

Miniflux và bộ cài Tiny Tiny RSS chính thức đều yêu cầu PostgreSQL. Đổi lại, bạn có full text search thực sự và khả năng ghi đồng thời an toàn. Chi phí là thêm một container, một volume và một vấn đề lặp lại: các image PostgreSQL chính thức không thể migrate dữ liệu giữa các major version ngay tại chỗ. Tài liệu Tiny Tiny RSS nói rõ điều này và cảnh báo rằng “official PostgreSQL containers have no support for migrating data between major versions”. Với một feed reader, các lựa chọn thực tế là giữ cố định major version cũ, hoặc dump rồi restore bằng pg_dump và pg_restore. PostgreSQL cũng có tài liệu về pg_upgrade và các hình thức upgrade dựa trên replication. Những cách này đáng công setup trên các database lớn, nơi downtime là vấn đề quan trọng. Database của một feed reader hiếm khi thuộc nhóm đó. Hãy chuẩn bị thực hiện việc này một lần mỗi 1 hoặc 2 năm.

SQLite là database mặc định của FreshRSS và yarr. Chỉ một file, không cần server, không cần port, không cần password. SQLite hoạt động tốt với một người dùng và vài trăm feed. Nó chậm lại khi nhiều người dùng cùng ghi dữ liệu. Khi đó, tùy chọn PostgreSQL của FreshRSS bắt đầu phát huy giá trị. yarr đã bổ sung hỗ trợ PostgreSQL tùy chọn trong v2.7, nhưng file embedded vẫn là cách chạy thông thường.

H2 là database embedded mặc định của CommaFeed. Bạn nên cân nhắc điều này trước khi bắt đầu, vì CommaFeed chọn database khi build image. Chuyển từ H2 sang PostgreSQL sau này không chỉ là thay đổi cấu hình. Đây là một image khác, kèm theo quá trình migrate dữ liệu mà bạn phải tự thực hiện. Vì vậy, hãy quyết định trước khi máy chủ đã lưu lịch sử đọc trong 1 năm.

Ứng dụng trên điện thoại của bạn có hoạt động không

Câu hỏi này quyết định nhiều hơn bạn nghĩ, vì giao diện web chỉ là một nửa cách bạn sử dụng feed reader.

Miniflux hỗ trợ API tương thích với Fever và API tương thích với Google Reader, nên hầu hết client trên iOS và Android đều kết nối được với nó. FreshRSS cũng hỗ trợ hai API này và tài liệu của dự án xếp hạng chúng: Google Reader API là "tốt nhất" với đầy đủ tính năng, còn Fever API có hành vi "tính năng hạn chế và kém hiệu quả hơn". FreshRSS cũng cần 2 bước trước khi bất kỳ app nào có thể đăng nhập. Bật "Cho phép truy cập API (bắt buộc cho app mobile)" trong mục Authentication, sau đó tạo API password trong user profile. Nếu bỏ qua API password, app sẽ báo lỗi xác thực trong khi đăng nhập qua web vẫn hoạt động. Điều này dễ gây nhầm lẫn nếu bạn chưa biết cần kiểm tra ở đâu.

CommaFeed hiện cũng hỗ trợ cả hai API: dự án này đã có API tương thích với Fever từ lâu, còn version 7.3.0 bổ sung API tương thích với Google Reader cho các app không hỗ trợ Fever. Vì vậy, hãy dùng 7.3.0 hoặc mới hơn nếu app của bạn chỉ hỗ trợ Google Reader. yarr cung cấp API tương thích với Fever và không cung cấp API nào khác, nên nó hoạt động với các client hỗ trợ Fever nhưng không hoạt động với các app chỉ hỗ trợ Google Reader. Tiny Tiny RSS có API riêng, nên bạn cần client được viết riêng cho nó. Hãy kiểm tra app bạn muốn dùng có hỗ trợ reader đó không trước khi import 300 feed vào hệ thống.

Tệp compose dùng được cho máy chủ 1 GB

Đây là stack Miniflux, được điều chỉnh từ ví dụ Docker của chính dự án vào tháng 10 năm 2026. Cổng public chỉ bind vào loopback, địa chỉ listen được đặt rõ ràng, và cả hai container đều có giới hạn memory.

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:

Có 3 dòng trong tệp này thường bị cấu hình sai. LISTEN_ADDR=0.0.0.0:8080 lặp lại thiết lập mà official image đã có trong Dockerfile, nên khi dùng cùng miniflux/miniflux, đây chỉ là biện pháp bảo vệ an toàn chứ không phải cách sửa lỗi. Thiết lập này quan trọng khi bạn tự build image hoặc chạy binary được đóng gói, vì default được ghi trong tài liệu của binary là 127.0.0.1:8080. Process bind vào loopback bên trong container sẽ không thể được truy cập qua published port, nên bạn sẽ nhận connection reset dù container vẫn có vẻ healthy. Đường dẫn volume /var/lib/postgresql khớp với PostgreSQL 18; version 17 trở về trước lưu dữ liệu tại /var/lib/postgresql/data. Nếu mount sai đường dẫn, data directory hoàn toàn không nằm trên volume, nên toàn bộ dữ liệu sẽ biến mất khi container được tạo lại lần tiếp theo. 127.0.0.1:8080:8080 giữ cho port không public trên Internet, vì publish port mà không chỉ định address sẽ ghi một rule vào chain mà ufw không quản lý. Docker port bypass ufw giải thích cơ chế này, còn reverse proxy Traefik là cách đặt TLS phía trước dịch vụ.

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

docker compose ps phải liệt kê cả hai service ở trạng thái running, trong đó database được đánh dấu healthy. Lần khởi động đầu tiên của Miniflux ghi log về các schema migration; đó là thao tác mà RUN_MIGRATIONS=1 kích hoạt. docker stats --no-stream in ra cột memory hiện tại. Đây là con số cần so sánh với các giới hạn trong bảng bên trên. Nếu container Miniflux restart liên tục, hãy đọc log của container: connect: connection refused có nghĩa là container khởi động trước khi PostgreSQL sẵn sàng nhận connection. Đây chính xác là tình huống mà điều kiện service_healthy ngăn chặn, vì vậy hãy kiểm tra xem điều kiện này còn nguyên sau khi bạn chỉnh sửa tệp hay không. Nếu Compose vẫn còn mới với bạn, Kiến thức cơ bản về Docker Compose trên VPS trình bày bố cục tệp trước.

Không phù hợp trên máy chủ 1 GB

Tiny Tiny RSS là ứng dụng nên bỏ qua. Stack 4 service chính thức của ứng dụng chạy được trên VPS 1 GB nếu VPS đó không làm việc gì khác. Nó không chạy ổn khi đặt cùng một ứng dụng khác dùng database và một reverse proxy. 4 service tương ứng với 4 nhóm overhead, trong đó có một service dùng PostgreSQL.

CommaFeed vẫn phù hợp, nhưng chỉ khi dùng image H2 và giới hạn 256 MB theo ví dụ của chính dự án. Mô hình làm máy chủ nhỏ quá tải là chạy CommaFeed cùng một database server riêng. Các biến thể image -jvm còn làm tình hình tệ hơn, vì tài liệu của dự án cảnh báo rằng JVM mặc định sử dụng nhiều bộ nhớ và không trả phần bộ nhớ chưa dùng về cho operating system. Các tag latest-h2 và latest-postgresql là native build. Dự án khuyến nghị chúng vì dùng ít bộ nhớ hơn. Vì vậy, hãy dùng các tag này trừ khi bạn có lý do cần chạy JVM.

Khi máy chủ hết bộ nhớ, kernel out-of-memory killer sẽ chọn một process và terminate process đó. dmesg -T hiển thị một dòng như Out of memory: Killed process 1234 (java). Container sau đó biến mất khỏi docker compose ps mà không có message nào trong application log, vì application chưa kịp ghi log.

Cách nâng cấp hoạt động trên từng ứng dụng

  • Miniflux: docker compose pull && docker compose up -d, các migration của schema được áp dụng khi khởi động trong lúc RUN_MIGRATIONS=1 được đặt. Rủi ro khi nâng cấp không nằm ở Miniflux. Nó nằm ở phiên bản major của PostgreSQL bên dưới.
  • FreshRSS: pull image mới. Với SQLite, không có database engine để nâng cấp, nên lỗi thường gặp thường đến từ các extension bên thứ ba chưa được cập nhật tương thích.
  • CommaFeed: pull variant của image tương ứng với database của bạn. Chuyển từ latest-h2 sang latest-postgresql không chuyển dữ liệu của bạn sang được.
  • yarr: thay binary và giữ nguyên file database. Các bản release được phát hành vào tháng 6, tháng 7 và tháng 9 năm 2026; v2.9 là bản mới nhất tính đến tháng 10 năm 2026, nên thỉnh thoảng hãy kiểm tra trang release.
  • Tiny Tiny RSS: docker compose pull && docker compose up -d. Application container tự cập nhật khi khởi động. FAQ của dự án liên hệ lỗi cập nhật schema với volume hoặc cấu hình override bị hỏng, nên hãy kiểm tra các phần này trước nếu lỗi xuất hiện. Nếu file compose của bạn vẫn pull image từ dự án tt-rss.org đã ngừng hoạt động, hãy chuyển sang image của fork (supahgreg/tt-rss trên Docker Hub hoặc ghcr.io/tt-rss/tt-rss).

Hãy tạo database dump trước khi thực hiện bất kỳ thao tác nào trong số này, không phải sau đó.

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

Chi phí băng thông của chu kỳ làm mới

Các con số dưới đây là phép tính, không phải số đo thực tế. Chúng giả định có 100 feed, mỗi feed nhận một request trong mỗi chu kỳ và mỗi response có kích thước 40 KB. Lưu lượng thực tế sẽ thấp hơn khi server hỗ trợ conditional request, và cao hơn khi feed chứa toàn bộ nội dung bài viết.

Biểu đồMonthly fetches and bandwidth for 100 feeds at 40 KB per response
Dữ liệu đằng sau biểu đồ này
[
  {
    "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
  }
]

Chu kỳ 5 phút với 100 feed tạo ra 864,000 request và tiêu thụ khoảng 34.6 GB mỗi tháng. Polling mỗi giờ tạo ra 72,000 request và tiêu thụ khoảng 2.9 GB. Miniflux mặc định đặt POLLING_FREQUENCY là 60 phút, tương ứng với dòng cuối trong biểu đồ đó. Giá trị mặc định này phù hợp với gần như mọi trường hợp. Bài viết không xuất hiện sớm hơn chỉ vì bạn yêu cầu thường xuyên hơn.

Conditional request là yếu tố giữ lưu lượng thực tế thấp hơn phép tính. Reader lưu các header ETag và Last-Modified do feed trả về sẽ gửi lại chúng dưới dạng If-None-Match và If-Modified-Since. Khi không có nội dung mới, server trả về 304 Not Modified mà không có body. Kết nối vẫn tốn chi phí handshake, nhưng không phải tải payload. Những feed không hỗ trợ conditional request sẽ gửi toàn bộ tài liệu trong mỗi lần request. Vì vậy, chỉ vài feed lớn cũng có thể tự chiếm phần lớn dung lượng transfer của bạn.

Polling quá thường xuyên cũng khiến bạn bị chặn. Server phát hiện bạn đang gửi request quá dồn dập sẽ trả về 429 Too Many Requests, còn một số site sẽ trả về 403. Miniflux ghi lại lỗi gần nhất ngay trên feed. Vì vậy, danh sách feed là nơi đầu tiên cần kiểm tra khi một feed ngừng cập nhật trong khi các feed khác vẫn hoạt động.

Feed sẽ ngừng hoạt động, còn file OPML không phải là bản backup

Feed hỏng sớm hơn bạn nghĩ. Domain hết hạn, website chuyển sang nền tảng không có feed, và một URL từng trả về XML bắt đầu trả về trang lỗi HTML với status 200 OK. Trường hợp cuối khó phát hiện nhất: fetch thành công, parse thất bại, và reader ghi nhận lỗi parse thay vì lỗi network. Mỗi năm một lần, hãy sắp xếp danh sách feed theo thời điểm cập nhật gần nhất rồi xóa những feed đã im lặng quá lâu.

Export OPML là danh sách subscription của bạn. Một file OPML chuẩn chứa URL của feed và tên folder. FreshRSS thêm XML namespace riêng để lưu các cài đặt theo từng feed, chẳng hạn refresh interval, XPath scraping selector và auto-read filter. Tuy nhiên, không có export OPML nào lưu trạng thái đã đọc, bài viết được đánh dấu sao hoặc nội dung bài viết bạn đã lưu. Khi import OPML đó vào một bản cài đặt mới, bạn lấy lại được các feed, nhưng mọi bài viết từng đọc sẽ lại bị đánh dấu là chưa đọc.

Bản backup quan trọng là database. Với PostgreSQL, command pg_dump ở trên thực hiện toàn bộ công việc. Với reader dùng SQLite như FreshRSS hoặc yarr, hãy dừng writer rồi copy file, hoặc tạo một bản copy nhất quán trong lúc reader vẫn chạy bằng sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". Một bản cp thông thường của database đang được ghi có thể tạo ra file không mở được về sau, vì bản copy chứa một lần ghi chưa hoàn tất. Sau đó, hãy đẩy các file đó ra khỏi máy theo lịch định kỳ. Đây là mục đích của restic backup trên VPS. Ít nhất một lần, hãy restore một bản vào scratch container để xác nhận quy trình hoạt động.

Feed reader là một trong những service rẻ nhất để tự vận hành. Vì vậy, nó xuất hiện trong mọi danh sách những thứ đáng tự host trong 2026. Hãy đặt một instance SearXNG tự host bên cạnh nó để cả việc đọc và tìm kiếm đều chạy trên hardware do bạn kiểm soát.

FAQ

Trình đọc RSS tự host nào dùng ít memory nhất?

yarr. Đây là một binary Go duy nhất có tích hợp SQLite, nên không cần database server hoặc language runtime riêng, và giới hạn 128 MB là đủ thoải mái. Đổi lại, tính năng bị giới hạn: ứng dụng chỉ hỗ trợ Fever API, và bản release mới nhất là v2.9 từ tháng 9 năm 2026. Nếu bạn cần Google Reader API và tìm kiếm toàn văn với mức sử dụng tài nguyên tương tự, Miniflux kết hợp với PostgreSQL ở mức 320 MB là lựa chọn phù hợp hơn.

Tôi có thể chạy trình đọc RSS tự host trên VPS 1 GB không?

Có. Miniflux kết hợp với PostgreSQL dùng khoảng 320 MB khi bạn đặt mem_limit cho cả hai container, còn FreshRSS với SQLite có thể chạy trong một container. Trên VPS 1 GB, bạn nên tránh stack Tiny Tiny RSS chính thức. Stack này gồm 4 service, trong đó có PostgreSQL riêng. Luôn đặt memory limit, vì container không giới hạn trên máy đã đầy memory sẽ khiến kernel kill một process. Process bị chọn thường là database thay vì application gây ra sự cố.

Những ứng dụng nào trong số này hoạt động với app RSS trên iOS và Android?

Miniflux, FreshRSS và CommaFeed 7.3.0 trở lên đều hỗ trợ cả Fever compatible API và Google Reader compatible API, nên gần như mọi mobile client đều có thể kết nối. yarr chỉ cung cấp Fever API. Tiny Tiny RSS sử dụng API riêng, nên bạn cần client được xây dựng cho nó. Trên FreshRSS, bạn cũng phải bật quyền truy cập API trong Authentication và đặt API password riêng trong profile. Nếu không, app sẽ không đăng nhập được trong khi website vẫn hoạt động.

OPML export có phải là bản backup của trình đọc RSS không?

Không. OPML khôi phục danh sách subscription. Extended export của FreshRSS cũng chứa các thiết lập và filter riêng của từng feed, nhưng read state, starred item và nội dung bài viết đều nằm trong database. Hãy backup chính database bằng pg_dump cho PostgreSQL hoặc lệnh .backup cho SQLite, rồi copy kết quả ra khỏi server.

Miniflux có hỗ trợ SQLite không?

Không. Tài liệu của project ghi rõ rằng nó “chỉ hoạt động với PostgreSQL”, và chức năng tìm kiếm toàn văn được triển khai bằng các tính năng của PostgreSQL, nên không có mode nhẹ hơn để chuyển sang. Nếu bạn muốn một trình đọc feed không cần database container, hãy chạy FreshRSS với SQLite backend mặc định hoặc yarr với file được tích hợp sẵn.