2026'da FreshRSS Nasıl Self-Host Edilir: Feed Yenileme, Mobile API ve Yedekler
Docker, portlar, kalıcı veriler, TLS, güvenlik, yedekler ve production kullanımını engelleyen sorunları kapsayan pratik bir FreshRSS self-hosting rehberi. Kontrollerle birlikte.
Başarısız bir FreshRSS deployment'ı her zaman çökmeyebilir. cron devre dışı bırakıldığı veya outbound DNS başarısız olduğu için feed'ler hiç yenilenmezken login sayfası sunabilir. Bunun yerine uçtan uca bir kontrolle başlayın: feed ekleyin, zamanlanmış bir yenileme çalıştırın, bir öğeyi okundu olarak işaretleyin ve bu durumu mobile API üzerinden senkronize edin.
Bu kontrol, FreshRSS'in kataloglanmış amacına uyar: mobile API uyumlu, self-hosted RSS reader. Ayrıca eksik dependency'leri, hatalı proxy varsayımlarını ve ephemeral verileri bir uptime probe'dan daha erken ortaya çıkarır.
Docker'a dokunmadan önce FreshRSS'i haritalayın
FreshRSS için dört konuyu birbirinden ayırın: ingress, 80 numaralı portu dinleyen listener, kalıcı state ve destekleyici servisler ya da yerel kapasite. FreshRSS için harici gereksinim, zamanlanmış feed yenileme ve feed host'larına outbound erişimdir. Başka bir inbound servisi yayınlamadan outbound DNS, TLS ve provider davranışını test edin.
Bu ayrımı tamamlanmış saymadan önce bilinen, sorunsuz transaction'ı çalıştırın — feed ekleyin, zamanlanmış bir yenileme çalıştırın, bir öğeyi okundu olarak işaretleyin ve bu durumu mobile API üzerinden senkronize edin. Feed sayısını, yenileme aralığını, yavaş publisher'ları, database write işlemlerini ve eş zamanlı API client'larını ölçün; sonucu deployment kaydıyla birlikte saklayın. Bu kayıt hem bir acceptance criterion hem de ilk kapasite baseline'ı sağlar.
FreshRSS'in yeniden oluşturamayacağı state'i yedekleyin
FreshRSS için bir recovery manifest hazırlayın: data, extension'lar ve seçilen database. Bootstrap işleminden önce /var/www/FreshRSS/data yolunu mount edin, zararsız örnek veriler yazın ve bu yolun gerçekten kalıcı olduğunu kanıtlamak için container'ı değiştirin. Ownership ve boş alanı şimdi kontrol edin; çünkü mount edilmiş ancak yazılamayan bir yol, hiç persistence yokmuş gibi davranır.
Yedekleri çalışan server'dan ayrı bir failure domain'a alın. FreshRSS'i pinned image üzerinden yeniden oluşturun ve subscription'ların, kategorilerin, read state'in, filter'ların ve extension'ların geri geldiğini; zamanlanmış yenilemenin yeni bir öğe getirdiğini doğrulayın. Kalıcı volume rehberi, bu çalışmayı snapshot ve retention policy'ye dönüştürmenize yardımcı olur.
FreshRSS trust boundary'sini seçin
Sadece login formunu değil, FreshRSS'in gerçekleştirdiği işlemi de threat model kapsamına alın. Buradaki yüksek riskli hata, initial setup'ı veya default user'ı public bir host üzerinden erişilebilir bırakmaktır. Bu sınırı uygulayın: setup'ı private olarak tamamlayın, API password'larını koruyun ve mobile synchronization'ı etkinleştirmeden önce trusted proxy'leri yapılandırın.
CRON_MIN gizlilikten çok davranışı kontrol eder; tipini ve değerini doğrulayın, gerçek FreshRSS credential'larını ayrı saklayın. Bir permission error'ı container'ı root olarak çalıştırarak veya host'u geniş kapsamlı mount ederek çözmeye çalışmayın. Feed sayısı, yenileme aralığı, yavaş publisher'lar, database write işlemleri ve eş zamanlı API client'ları kullanıcılar tarafından tetiklenebildiğinde resource limit'leri de security design'ın parçasıdır.
Gerçek FreshRSS verileri gelmeden önce neler geçmeli?
FreshRSS smoke test'ini tekrarlanabilir bir release command'a veya kısa bir runbook'a dönüştürün. Çıktısı şu sonucu göstermelidir: feed ekleyin, zamanlanmış bir yenileme çalıştırın, bir öğeyi okundu olarak işaretleyin ve bu durumu mobile API üzerinden senkronize edin. Application version'ı, container digest'ini, route hostname'ini ve test data identifier'ını sonuçla birlikte kaydedin.
Aynı kontrolü rutin bir container değişiminden ve data, extension'lar ile seçilen database'i başka bir yerde restore ettikten sonra çalıştırın. Restore işlemi; subscription'lar, kategoriler, read state, filter'lar ve extension'lar geri geldiğinde ve zamanlanmış yenileme yeni bir öğe getirdiğinde başarılıdır. Feed sayısı, yenileme aralığı, yavaş publisher'lar, database write işlemleri ve eş zamanlı API client'larıyla ilişkili timing ve consumption değerlerini karşılaştırın; son işlem hâlâ başarılı olsa bile büyük bir değişiklik incelenmeye değerdir.
Ardından güvenli bir failure senaryosunu deneyin: zamanlanmış feed yenilemesi ve feed host'larına outbound erişim için kullanılan test path'ini geçici olarak engelleyin. FreshRSS'in hatayı görünür kıldığını ve yıkıcı manuel düzenlemeler yapılmadan normale döndüğünü doğrulayın. Yalnızca gerekli, redakte edilmiş log excerpt'ini saklayın. Bu dört parçalı gate; startup, persistence, recovery ve failure handling süreçlerini kapsar.
FreshRSS için bir Docker baseline'ı
Production'a uygun bir launch bilerek sıradandır: named state, açıkça belirtilmiş port ve image içinde secret bulunmaması.
docker run -d \
--name freshrss \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v freshrss-data:/var/www/FreshRSS/data \
-e CRON_MIN=15 \
freshrss/freshrss:latest
Bu örnek, eksiksiz bir supporting stack yerine bir baseline'dır. Zamanlanmış feed yenilemesi ve feed host'larına outbound erişim için gereken outbound veya client-side path'e izin verin ve bu yolu doğrulayın. Effective mount'ları ve listener'ı kontrol edin; ardından feed eklemeyi, zamanlanmış bir yenileme çalıştırmayı, bir öğeyi okundu olarak işaretlemeyi ve bu durumu mobile API üzerinden senkronize etmeyi deneyin. Bir sonraki restart'tan önce çalışan image'ı pinleyin.
Proxy başarısının application failure'ı gizlemesini önleyin
Browser, API client ve FreshRSS aynı origin üzerinde anlaşmalıdır. Bunu sağlamak için trusted proxy'leri ve canonical HTTPS base'i tanımlayın. Original host ve protocol bilgilerini korurken port 80'i rakip bir public address olarak erişime kapalı tutun.
Site erişilemiyor troubleshooting rehberi, erişilemeyen bir route ile yanıt veren bir application arasındaki farkı belirlemenize yardımcı olur. Bu ayrım burada önemlidir: cron devre dışı olduğu veya outbound DNS başarısız olduğu için feed'ler hiç yenilenmez. Yalnızca ilk durum ingress değişiklikleriyle düzeltilir; ikinci durum için FreshRSS log'larını, state'i veya workload'u incelemek gerekir.
Yalnızca container'ı değil, workload'u izleyin
FreshRSS'in gerçekleştirdiği işi gözlemleyin: feed sayısı, yenileme aralığı, yavaş publisher'lar, database write işlemleri ve eş zamanlı API client'ları. Bu iş için headroom bırakarak limit'ler belirleyin ve workload'la rekabet eden bir liveness probe kullanmaktan kaçının. Operator check yine de belirli aralıklarla feed eklemeyi, zamanlanmış bir yenileme çalıştırmayı, bir öğeyi okundu olarak işaretlemeyi ve bu durumu mobile API üzerinden senkronize etmeyi denemelidir.
Update'ler için login hâlâ çalışıyor olsa bile extension'ların, database migration'larının ve feed parser değişikliklerinin yenilemeleri etkileyebileceğini unutmayın. Candidate'ı restore edilmiş bir kopya üzerinde deploy edin ve bilinen testi tekrarlayın. cron devre dışı olduğu veya outbound DNS başarısız olduğu için feed'ler hiç yenilenmiyorsa hangi varsayımın değiştiğini bulmak için runtime log'larını ve gerçek network request'i kullanın.
Tekrarlanabilir infrastructure işlerini Dockup'a taşıyın
Dockup'ın one-click FreshRSS deployment'ı replacement işlemini güvenli hâle getirmelidir: route 80 numaralı portu hedeflemeye devam eder, secret'lar image içine gömülmez ve persistent path'ler yeni container'da geri gelir. Aynı deployment Dockup compute üzerinde veya bağlı bir makinede çalışabilir.
Uygulamaya özel işleri, zamanlanmış feed yenilemesine ve feed host'larına outbound erişime izin verip doğrulayarak, canonical public address'i uygulayarak ve şu acceptance check'i çalıştırarak tamamlayın: feed ekleyin, zamanlanmış bir yenileme çalıştırın, bir öğeyi okundu olarak işaretleyin ve bu durumu mobile API üzerinden senkronize edin. Gerçek kullanıcılar gelmeden önce restore sonucunu runbook'a ekleyin.
Sık sorulan sorular
Production deployment için FreshRSS'in neye ihtiyacı vardır?
FreshRSS container'ını tek bir HTTPS origin üzerinden 80 numaralı porta route edin. Harici delivery gereksinimi, zamanlanmış feed yenilemesi ve feed host'larına outbound erişimdir. Feed ekleyemeden, zamanlanmış bir yenileme çalıştıramadan, bir öğeyi okundu olarak işaretleyemeden ve bu durumu mobile API üzerinden senkronize edemeden FreshRSS'i hazır kabul etmeyin.
FreshRSS'teki hangi veriler yedeklenmelidir?
/var/www/FreshRSS/data yolunu persist edin ve data, extension'lar ile seçilen database'i aynı recovery manifest'e dahil edin. Temiz bir FreshRSS restore işlemi yalnızca subscription'lar, kategoriler, read state, filter'lar ve extension'lar geri geldiğinde ve zamanlanmış yenileme yeni bir öğe getirdiğinde başarılıdır.
Reverse proxy arkasında FreshRSS HTTPS gerektirir mi?
Public FreshRSS origin'i için HTTPS kullanın ve internal route üzerinde port 80'i tutun. FreshRSS ayarını doğru uygulayın: trusted proxy'leri ve canonical HTTPS base'i tanımlayın. FreshRSS için HTTPS, credential'ları veya user content'i transit sırasında korur ve origin'e duyarlı client davranışının tutarlı kalmasını sağlar.
FreshRSS upgrade'i nasıl test edilmelidir?
Mevcut FreshRSS state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. Login hâlâ çalışıyor olsa bile extension'ların, database migration'larının ve feed parser değişikliklerinin yenilemeleri etkileyebileceğine özellikle dikkat edin. Data migration ve rollback sınırları anlaşılana kadar önceki FreshRSS image'ını saklayın.