VPS için self-hosted RSS okuyucu karşılaştırması

Küçük bir VPS için hangi self-hosted RSS okuyucu uygundur?

Miniflux, küçük bir VPS üzerinde çalıştırılabilecek self-hosted RSS okuyucudur. PostgreSQL'in yanında çalışan tek bir Go binary dosyasından oluşur. Fever ve Google Reader API'lerini destekler; bu nedenle üçüncü taraf telefon uygulamaları bağlanabilir. Yükseltme işlemi tek bir docker compose pull gerektirir. Eklentiler ve içinde SQLite bulunan tek bir container istediğinizde FreshRSS tercih edilmelidir.

Bir VPS üzerinde disk alanı ayırmaya değer beş okuyucu vardır: Miniflux, FreshRSS, CommaFeed, yarr ve Tiny Tiny RSS. Bu sayfa, aralarındaki gerçek farkları karşılaştırır: her stack'in ihtiyaç duyduğu bellek, her birinin zorunlu kıldığı veritabanı, telefon uygulamanızın ihtiyaç duyduğu sync API ve yükseltme gününde yaşananlar. Buradaki her değer ya proje tarafından yayımlanmıştır ya da basit bir aritmetik hesabın sonucudur; metin hangisinin geçerli olduğunu belirtir. Bunların hiçbiri donanımınız üzerinde yapılmış bir benchmark değildir. Bu nedenle kendi sisteminizi docker stats ile ölçün.

Beş okuyucu, her biri bir paragrafta

Miniflux, Go ile yazılmıştır ve statik olarak derlenmiş tek bir binary olarak dağıtılır. Belgelerinde tek zorunlu bağımlılık açıkça belirtilir: Yalnızca PostgreSQL ile çalışır. SQLite modu yoktur. REST API, Fever uyumlu API ve Google Reader uyumlu API desteğinin yanı sıra OPML içe ve dışa aktarma özellikleri sunar. Tam metin araması PostgreSQL'e devredilir. Veritabanının isteğe bağlı olmamasının nedenlerinden biri budur.

FreshRSS, PHP ile yazılmıştır ve web sunucusu ile uygulamayı birlikte barındıran tek bir container olarak çalışır. SQLite varsayılan veritabanıdır ve ikinci bir servis gerektirmez. Daha büyük kurulumlar için PostgreSQL ve MySQL de desteklenir. Google Reader API ve Fever API ile iletişim kurabilir. Kurulum VPS üzerinde FreshRSS kurulum rehberimizde zaten ele alındığından bu sayfada kurulum tekrarlanmaz, karşılaştırma yapılır.

CommaFeed, Google Reader düzenini temel alan Quarkus üzerinde çalışan bir Java uygulamasıdır. Veritabanı çalışma zamanında değil, derleme sırasında seçilir. Bu nedenle proje her veritabanı için ayrı bir image yayımlar: gömülü H2 veritabanı için athou/commafeed:latest-h2, PostgreSQL için athou/commafeed:latest-postgresql ve MySQL ile MariaDB için ek varyantlar. Bu etiketler yerel olarak derlenmiş build'lerdir. -jvm son eki, bunun yerine JVM üzerinde çalışan varyantları belirtir. REST API ve Fever uyumlu API sunar. Ayrıca 7.3.0 sürümünden (August 2026) itibaren Google Reader uyumlu API de sunmaktadır.

yarr (yet another rss reader), SQLite gömülü tek bir Go binary'sidir ve hiç container gerektirmez. Düz ./yarr, 127.0.0.1:7070 üzerinde dinler. Flag'ler kısadır: -addr 0.0.0.0:7070 -auth alice:secret, parola arkasında ağ erişimine açar; -db /data/yarr.db ise veritabanının istenen konuma yerleştirilmesini sağlar. Fever uyumlu API sunar. En yeni etiketli sürümü, October 2026 tarihinde kontrol edildiğinde September 2026 tarihli v2.9'dur. Bundan önce June ayında v2.7 ve July ayında v2.8 yayımlanmıştır. Bu nedenle proje yeniden etkin biçimde geliştirilmektedir.

Tiny Tiny RSS, beş seçenek arasındaki en eski ve çalıştırılması en ağır olanıdır. tt-rss.org adresindeki özgün proje 1 November 2025 tarihinde kullanımdan kaldırılmıştır. Geliştirme, belgeleri artık resmi kurulum yöntemi olarak kullanılan topluluk çatallamasında github.com/tt-rss/tt-rss adresinde sürdürülmektedir. Bu kurulum dört servisten oluşur: bir PostgreSQL container'ı, bir PHP-FPM uygulama container'ı, akışları alan ayrı bir updater container'ı ve önde çalışan bir nginx container'ı. Belgelerde bu kurulumun PostgreSQL kullandığı açıkça belirtilir. Android istemcisinin ve çeşitli üçüncü taraf uygulamaların kullandığı kendi JSON API'si vardır. Fever desteği bulunmaz.

Her stack’in ihtiyaç duyduğu bellek

Aşağıdaki değerler ölçüm değil, bütçedir: Her stack’in küçük bir VPS üzerinde aşmaması gereken bellek sınırını gösterir. CommaFeed değeri, projenin yayımladığı kendi örneğidir ve container sınırını 256 MB olarak belirler. Diğer değerler, feed fetcher için pay bırakacak şekilde belirlenmiş sınırlardır. Yenileme döngüsü başladığında bellek kullanımında artışa neden olan bileşen feed fetcher’dır.

[
  {
    "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, tek bir binary ve tek bir SQLite dosyası kullandığı için 128 MB ile en düşük bellek bütçesine sahiptir. Bunun altında database server veya language runtime çalışmaz. Miniflux, 2 container genelinde 320 MB gerektirir. Bu belleğin büyük bölümü Miniflux’tan ziyade PostgreSQL tarafından kullanılır. Tiny Tiny RSS ise 4 container genelinde 640 MB ile diğerlerinden ayrılır. Bunun nedeni application, updater, database ve web server bileşenlerinin dört ayrı process ve dört ayrı heap olarak çalışmasıdır.

Bu değerleri varsayım olarak değil, gerçek limitler olarak ayarlayın. Docker Compose’ta bellek limitleri söz dizimini ve bir container limitine ulaştığında ne olduğunu açıklar. Limiti olmayan bir container, sistem belleği tükendiğinde düzgün biçimde başarısız olmaz. Kernel bir process seçerek sonlandırır. Bu process çoğu zaman bellek baskısına neden olan container’a ait değildir.

Her okuyucunun sizi zorunlu kıldığı veritabanı

Bu beş seçenek arasındaki en büyük operasyonel fark veritabanıdır. Kullanıcı arayüzündeki farklılıklardan daha önemli bir karardır. Çünkü yedekleme prosedürünüzü ve yükseltme riskinizi belirler.

Miniflux ve resmi Tiny Tiny RSS kurulumu için PostgreSQL gerekir. Gerçek full-text search ve güvenli eşzamanlı yazma desteği sağlar. Bunun karşılığında ikinci bir container ve bir volume gerekir. Ayrıca düzenli olarak karşılaşılan bir sorun vardır: resmi PostgreSQL image'ları major sürümler arasında verileri yerinde taşıyamaz. Tiny Tiny RSS dokümantasyonu bunu doğrudan belirtir ve "official PostgreSQL containers have no support for migrating data between major versions" uyarısını yapar. Bir feed reader için gerçekçi seçenekler, eski major sürümü sabitlemek veya pg_dump ve pg_restore ile dump alıp geri yüklemektir. PostgreSQL ayrıca pg_upgrade ve replication tabanlı yükseltmeleri de belgeler. Bu yöntemler, kesinti süresinin önemli olduğu büyük veritabanlarında ek kurulum maliyetini karşılar. Bir feed reader veritabanı ise genellikle bu ölçekte değildir. Bu işlemi bir veya iki yılda bir yapacak şekilde planlayın.

SQLite, FreshRSS'in ve yarr'ın varsayılanıdır. Tek dosya kullanır; sunucuya, porta veya parolaya ihtiyaç duymaz. Birkaç yüz feed'i olan tek bir kullanıcı için yeterli performans sağlar. Birden fazla kullanıcı aynı anda yazma yaptığında yavaşlar. FreshRSS'in PostgreSQL seçeneği bu noktada avantaj sağlamaya başlar. yarr, v2.7 sürümünde isteğe bağlı PostgreSQL desteği ekledi. Ancak embedded file kullanımı, yarr'ı çalıştırmanın normal yoludur.

H2, CommaFeed'in embedded varsayılanıdır. Başlamadan önce bunu dikkatle değerlendirmek gerekir. Çünkü CommaFeed veritabanını image oluşturulurken seçer. H2'den daha sonra PostgreSQL'e geçmek bir yapılandırma değişikliği değildir. Farklı bir image kullanılması ve veri taşıma işleminin sizin tarafınızdan yapılması gerekir. Bu nedenle, sistemde bir yıllık okuma geçmişi birikmeden önce karar verin.

Telefon uygulamanız çalışacak mı

Bu soru, beklenenden daha fazlasını belirler. Çünkü web arayüzü, bir feed reader'ın kullanım biçiminin yalnızca yarısıdır.

Miniflux, Fever uyumlu bir API ve Google Reader uyumlu bir API sunar. Bu nedenle çoğu iOS ve Android istemcisi buna bağlanabilir. FreshRSS de aynı iki API'yi sunar ve kendi belgelerinde bunları özelliklerine göre sıralar: Google Reader API, tüm özellikleri desteklediği için "best" olarak belirtilir. Fever API ise "limited features and less efficient" davranışa sahiptir. FreshRSS ile herhangi bir uygulamada oturum açılabilmesi için iki adım daha gerekir. Authentication bölümünde "Allow API access (required for mobile apps)" seçeneğini etkinleştirin. Ardından kullanıcı profilinde bir API password oluşturun. API password oluşturulmazsa web oturumu çalışmaya devam ederken uygulamada kimlik doğrulama hatası alınır. Sorunun nereden kaynaklandığı bilinmediğinde bu durum kafa karıştırıcı olabilir.

CommaFeed artık her iki API'yi de sunar. Uzun süredir Fever uyumlu bir API'ye sahiptir. 7.3.0 sürümü, Fever'ı desteklemeyen uygulamalar için Google Reader uyumlu bir API eklemiştir. Uygulamanız yalnızca Google Reader konuşuyorsa 7.3.0 veya daha yeni bir sürüm kullanın. yarr yalnızca Fever uyumlu bir API sunar. Bu nedenle Fever destekli istemcilerle çalışır. Yalnızca Google Reader konuşan uygulamalarla çalışmaz. Tiny Tiny RSS ise kendi API'sini kullanır. Bu nedenle onun için geliştirilmiş bir istemci gerekir. İçeri aktarma işleminden önce, tercih ettiğiniz uygulamanın kullandığınız feed reader'ı desteklediğini kontrol edin. Aksi halde 300 feed'i içeri aktardıktan sonra sorun yaşayabilirsiniz.

1 GB RAM’li bir sunucu için çalışan compose dosyası

Bu, Ekim 2026 itibarıyla projenin kendi Docker örneğinden uyarlanmış Miniflux yığınıdır. Dışarı açılan port loopback adresine bağlanmıştır, dinleme adresi açıkça belirtilmiştir ve her iki container için bellek sınırı tanımlanmıştır.

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:

Bu dosyada genellikle hatalı yapılandırılan üç satır vardır. LISTEN_ADDR=0.0.0.0:8080, resmi image’ın Dockerfile içinde zaten belirlediği ayarı tekrarlar. Bu nedenle miniflux/miniflux ile birlikte bir düzeltme değil, zararsız bir güvenlik önlemidir. Kendi image’ınızı oluşturduğunuzda veya paketlenmiş bir binary çalıştırdığınızda önem kazanır; çünkü binary için belgelenen varsayılan değer 127.0.0.1:8080 şeklindedir. Container içindeki loopback adresine bağlanan bir sürece yayınlanan port üzerinden erişilemez. Bu durumda container sağlıklı göründüğü halde bağlantı sıfırlanır. /var/lib/postgresql volume yolu PostgreSQL 18 ile uyumludur. 17 ve önceki sürümlerde veriler /var/lib/postgresql/data yolunda tutulur. Yanlış yolu mount etmek, veri dizininin hiç volume üzerinde olmaması anlamına gelir. Bu nedenle container yeniden oluşturulduğunda tüm veriler kaybolur. 127.0.0.1:8080:8080, portun genel internete açılmasını engeller. Çünkü adres belirtmeden port yayınlamak, ufw tarafından yönetilmeyen bir zincire kural ekler. Bu mekanizma Docker portları ufw’yi atlar bölümünde açıklanır. TLS’yi önüne koymak için Traefik reverse proxy kullanılır.

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

docker compose ps her iki servisi de çalışır durumda göstermelidir. Veritabanı healthy olarak işaretlenmelidir. Miniflux’ın ilk başlatılması sırasında şema migration kayıtları yazılır. RUN_MIGRATIONS=1 bu işlemi tetikler. docker stats --no-stream anlık bellek kullanımını gösterir. Karşılaştırılması gereken değer, yukarıdaki tablodaki sınırlar ile bu değerdir. Miniflux container’ı döngü halinde yeniden başlatılıyorsa günlüğünü okuyun: connect: connection refused, PostgreSQL bağlantıları kabul etmeye hazır olmadan başladığı anlamına gelir. service_healthy koşulu tam olarak bunu önler. Bu nedenle düzenlemelerinizden sonra koşulun hâlâ bulunduğunu doğrulayın. Compose sizin için yeniyse dosya düzeni önce VPS üzerinde Docker Compose temelleri bölümünde açıklanır.

1 GB sunucuya sığmayacaklar

Tiny Tiny RSS atlanması gereken seçenektir. Resmi dört servisli yığını, başka bir iş yapmayan 1 GB VPS üzerinde çalışır. Ancak aynı VPS üzerinde veritabanı kullanan başka bir uygulama ve reverse proxy ile birlikte çalışmaz. Dört servis, dört ayrı ek yük kümesi anlamına gelir. Bu servislerden biri de PostgreSQL'dir.

CommaFeed sığar, ancak yalnızca H2 image ve projenin kendi örneğinde tanımladığı 256 MB sınırı ile. Küçük bir sunucuyu zorlayan yapı, CommaFeed'in ayrı bir database server ile birlikte çalıştırılmasıdır. -jvm image varyantları durumu daha da kötüleştirir. Proje dokümantasyonu, JVM'nin varsayılan olarak yüksek miktarda bellek kullandığı ve kullanılmayan belleği operating system'e geri vermediği konusunda uyarır. latest-h2 ve latest-postgresql etiketleri, daha düşük bellek kullanımı için önerilen native build'lerdir. Bu nedenle JVM çalıştırmak için özel bir neden yoksa bunlar kullanılmalıdır.

Bir sunucunun belleği tükendiğinde kernel out of memory killer bir süreç seçerek sonlandırır. dmesg -T, Out of memory: Killed process 1234 (java) gibi bir satır gösterir. Container, application log içinde herhangi bir mesaj olmadan docker compose ps üzerinden kaybolur. Bunun nedeni, uygulamanın böyle bir mesaj yazma fırsatı bulamamasıdır.

Her birinde yükseltmelerin çalışma şekli

• Miniflux: docker compose pull && docker compose up -d; RUN_MIGRATIONS=1 ayarlı olduğunda şema geçişleri başlangıç sırasında uygulanır. Yükseltme riski Miniflux değildir. Risk, altında çalışan PostgreSQL ana sürümündedir.
• FreshRSS: Yeni image sürümünü çekin. SQLite kullanıldığında yükseltilmesi gereken bir veritabanı motoru yoktur. Bu nedenle olağan bozulma, güncel sürümlerle uyumlu hale getirilmemiş üçüncü taraf eklentilerden kaynaklanır.
• CommaFeed: Veritabanınızla eşleşen image varyantını çekin. latest-h2 sürümünden latest-postgresql sürümüne geçiş verilerinizi taşımaz.
• yarr: Binary dosyasını değiştirin ve veritabanı dosyasını koruyun. Sürümler June, July ve September 2026 tarihlerinde yayımlandı. October 2026 itibarıyla en yeni sürüm v2.9 olduğundan release sayfasını zaman zaman kontrol edin.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Uygulama container'ı başlangıçta kendini günceller. Projenin FAQ bölümü, şema güncelleme hatalarını bozuk bir volume veya override yapılandırmasıyla ilişkilendirir. Bu nedenle böyle bir hata görünürse önce bunları kontrol edin. Compose dosyanız hâlâ kullanımdan kaldırılan tt-rss.org projesindeki image'ları çekiyorsa bunları fork'un image'larıyla değiştirin (Docker Hub'da supahgreg/tt-rss veya ghcr.io/tt-rss/tt-rss).

Bu işlemlerin tümünden önce, sonrasında değil, veritabanı dökümü alın.

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

Yenileme aralığının bant genişliği maliyeti

Aşağıdaki sayılar ölçüm değil, aritmetik hesaplamadır. Bu hesapta 100 feed, her aralıkta feed başına bir istek ve yanıt başına 40 KB varsayılır. Sunucu koşullu istekleri desteklediğinde gerçek trafik daha düşük olur. Feed'ler makalenin tam metnini içerdiğinde ise daha yüksek olur.

[
  {
    "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 feed için beş dakikalık aralıkta ayda 864,000 istek gönderilir ve yaklaşık 34.6 GB veri aktarılır. Saatlik yoklama ise 72,000 istek ve yaklaşık 2.9 GB veri oluşturur. Miniflux, POLLING_FREQUENCY değerini 60 dakika olarak kullanır. Bu, grafikteki son satıra karşılık gelir ve bu varsayılan ayar neredeyse herkes için uygundur. Bir makaleyi daha sık istemek, makalenin daha erken gelmesini sağlamaz.

Koşullu istekler, gerçek değerin aritmetik hesaptan düşük kalmasını sağlar. Bir okuyucu, feed'in döndürdüğü ETag ve Last-Modified başlıklarını saklar. Sonraki isteklerde bunları If-None-Match ve If-Modified-Since olarak geri gönderir. Yeni içerik yoksa sunucu 304 Not Modified yanıtını gövde olmadan döndürür. Bağlantı kurulumu için yine bir el sıkışma gerekir. Ancak içerik yükü aktarılmaz. Koşullu istekleri yok sayan feed'ler, her istekte belgenin tamamını gönderir. Bu nedenle birkaç büyük feed, aktarım maliyetinin çoğunu tek başına oluşturabilir.

Sık aralıklarla yoklama yapmak engellenmenize de neden olabilir. Bir sunucu kendisine aşırı istek gönderdiğinizi tespit ederse 429 Too Many Requests yanıtını verir. Bazı siteler bunun yerine 403 yanıtını döndürür. Miniflux, son hatayı doğrudan feed ile ilişkilendirerek kaydeder. Bu nedenle bir feed güncellenmeyi durdurduğunda ve diğerleri çalışmaya devam ettiğinde ilk olarak feed listesine bakılmalıdır.

Akışlar bozulur; OPML dosyası yedek değildir

Akışlar beklediğinizden daha hızlı kullanılmaz hale gelir. Alan adlarının süresi dolar, siteler akış sunmayan platformlara taşınır ve daha önce XML sunan bir URL, 200 OK durum koduna sahip bir HTML hata sayfası sunmaya başlar. Son durum sorunludur: alma işlemi başarılı olur, ayrıştırma başarısız olur ve okuyucunuz ağ hatası yerine ayrıştırma hatası kaydeder. Yılda bir kez akış listesini son güncellenme tarihine göre sıralayın ve sessiz kalanları silin.

OPML dışa aktarımı abonelik listenizdir. Standart bir OPML dosyasında akış URL'leri ve klasör adları bulunur. FreshRSS, akış yenileme aralığı, XPath ile kazıma seçicileri ve otomatik okuma filtreleri gibi akış başına ayarları da içeren kendi XML ad alanını ekler; ancak hiçbir OPML dışa aktarımı okuma durumunu, yıldızlanan makaleleri veya kaydettiğiniz makale metnini içermez. Bu OPML dosyasını yeni bir kuruluma içe aktardığınızda akışlarınız geri gelir, ancak şimdiye kadar okuduğunuz tüm makaleler yeniden okunmamış olarak işaretlenir.

Önemli olan yedek veritabanıdır. PostgreSQL için yukarıdaki pg_dump komutu tüm işlemi gerçekleştirir. FreshRSS veya yarr gibi SQLite kullanan bir okuyucuda yazma işlemini durdurup dosyayı kopyalayın ya da çalışırken sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" ile tutarlı bir kopya alın. Yazma işlemi devam eden bir veritabanının düz cp kopyası, yarım kalmış bir yazma işlemini yakalayabileceği için daha sonra açılamayacak bir dosya oluşturabilir. Ardından bu dosyaları bir zamanlamayla sunucudan dışarıya aktarın. VPS üzerinde restic ile yedekleme bunun için kullanılır. İşlemin çalıştığından emin olmak için yedeklerden birini en az bir kez geçici bir container'a geri yükleyin.

Akış okuyucu, kendi sisteminizde çalıştırabileceğiniz en düşük maliyetli servislerden biridir. Bu nedenle 2026 yılında self-host etmeye değer şeyler listelerinin tamamında yer alır. Yanına self-host edilen bir SearXNG örneği kurarsanız hem okuma hem de arama işlemleri denetiminizdeki donanım üzerinde kalır.

FAQ

En az bellek kullanan self-hosted RSS okuyucusu hangisidir?

yarr. SQLite derlenmiş tek bir Go binary dosyasıdır. Bu nedenle ayrı bir veritabanı sunucusuna veya dil runtime'ına gerek duymaz. 128 MB bellek sınırı yeterlidir. Bunun karşılığında özellikler sınırlıdır: yalnızca Fever API kullanılır ve en yeni sürümü Eylül 2026 tarihli v2.9'dur. Google Reader API desteği ve benzer bellek kullanımıyla full text search isteniyorsa 320 MB ile Miniflux ve PostgreSQL daha uygun seçenektir.

Self-hosted RSS okuyucusu 1 GB VPS üzerinde çalıştırılabilir mi?

Evet. Her iki container üzerinde mem_limit ayarlandığında Miniflux ve PostgreSQL yaklaşık 320 MB bellek içinde çalışır. FreshRSS ve SQLite ise tek bir container içine sığar. 1 GB sistemlerde kaçınılması gereken seçenek, kendi PostgreSQL servisini de içeren resmi Tiny Tiny RSS stack'idir. Bu stack toplam 4 servis çalıştırır. Her zaman bellek sınırı belirlenmelidir. Tamamen dolu bir sistemde sınırsız belleğe sahip bir container için kernel bir süreci sonlandırır. Sonlandırılan süreç çoğu zaman hataya neden olan uygulama yerine veritabanı olur.

Bunlardan hangileri iOS ve Android RSS uygulamalarıyla çalışır?

Miniflux, FreshRSS ve CommaFeed 7.3.0 veya sonraki sürümleri hem Fever uyumlu API hem de Google Reader uyumlu API kullanır. Bu nedenle neredeyse tüm mobil istemciler bağlanabilir. yarr yalnızca Fever API sunar. Tiny Tiny RSS kendi API'sini kullanır. Bu nedenle Tiny Tiny RSS için geliştirilmiş bir istemci gerekir. FreshRSS üzerinde Authentication bölümünden API erişimi de etkinleştirilmelidir. Ayrıca profilde ayrı bir API parolası belirlenmelidir. Aksi halde web sitesi çalışmaya devam ederken uygulama oturum açamaz.

OPML dışa aktarma işlemi RSS okuyucumun yedeği midir?

Hayır. OPML abonelik listesini yeniden oluşturur. FreshRSS'in extended export özelliği feed başına ayarları ve filtreleri de içerir. Ancak okuma durumu, yıldızlı öğeler ve makale metinlerinin tamamı veritabanında tutulur. PostgreSQL için pg_dump kullanılarak veritabanının kendisi yedeklenmelidir. SQLite için ise bir .backup komutu kullanılmalıdır. Oluşturulan çıktı sunucu dışına kopyalanmalıdır.

Miniflux SQLite destekler mi?

Hayır. Proje belgelerinde yalnızca "works only with PostgreSQL" ifadesi yer alır. Full text search, PostgreSQL özellikleri kullanılarak uygulanır. Bu nedenle geçiş yapılabilecek daha hafif bir mod yoktur. Hiç veritabanı container'ı kullanmak istenmiyorsa FreshRSS, varsayılan SQLite backend'iyle veya yarr, embedded dosyasıyla çalıştırılmalıdır.