Pilihan RSS Reader Terbaik untuk VPS Sendiri

Pembaca RSS layan diri (self-hosted) yang manakah sesuai untuk VPS kecil

Miniflux ialah pembaca RSS layan diri untuk dipasang pada VPS kecil. Ia terdiri daripada satu binari Go di samping PostgreSQL. Ia menyokong API Fever dan Google Reader, membolehkan aplikasi telefon pihak ketiga disambungkan, dan naik taraf hanya memerlukan satu docker compose pull. Pilih FreshRSS jika anda mahukan sambungan (extensions) dan satu kontena yang mengandungi SQLite di dalamnya.

Terdapat lima pembaca yang berbaloi dengan ruang cakera pada VPS: Miniflux, FreshRSS, CommaFeed, yarr dan Tiny Tiny RSS. Halaman ini membandingkan perbezaan sebenar antara kesemuanya: memori yang diperlukan oleh setiap tindanan (stack), pangkalan data yang diwajibkan oleh setiap satu, API penyelarasan yang diperlukan oleh aplikasi telefon anda, dan apa yang berlaku pada hari naik taraf. Setiap angka di sini sama ada diterbitkan oleh projek tersebut atau hasil pengiraan mudah, dan teks ini menyatakan yang mana satu. Tiada satu pun daripada ini merupakan penanda aras (benchmark) perkakasan anda, jadi ukur kotak anda sendiri dengan docker stats.

Lima pembaca, satu perenggan setiap satu

Miniflux ditulis dalam Go dan diedarkan sebagai satu binari yang dikompil secara statik. Dokumentasinya menyatakan dengan jelas tentang satu dependency wajib: ia "hanya berfungsi dengan PostgreSQL". Tiada mod SQLite. Ia menawarkan REST API, API yang serasi dengan Fever, dan API yang serasi dengan Google Reader, serta fungsi import dan eksport OPML. Carian teks penuh diserahkan kepada PostgreSQL, yang merupakan sebab mengapa pangkalan data tersebut tidak boleh diketepikan.

FreshRSS berasaskan PHP dan berjalan sebagai satu kontena yang mengandungi kedua-dua pelayan web dan aplikasi. SQLite ialah pangkalan data lalai dan tidak memerlukan servis kedua, manakala PostgreSQL dan MySQL disokong untuk pemasangan yang lebih besar. Ia menyokong API Google Reader dan API Fever. Pemasangannya telah pun dibincangkan dalam panduan FreshRSS kami di VPS, jadi halaman ini membuat perbandingan dan bukannya mengulangi proses pemasangan tersebut.

CommaFeed ialah aplikasi Java berasaskan Quarkus dengan reka letak yang meniru Google Reader. Pangkalan datanya dipilih semasa fasa binaan (build time), bukan semasa runtime, jadi projek ini menerbitkan satu imej bagi setiap pangkalan data: athou/commafeed:latest-h2 untuk pangkalan data H2 terbenam, athou/commafeed:latest-postgresql untuk PostgreSQL, dan varian lain untuk MySQL serta MariaDB. Tag tersebut adalah binaan yang dikompil secara natif, dan akhiran -jvm menandakan varian yang berjalan di atas JVM. Ia mendedahkan REST API dan API yang serasi dengan Fever, serta sejak versi 7.3.0 (Ogos 2026), ia turut menyertakan API yang serasi dengan Google Reader.

yarr (yet another rss reader) ialah satu binari Go dengan SQLite terbenam, dan ia tidak memerlukan kontena langsung. ./yarr biasa mendengar pada 127.0.0.1:7070. Flag yang digunakan adalah ringkas: -addr 0.0.0.0:7070 -auth alice:secret membukanya kepada rangkaian di sebalik kata laluan, dan -db /data/yarr.db meletakkan pangkalan data di lokasi pilihan anda. Ia mempunyai API yang serasi dengan Fever. Keluaran berlabel terbaharunya ialah v2.9, dari September 2026, disemak pada Oktober 2026, menyusuli v2.7 pada Jun dan v2.8 pada Julai, jadi ia sedang dibangunkan semula secara aktif.

Tiny Tiny RSS adalah yang tertua daripada kelima-lima pembaca ini dan yang paling berat untuk dijalankan. Projek asal di tt-rss.org telah ditamatkan pada 1 November 2025, dan pembangunan diteruskan dalam fork komuniti di github.com/tt-rss/tt-rss, yang dokumentasinya kini menjadi panduan persediaan rasmi. Persediaan tersebut melibatkan empat servis: kontena PostgreSQL, kontena aplikasi PHP-FPM, kontena pengemaskini berasingan yang mengambil suapan (feeds), dan kontena nginx di hadapan. Dokumentasinya menyatakan dengan jelas bahawa "persediaan ini menggunakan PostgreSQL". Ia mempunyai API JSON sendiri, yang digunakan oleh klien Androidnya dan beberapa aplikasi pihak ketiga. Fever tidak disertakan di dalamnya.

Berapakah memori yang diperlukan oleh setiap stack

Angka di bawah adalah belanjawan, bukan ukuran: had siling memori yang perlu dipatuhi oleh setiap stack pada VPS kecil. Angka untuk CommaFeed adalah contoh yang diterbitkan oleh projek itu sendiri, yang mengehadkan container pada 256 MB. Angka lain adalah siling yang memberikan ruang untuk pengambil suapan (feed fetcher), iaitu bahagian yang melonjak apabila kitaran muat semula bermula.

[
  {
    "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 berada pada tahap terendah iaitu 128 MB kerana ia terdiri daripada satu binari dan satu fail SQLite, tanpa pelayan pangkalan data atau runtime bahasa di bawahnya. Miniflux memerlukan 320 MB merentasi 2 container, dan sebahagian besar daripadanya digunakan oleh PostgreSQL dan bukannya Miniflux. Tiny Tiny RSS adalah pengecualian pada 640 MB merentasi 4 container, kerana aplikasi, pengemas kini, pangkalan data dan pelayan web adalah empat proses berasingan dengan empat heap yang berasingan.

Tetapkan nilai ini sebagai had sebenar dan bukannya sekadar harapan. Had memori dalam Docker Compose merangkumi sintaks dan tindakan yang dilakukan oleh container apabila ia mencapai siling tersebut. Container tanpa had tidak akan gagal dengan teratur pada pelayan yang penuh: kernel akan memilih proses mangsa dan menamatkannya, dan mangsa tersebut selalunya bukanlah container yang menyebabkan tekanan memori.

Pangkalan data yang dipaksa oleh setiap pembaca ke atas anda

Pangkalan data merupakan perbezaan operasi paling besar antara kelima-lima pilihan ini. Ia adalah keputusan yang lebih besar daripada sebarang perbezaan pada antara muka pengguna, kerana ia menentukan prosedur sandaran dan risiko naik taraf anda.

PostgreSQL diperlukan oleh Miniflux dan oleh tetapan rasmi Tiny Tiny RSS. Ia memberikan carian teks penuh yang sebenar dan penulisan serentak yang selamat. Ia memerlukan satu kontena tambahan, satu volum, dan satu masalah berulang: imej rasmi PostgreSQL tidak boleh memigrasikan data antara versi utama secara terus (in-place). Dokumentasi Tiny Tiny RSS menyatakan perkara ini secara langsung, dan memberi amaran bahawa "imej PostgreSQL rasmi tidak mempunyai sokongan untuk memigrasikan data antara versi utama". Bagi pembaca suapan (feed reader), pilihan realistik anda adalah dengan menetapkan versi utama yang lama, atau melakukan dump dan restore menggunakan pg_dump dan pg_restore. PostgreSQL juga mendokumentasikan pg_upgrade dan naik taraf berasaskan replikasi, yang berbaloi dengan tetapan tambahan pada pangkalan data besar di mana waktu henti (downtime) menjadi isu, namun pangkalan data pembaca suapan jarang sekali tergolong dalam kategori tersebut. Rancang untuk perkara ini sekali setiap satu atau dua tahun.

SQLite ialah lalai untuk FreshRSS dan yarr. Satu fail, tiada pelayan, tiada port, tiada kata laluan. Ia berfungsi dengan baik untuk seorang pengguna dengan beberapa ratus suapan, dan ia menjadi perlahan apabila beberapa pengguna menulis secara serentak, iaitu ketika pilihan PostgreSQL pada FreshRSS mula menunjukkan nilainya. yarr menambah sokongan PostgreSQL pilihan dalam v2.7, tetapi fail terbenam (embedded) adalah cara biasa untuk menjalankannya.

H2 ialah lalai terbenam untuk CommaFeed, dan ia memerlukan sedikit pertimbangan sebelum anda bermula, kerana CommaFeed memilih pangkalan datanya semasa imej dibina. Berpindah daripada H2 ke PostgreSQL kemudian hari bukanlah sekadar perubahan konfigurasi. Ia melibatkan imej yang berbeza berserta migrasi data yang perlu anda lakukan sendiri, jadi buat keputusan sebelum anda mempunyai sejarah bacaan selama setahun di dalamnya.

Adakah aplikasi telefon anda akan berfungsi

Soalan ini menentukan lebih banyak perkara daripada yang dijangkakan, kerana antara muka web hanyalah separuh daripada cara pembaca suapan (feed reader) digunakan.

Miniflux menyokong API yang serasi dengan Fever dan API yang serasi dengan Google Reader, jadi kebanyakan klien iOS dan Android boleh bersambung dengannya. FreshRSS menyokong kedua-dua API tersebut, dan dokumentasinya sendiri menyusun kedudukannya: API Google Reader adalah "terbaik" dengan sokongan ciri penuh, manakala API Fever mempunyai "ciri terhad dan kurang cekap". FreshRSS juga memerlukan dua langkah sebelum sebarang aplikasi boleh log masuk. Dayakan "Allow API access (required for mobile apps)" di bawah Authentication, kemudian cipta kata laluan API dalam profil pengguna. Melangkau langkah kata laluan API akan menyebabkan kegagalan pengesahan dalam aplikasi walaupun log masuk web terus berfungsi, yang mengelirukan sehingga anda tahu di mana untuk menyemaknya.

CommaFeed kini menyokong kedua-duanya juga: ia telah lama mempunyai API yang serasi dengan Fever, dan versi 7.3.0 menambah API yang serasi dengan Google Reader untuk aplikasi yang tidak menyokong Fever, jadi jalankan versi 7.3.0 atau lebih baharu jika aplikasi anda hanya menyokong Google Reader. yarr mendedahkan API yang serasi dengan Fever sahaja, jadi ia berfungsi dengan klien yang menyokong Fever dan tidak berfungsi dengan aplikasi yang hanya menyokong Google Reader. Tiny Tiny RSS sebaliknya mempunyai API sendiri, yang bermaksud anda memerlukan klien yang ditulis khusus untuknya. Pastikan aplikasi pilihan anda menyokong pembaca tersebut sebelum anda mengimport 300 suapan ke dalamnya.

Fail compose yang berfungsi untuk pelayan 1 GB

Ini adalah stack Miniflux, yang diadaptasi daripada contoh Docker rasmi projek tersebut setakat Oktober 2026. Port yang diterbitkan diikat pada loopback, alamat pendengar ditetapkan secara eksplisit, dan kedua-dua container mempunyai had memori.

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:

Tiga baris dalam fail tersebut sering disalah anggap oleh pengguna. LISTEN_ADDR=0.0.0.0:8080 mengulangi apa yang telah ditetapkan oleh imej rasmi dalam Dockerfile-nya, jadi dengan miniflux/miniflux ia merupakan langkah keselamatan yang tidak berbahaya dan bukannya satu pembaikan. Ia menjadi penting apabila anda membina imej sendiri atau menjalankan binari yang dipakejkan, kerana lalai yang didokumentasikan bagi binari tersebut ialah 127.0.0.1:8080, dan proses yang diikat pada loopback di dalam container tidak boleh dicapai melalui port yang diterbitkan. Akibatnya, anda akan mendapat ralat connection reset walaupun container kelihatan sihat. Laluan volum /var/lib/postgresql sepadan dengan PostgreSQL 18; versi 17 dan sebelumnya menyimpan data dalam /var/lib/postgresql/data, dan memasang laluan yang salah bermakna direktori data tidak berada pada volum tersebut, jadi segala-galanya akan hilang apabila container dicipta semula. 127.0.0.1:8080:8080 menghalang port daripada terdedah kepada internet awam, kerana menerbitkan port tanpa alamat akan menulis peraturan ke dalam chain yang tidak diuruskan oleh ufw. Docker ports bypass ufw menjelaskan mekanisme tersebut, dan a Traefik reverse proxy adalah cara anda meletakkan TLS di hadapannya.

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

docker compose ps sepatutnya menyenaraikan kedua-dua servis sebagai sedang berjalan, dengan pangkalan data ditandakan sebagai healthy. Permulaan pertama Miniflux akan mencatat migrasi skema dalam log, iaitu perkara yang dicetuskan oleh RUN_MIGRATIONS=1. docker stats --no-stream memaparkan lajur memori semasa, dan itulah angka yang perlu dibandingkan dengan had siling dalam carta di atas. Jika container Miniflux dimulakan semula secara berulang, baca lognya: connect: connection refused bermakna ia bermula sebelum PostgreSQL bersedia untuk menerima sambungan, yang sebenarnya merupakan perkara yang dicegah oleh syarat service_healthy, jadi pastikan syarat tersebut masih ada selepas anda membuat suntingan. Jika Compose merupakan perkara baharu bagi anda, Docker Compose basics on a VPS merangkumi susun atur fail tersebut terlebih dahulu.

Perkara yang tidak muat pada pelayan 1 GB

Tiny Tiny RSS ialah aplikasi yang perlu dielakkan. Stak empat servis rasminya boleh berjalan pada VPS 1 GB jika VPS tersebut tidak menjalankan tugas lain, namun ia tidak akan berjalan di samping aplikasi berasaskan pangkalan data yang lain serta reverse proxy. Empat servis bermakna empat set overhead, dan salah satunya ialah PostgreSQL.

CommaFeed boleh dimuatkan, tetapi hanya dengan imej H2 dan had 256 MB yang ditetapkan oleh contoh projek itu sendiri. Gandingan yang akan membebankan pelayan kecil ialah CommaFeed yang diletakkan bersebelahan dengan pelayan pangkalan data yang berasingan, dan varian imej -jvm memburukkan lagi keadaan. Hal ini kerana dokumentasi projek memberi amaran bahawa JVM bersifat tamak secara lalai dan tidak memulangkan memori yang tidak digunakan kepada sistem pengendalian. Tag latest-h2 dan latest-postgresql merupakan binaan natif yang disyorkan oleh projek tersebut kerana penggunaan memorinya yang lebih rendah, jadi kekalkan penggunaan tag tersebut melainkan anda mempunyai sebab untuk menjalankan JVM.

Apabila pelayan kehabisan memori, kernel out of memory killer akan memilih satu proses dan menamatkannya. dmesg -T menunjukkan baris seperti Out of memory: Killed process 1234 (java), dan kontena tersebut akan hilang begitu sahaja daripada docker compose ps tanpa sebarang mesej dalam log aplikasi, kerana aplikasi tersebut tidak sempat menulis sebarang mesej.

Bagaimana naik taraf berfungsi bagi setiap satu

• Miniflux: docker compose pull && docker compose up -d, dengan migrasi skema digunakan semasa permulaan apabila RUN_MIGRATIONS=1 ditetapkan. Risiko naik taraf bukanlah pada Miniflux, tetapi pada versi utama PostgreSQL yang mendasarinya.
• FreshRSS: tarik imej baharu. Dengan SQLite, tiada enjin pangkalan data untuk dinaik taraf, jadi kerosakan biasanya berpunca daripada sambungan pihak ketiga yang tidak dikemaskini.
• CommaFeed: tarik varian imej yang sepadan dengan pangkalan data anda. Penukaran daripada latest-h2 kepada latest-postgresql tidak memindahkan data anda.
• yarr: gantikan fail binari dan kekalkan fail pangkalan data. Versi keluaran muncul pada Jun, Julai dan September 2026, dengan v2.9 sebagai yang terbaharu setakat Oktober 2026, jadi semak halaman keluaran dari semasa ke semasa.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Kontena aplikasi mengemaskini dirinya sendiri semasa permulaan, dan FAQ projek tersebut mengaitkan ralat kemaskini skema dengan volum yang rosak atau tetapan override, jadi semak perkara tersebut dahulu jika ralat muncul. Jika fail compose anda masih menarik imej daripada projek tt-rss.org yang telah ditamatkan, tukar kepada imej fork (supahgreg/tt-rss di Docker Hub atau ghcr.io/tt-rss/tt-rss).

Ambil dump pangkalan data sebelum melakukan mana-mana langkah ini, bukan selepasnya.

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

Kos lebar jalur bagi selang muat semula

Angka di bawah adalah pengiraan aritmetik, bukan ukuran sebenar. Ia mengandaikan 100 suapan (feeds), satu permintaan bagi setiap suapan untuk setiap selang, dan 40 KB bagi setiap respons. Trafik sebenar adalah lebih rendah apabila pelayan mematuhi permintaan bersyarat, dan lebih tinggi apabila suapan mengandungi teks artikel penuh.

[
  {
    "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
  }
]

Selang lima minit bagi 100 suapan adalah 864,000 permintaan dan kira-kira 34.6 GB sebulan. Pengundian setiap jam adalah 72,000 permintaan dan kira-kira 2.9 GB. Miniflux diedarkan dengan POLLING_FREQUENCY ditetapkan kepada 60 minit, iaitu baris terakhir dalam carta tersebut, dan tetapan lalai itu adalah tepat untuk hampir semua pengguna. Sesuatu artikel tidak akan tiba lebih awal hanya kerana anda memintanya dengan lebih kerap.

Permintaan bersyarat adalah perkara yang memastikan angka sebenar kekal di bawah pengiraan aritmetik. Pembaca yang menyimpan pengepala ETag dan Last-Modified yang dikembalikan oleh suapan akan menghantarnya semula sebagai If-None-Match dan If-Modified-Since, dan pelayan yang tidak mempunyai kandungan baharu akan menjawab 304 Not Modified tanpa badan mesej. Sambungan tersebut masih menanggung kos jabat tangan (handshake), tetapi bukan muatan (payload). Suapan yang mengabaikan permintaan bersyarat akan memberikan keseluruhan dokumen setiap kali, jadi beberapa suapan besar boleh mendominasi bil pemindahan data anda secara sendirian.

Pengundian yang terlalu kerap juga menyebabkan anda disekat. Pelayan yang memutuskan bahawa anda sedang melakukan serangan akan membalas dengan 429 Too Many Requests, dan sesetengah tapak menjawab dengan 403. Miniflux merekodkan ralat terakhir pada suapan itu sendiri, jadi senarai suapan adalah tempat pertama untuk diperiksa apabila satu suapan berhenti dikemas kini sementara yang lain terus berfungsi.

Suapan mati, dan fail OPML bukanlah sandaran

Suapan menjadi usang lebih cepat daripada yang anda jangka. Domain tamat tempoh, tapak berpindah ke platform tanpa suapan, dan URL yang dahulunya menghoskan XML mula menghoskan halaman ralat HTML dengan status 200 OK. Kes terakhir ini adalah yang paling menyusahkan: pengambilan berjaya, penghuraian gagal, dan pembaca anda merekodkan ralat penghuraian dan bukannya ralat rangkaian. Sekali setahun, susun senarai suapan mengikut kemas kini terakhir dan padamkan apa yang telah senyap.

Eksport OPML ialah senarai langganan anda. Fail OPML standard menyimpan URL suapan dan nama folder. FreshRSS menambah namespace XML sendiri yang turut membawa tetapan setiap suapan seperti selang masa muat semula, pemilih scraping XPath dan penapis baca-automatik, tetapi tiada eksport OPML menyimpan status baca, artikel berbintang atau teks artikel yang anda simpan. Import OPML tersebut ke dalam pemasangan baharu dan anda akan mendapat semula suapan anda dengan setiap artikel yang pernah anda baca ditandakan sebagai belum dibaca semula.

Sandaran yang penting ialah pangkalan data. Untuk PostgreSQL, arahan pg_dump di atas adalah keseluruhan tugasnya. Untuk pembaca SQLite seperti FreshRSS atau yarr, hentikan penulis dan salin fail tersebut, atau ambil salinan konsisten semasa ia berjalan dengan sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'". cp biasa bagi pangkalan data yang sedang ditulis boleh menghasilkan fail yang tidak akan terbuka kemudian, kerana salinan tersebut menangkap penulisan yang belum selesai. Kemudian, pindahkan fail tersebut keluar dari pelayan mengikut jadual, itulah tujuan sandaran restic pada VPS, dan pulihkan satu ke dalam bekas percubaan sekurang-kurangnya sekali supaya anda tahu prosedur tersebut berfungsi.

Pembaca suapan adalah salah satu servis paling murah untuk dikendalikan sendiri, itulah sebabnya ia muncul dalam setiap senarai perkara yang berbaloi untuk dihoskan sendiri pada 2026. Letakkan instans SearXNG yang dihoskan sendiri di sebelahnya dan kedua-dua aktiviti membaca serta mencari anda kekal pada perkakasan yang anda kawal.

FAQ

Pembaca RSS self-hosted yang manakah menggunakan memori paling sedikit?

yarr. Ia merupakan satu binari Go dengan SQLite yang dikompilasi bersama, jadi tiada pelayan pangkalan data atau runtime bahasa lain yang diperlukan, dan had 128 MB sudah memadai. Kekurangannya ialah dari segi ciri: ia hanya menyokong Fever API, dan keluaran terbaharunya ialah v2.9 dari September 2026. Jika anda mahukan sokongan Google Reader API dan carian teks penuh dengan penggunaan sumber yang serupa, Miniflux bersama PostgreSQL pada 320 MB adalah pilihan yang lebih baik.

Bolehkah saya menjalankan pembaca RSS self-hosted pada VPS 1 GB?

Boleh. Miniflux bersama PostgreSQL boleh dimuatkan dalam sekitar 320 MB apabila anda menetapkan mem_limit pada kedua-dua kontena, dan FreshRSS dengan SQLite boleh dimuatkan dalam satu kontena. Servis yang perlu dielakkan pada 1 GB ialah stack rasmi Tiny Tiny RSS, yang terdiri daripada 4 servis termasuk PostgreSQL miliknya sendiri. Sentiasa tetapkan had memori, kerana kontena tanpa had pada pelayan yang penuh akan menyebabkan proses dimatikan oleh kernel, dan proses yang dipilih selalunya adalah pangkalan data dan bukannya aplikasi yang bermasalah.

Yang manakah antara ini berfungsi dengan aplikasi RSS iOS dan Android?

Miniflux, FreshRSS dan CommaFeed 7.3.0 atau lebih baharu menyokong kedua-dua API yang serasi dengan Fever dan API yang serasi dengan Google Reader, jadi hampir mana-mana klien mudah alih boleh disambungkan. yarr hanya menawarkan Fever API. Tiny Tiny RSS menggunakan API tersendiri, jadi anda memerlukan klien yang dibina khusus untuknya. Pada FreshRSS, anda juga mesti mendayakan akses API di bawah Authentication dan menetapkan kata laluan API yang berasingan dalam profil, jika tidak aplikasi akan gagal untuk log masuk walaupun laman web masih berfungsi.

Adakah eksport OPML merupakan sandaran bagi pembaca RSS saya?

Tidak. OPML membina semula senarai langganan anda, dan eksport lanjutan FreshRSS juga membawa tetapan serta penapis bagi setiap feed, tetapi status bacaan, item yang ditanda bintang dan teks artikel semuanya berada dalam pangkalan data. Sandarkan pangkalan data itu sendiri menggunakan pg_dump untuk PostgreSQL, atau arahan .backup untuk SQLite, dan salin hasilnya keluar dari pelayan.

Adakah Miniflux menyokong SQLite?

Tidak. Dokumentasi projek menyatakan ia "hanya berfungsi dengan PostgreSQL", dan carian teks penuh dilaksanakan menggunakan ciri PostgreSQL, jadi tiada mod yang lebih ringan untuk ditukar. Jika anda mahukan pembaca feed tanpa sebarang kontena pangkalan data, jalankan FreshRSS dengan backend SQLite lalainya atau yarr dengan fail terbenamnya.