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 paragraf

Miniflux, Go ile yazılmıştır ve tek bir statik olarak derlenmiş binary olarak yayımlanır. Dokümantasyonunda 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 sunar; ayrıca OPML içe ve dışa aktarma desteği sağlar. 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ı aynı container içinde çalıştırır. Varsayılan veritabanı SQLite'tır ve ikinci bir servis gerektirmez. Daha büyük kurulumlar için PostgreSQL ve MySQL desteklenir. Google Reader API ve Fever API ile çalışır. Kurulum işlemi VPS üzerinde FreshRSS kurulum rehberimizde zaten ele alındığından, bu sayfada kurulum tekrarlanmaz; bunun yerine 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, build 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. REST API ve Fever uyumlu API sunar.

yarr (yet another rss reader), SQLite gömülü tek bir Go binary'sidir ve 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, password arkasında ağa açar; -db /data/yarr.db ise veritabanının istenen konuma yazılmasını sağlar. Fever uyumlu API sunar. En yeni etiketlenmiş sürümü, Ağustos 2026'da kontrol edildiğinde Temmuz 2024 tarihli v2.8'dir. Bu nedenle aktif olarak geliştirilen bir yazılım yerine tamamlanmış bir yazılım olarak değerlendirilmelidir.

Tiny Tiny RSS, beş proje arasındaki en eski ve çalıştırılması en ağır olanıdır. Resmi Docker kurulumu dört servisten oluşur: bir PostgreSQL container'ı, bir PHP-FPM uygulama container'ı, feed'leri alan ayrı bir updater container'ı ve önde çalışan bir nginx container'ı. Dokümantasyonda 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 tuttuğu 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. Bunun nedeni, yedekleme prosedürünü ve yükseltme riskini belirlemesidir.

Miniflux ve resmi Tiny Tiny RSS kurulumu için PostgreSQL gerekir. Gerçek tam metin araması ve güvenli eşzamanlı yazma işlemleri 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ındaki verileri yerinde taşıyamaz. Tiny Tiny RSS belgelerinde bu durum açıkça belirtilir ve "resmi PostgreSQL container'ları major sürümler arasında veri taşımayı desteklemez" uyarısı yapılır. Gerçekçi seçenekler eski major sürümü sabitlemek veya pg_dump ve pg_restore ile dump alıp geri yüklemektir. Bu işlemi bir veya iki yılda bir yapacak şekilde planlama yapılmalıdır.

SQLite, FreshRSS ve yarr için varsayılan veritabanıdır. Tek bir dosya kullanır. Sunucu, port veya parola gerekmez. Birkaç yüz feed içeren tek kullanıcılı kurulumlarda iyi çalışır. Birden fazla kullanıcı aynı anda yazma işlemi yaptığında yavaşlar. FreshRSS için PostgreSQL seçeneği bu noktada anlamlı hale gelir. yarr, v2.7 sürümünde isteğe bağlı PostgreSQL desteği eklemiştir. Ancak yerleşik dosya, yarr'ı çalıştırmanın normal yoludur.

H2, CommaFeed'in yerleşik varsayılan veritabanıdır. Kuruluma başlamadan önce bunun üzerinde düşünülmelidir. CommaFeed veritabanını image oluşturulurken seçer. Daha sonra H2'den PostgreSQL'e geçiş yalnızca bir yapılandırma değişikliği değildir. Farklı bir image kullanılması ve veri taşıma işleminin elle yapılması gerekir. Bu nedenle, sistemde bir yıllık okuma geçmişi birikmeden önce karar verilmelidir.

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 Miniflux'a bağlanabilir. FreshRSS de aynı iki API'yi sunar ve kendi belgelerinde bunları şöyle sınıflandırır: Google Reader API, tüm özellikleri desteklediği için "en iyi" seçenektir. Fever API ise "sınırlı özelliklere" sahiptir ve "daha verimsiz" çalışır. FreshRSS'ta herhangi bir uygulamanın oturum açabilmesi için önce iki adımın tamamlanması 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 parolası oluşturun. API parolası oluşturulmazsa uygulamada kimlik doğrulama hatası alınır. Web oturumu açma işlemi çalışmaya devam eder. Bu durum, nereye bakılması gerektiği bilinmediğinde kafa karıştırıcı olabilir.

CommaFeed ve yarr yalnızca Fever uyumlu bir API sunar. Bu nedenle Fever destekleyen istemcilerle çalışırlar. Yalnızca Google Reader kullanan uygulamalarla çalışmazlar. Tiny Tiny RSS bunun yerine kendi API'sine sahiptir. Bu nedenle Tiny Tiny RSS için geliştirilmiş bir istemci gerekir. Tercih edilen uygulamanın ilgili reader'ı desteklediği doğrulanmalıdır. Ardından 300 feed içe aktarılmalıdır.

1 GB kapasiteli sunucu için çalışan bir compose dosyası

Bu, Ağustos 2026 itibarıyla projenin kendi Docker örneğinden uyarlanmış Miniflux stack'idir. Dışarı açılan port loopback adresine bağlanmıştır, dinleme adresi açıkça ayarlanmıştır 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 en sık hatalı ayarlanan üç satır vardır. LISTEN_ADDR=0.0.0.0:8080 ayarlanır; çünkü binary için belgelenmiş varsayılan değer 127.0.0.1:8080 değeridir. Container içinde loopback adresine bağlanan bir sürece yayınlanan port üzerinden erişilemez. Bu durumda sağlıklı görünen bir container ile bağlantı sıfırlanır. /var/lib/postgresql volume yolu PostgreSQL 18 ile eşleşir. 17 ve önceki sürümlerde veriler /var/lib/postgresql/data konumunda tutulur. Yanlış yolun mount edilmesi, veri dizininin volume üzerinde olmamasına neden olur. Bu nedenle container yeniden oluşturulduğunda tüm veriler kaybolur. 127.0.0.1:8080:8080 portu public internetten erişilemez durumda tutar. Bunun nedeni, adres belirtilmeden port yayınlandığında ufw tarafından yönetilmeyen bir chain içine kural yazılmasıdır. Docker portlarının ufw'yi atlaması bu mekanizmayı açıklar. Traefik reverse proxy ise önüne TLS eklemek için 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 schema migration kayıtları yazılır. RUN_MIGRATIONS=1 bu işlemi başlatır. docker stats --no-stream canlı bellek sütununu gösterir. Karşılaştırılması gereken değer, bu sütundaki sayıdır. Bu sayı, yukarıdaki tabloda belirtilen üst sınırlarla karşılaştırılmalıdır. Miniflux container'ı sürekli yeniden başlatılıyorsa loglarını okuyun. connect: connection refused, PostgreSQL bağlantıları kabul etmeye hazır olmadan önce başlatıldığını gösterir. service_healthy koşulu tam olarak bunu önler. Bu nedenle düzenlemelerden sonra koşulun korunup korunmadığını kontrol edin. Compose sizin için yeniyse VPS üzerinde Docker Compose temelleri önce dosya düzenini açıklar.

1 GB sunucuya sığmayacak uygulama

Tiny Tiny RSS atlanması gereken uygulamadır. Resmi dört servisli yapısı, VPS başka bir iş yapmıyorsa 1 GB VPS üzerinde çalışır. Ancak ayrı bir veritabanı kullanan başka bir uygulama ve reverse proxy ile birlikte çalışmaz. Dört servis, dört ayrı ek yük anlamına gelir. Bu servislerden biri PostgreSQL'dir.

CommaFeed sığar. Ancak bunun için H2 image kullanılmalı ve projenin kendi örneğinde belirlediği 256 MB sınırı uygulanmalıdır. Küçük bir sunucuda sorun çıkaran yapı, ayrı bir veritabanı sunucusunun yanında çalışan JVM'dir. Çünkü JVM, kendisine bırakılan tüm bellek payını kullanabilir. CommaFeed belgelerinde -Xmx256m bir üst sınır olarak gösterilir. OpenJ9 ise "HotSpot JVM'e göre daha verimli bir alternatif" olarak tanımlanır. Bu, belleğin nerede kullanıldığını gösterir.

Sunucunun belleği tükendiğinde kernel out of memory killer bir işlem seçer ve işlemi sonlandırır. dmesg -T içinde Out of memory: Killed process 1234 (java) benzeri bir satır görülür. Uygulama günlüğünde herhangi bir mesaj görünmeden container docker compose ps içinden kaybolur. Bunun nedeni, uygulamanın hata mesajı yazamadan sonlandırılmış olmasıdır.

Her birinde yükseltmelerin işleyişi

• Miniflux: docker compose pull && docker compose up -d. Şema geçişleri, RUN_MIGRATIONS=1 ayarı etkin durumdayken başlangıçta uygulanır. Yükseltme riski Miniflux değildir. Asıl risk, altında çalışan PostgreSQL major sürümündedir.
• FreshRSS: Yeni image'ı çekin. SQLite kullanıldığında yükseltilecek bir veritabanı motoru yoktur. Bu nedenle olağan uyumsuzluklar, güncel tutulmamış üçüncü taraf eklentilerinden 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. Temmuz 2024'teki v2.8 sürümünden bu yana yeni bir release yayımlanmadığından ve kontrol Ağustos 2026'da yapıldığından genellikle yükseltilecek bir şey yoktur.
• Tiny Tiny RSS: docker compose pull && docker compose up -d. Şema geçişleri otomatik olarak çalışır. Onay gerektiren bir geçiş olduğunda arayüz sizi bir migration ekranına yönlendirir.

Bu işlemlerin herhangi birinden önce, sonra 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.

Feed'ler bozulur, OPML dosyası yedek değildir

Feed'ler beklenenden daha hızlı kullanılmaz hale gelir. Alan adlarının süresi dolar, siteler feed 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. Feed listesini yılda bir kez son güncellenme tarihine göre sıralayın ve sessiz kalanları silin.

OPML dışa aktarımı abonelik listenizdir. Feed URL'lerini ve klasör adlarını içerir. Okuma durumunu, yıldızlanan makaleleri, feed başına ayarları, filtre kurallarını veya kaydettiğiniz makale metinlerini içermez. Bu OPML dosyasını yeni bir kuruluma içe aktardığınızda feed'leriniz 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 karşılar. 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. Yazılan bir veritabanının düz cp kopyası, daha sonra açılamayacak bir dosya oluşturabilir; çünkü kopya işlemi tamamlanmamış bir yazma işlemini yakalayabilir. Ardından bu dosyaları belirli bir plana göre sunucunun dışına aktarın. VPS üzerinde restic yedekleri bunun için kullanılır. Prosedürün çalıştığından emin olmak için dosyalardan birini en az bir kez geçici bir container'a geri yükleyin.

Feed okuyucu, kendi başınıza çalıştırabileceğiniz en düşük maliyetli servislerden biridir. Bu nedenle 2026 yılında self-host etmeye değer şeyler listelerinde yer alır. Yanına self-host edilen bir SearXNG instance'ı kurarsanız hem okuma hem de arama işlemleri kontrol ettiğiniz donanım üzerinde kalır.

FAQ

En az bellek kullanan self-hosted RSS okuyucu hangisidir?

yarr. İçinde SQLite derlenmiş tek bir Go ikilisidir. Bu nedenle ayrı bir veritabanı sunucusuna veya dil çalışma zamanına ihtiyaç duymaz. 128 MB bellek sınırı yeterlidir. Bunun karşılığında bakım ve özellikler sınırlıdır. En yeni sürümü Temmuz 2024 tarihli v2.8 sürümüdür ve yalnızca Fever API ile çalışır. Benzer kaynak kullanımıyla aktif olarak geliştirilen bir proje isteniyorsa 320 MB ile Miniflux ve PostgreSQL daha iyi bir seçenektir.

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

Evet. Her iki container için mem_limit ayarlandığında Miniflux ve PostgreSQL yaklaşık 320 MB içinde çalışır. FreshRSS ve SQLite ise tek bir container içine sığar. 1 GB sistemlerde kaçınılması gereken seçenek resmi Tiny Tiny RSS yığınıdır. Bu yığın, kendi PostgreSQL servisi dahil 4 servis çalıştırır. Bellek sınırları her zaman ayarlanmalıdır. Bellek sınırı olmayan bir container, sistem tamamen dolduğunda kernel tarafından sonlandırılan bir sürece neden olabilir. Sonlandırılan süreç çoğu zaman hatanın kaynağı olan uygulama yerine veritabanıdır.

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

Miniflux ve FreshRSS hem Fever uyumlu API hem de Google Reader uyumlu API sunar. Bu nedenle neredeyse tüm mobil istemciler bağlanabilir. CommaFeed ve yarr yalnızca Fever API sunar. Tiny Tiny RSS kendi API'sini kullanır. Bu nedenle onun 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ı ayarlanmalıdır. Aksi halde web sitesi çalışmaya devam ederken uygulama oturum açamaz.

OPML dışa aktarma işlemi RSS okuyucumun yedeği sayılır mı?

Hayır. OPML yalnızca akış URL'lerini ve klasörleri içerir. Bu nedenle abonelik listenizi yeniden oluşturur, ancak başka hiçbir veriyi içermez. Okuma durumu, yıldızlanan öğeler, filtre kuralları ve makale metinlerinin tümü veritabanında tutulur. PostgreSQL için pg_dump kullanılarak veritabanının kendisi yedeklenmelidir. SQLite için ise bir .backup komutu kullanılmalı ve elde edilen çı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. Tam metin araması PostgreSQL özellikleri kullanılarak uygulanır. Bu nedenle geçiş yapılabilecek daha hafif bir çalışma modu yoktur. Hiç veritabanı container'ı kullanmak istenmiyorsa FreshRSS varsayılan SQLite arka ucuyla veya yarr gömülü dosyasıyla çalıştırılabilir.