2026'da ntfy Nasıl Self-Host Edilir: Topic'ler, Erişim Kontrolü ve Teslimat
Docker, portlar, kalıcı veriler, TLS, güvenlik, yedeklemeler ve production kullanımını engelleyen sorunları kapsayan pratik ntfy self-hosting rehberi. Adım adım.
ntfy kurulum notlarının çoğu ilk sayfa yüklemesinde sona erer. Bu çok erkendir: cache ephemeral olabilir veya WebSocket/SSE bağlantıları proxy üzerinde zaman aşımına uğrayabilir. Kullanışlı bir production testi daha kapsamlı olmalıdır — curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin.
ntfy'nin rolü oldukça basittir: basit bir HTTP request'iyle push notification göndermek. Operasyonel kapsamı web process'inden daha fazlasını içerir; bu nedenle gerçek veriler gelmeden önce dependency'yi, saklanan state'i ve public route'u açıkça tanımlamak gerekir.
ntfy'nin production yapısı
ntfy HTTP process'i 80 portunu dinler; bu portu application network üzerinde tutun ve yalnızca platform route'unu yayınlayın. Local runtime gereksinimi bir config volume'ü ve isteğe bağlı bir auth database'dir. Bu sınırı yayınlama işleminden önce ve container değişiminden sonra tekrar test edin.
Sınırı kısa bir contract olarak yazılı hâle getirin: gereksinimin sahibi kim, hangi credential kullanılıyor, kabul edilebilir timeout nedir ve hata nasıl görünür? Ardından şu transaction'ı çalıştırın: curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin. Çalışma sırasında uzun süreli subscriber bağlantılarını, attachment boyutunu, cache retention'ını ve outbound push relay'lerini gözlemleyin; çünkü bu workload, boşta duran bir container'dan daha faydalı bir başlangıç boyutu sağlar.
ntfy'yi hareketli parçaları gizlemeden başlatın
Container'ı gerçeğin kaynağı olarak değil, değiştirilebilir bir runtime olarak kullanın.
docker run -d \
--name ntfy \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v ntfy-data:/var/cache/ntfy \
-e NTFY_BASE_URL=https://app.example.com \
binwiederhier/ntfy:latest serve
Dış erişime açmadan önce local gereksinimi doğrulayın: bir config volume'ü ve isteğe bağlı bir auth database. Container user'ını, yazılabilir path'leri ve bind edilmiş listener'ı dış erişime açmadan önce inceleyin. Eksiksiz action'ı çalıştırın — curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin — ve sonucu üreten tam image reference'ını kaydedin.
ntfy'ye tek bir canonical address verin
base-url değerini publisher'lar ve subscriber'lar tarafından kullanılan public HTTPS origin olarak ayarlayın. Seçtiğiniz hostname'i container'ın 80 portuna yönlendirin, original host ile HTTPS scheme'i forward edin ve ikinci bir direct origin yayınlamaktan kaçının.
ntfy'yi temiz bir external client'tan test edin. Ingress hatasını bilinen application boundary'den ayırın — cache ephemeral olabilir veya WebSocket/SSE bağlantıları proxy üzerinde zaman aşımına uğrayabilir. Certificate, DNS veya 502 hatası routing'e aittir; ntfy'ye ulaşan ve daha sonra başarısız olan bir request ise application state'ine, capacity'ye veya supporting requirement'a aittir. Özel domain TLS rehberi ilk grubu ele alır.
ntfy'nin değişimden sonra çalıştığını kanıtlayın
Container'ını optimize etmeden önce ntfy'nin state'ini koruyun. Gerekli küme; configuration, auth database ve korunması gereken attachment'lardır. Bootstrap işleminden önce /var/cache/ntfy'yi mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten persistent olduğunu kanıtlamak için container'ı değiştirin. Birden fazla store'un uyumlu olması gerekiyorsa write işlemlerinin durdurulacağı ve backup'ların alınacağı sırayı belgeleyin.
Kopyaları deployment server'ın dışında tutun ve credential veya private content içeren materyalleri encrypt edin. Recovery; user'lar, ACL'ler, configuration ve korunan attachment'lar geri geldiğinde ve kimlik doğrulaması yapılmış bir subscriber yeni bir mesaj aldığında başarılıdır. Persistent mount ile bağımsız bir kopya arasındaki fark persistent storage ve snapshot'lar bölümünde açıklanır.
ntfy'ye tüm host'u vermeyin
ntfy için değerli surface her zaman landing page değildir. En büyük hata, mesajlar operational detail içerdiğinde public topic guessing'e izin vermektir. Buna bilinçli şekilde karşı koyun: topic ACL'lerini kullanın; çünkü tahmin edilmesi zor topic name'leri operational message'lar için güçlü bir authorization yöntemi değildir.
NTFY_BASE_URL bir secret değil, configuration'dır; ntfy tarafından kullanılan ayrı credential'ları korurken değerini açıkça belirtin. Image destekliyorsa unprivileged bir container user kullanın ve ilgisiz credential'ları mount etmeyin. Güvenilmeyen işlemlerin uzun süreli subscriber bağlantılarını, attachment boyutunu, cache retention'ını ve outbound push relay'lerini tüketebileceği ingress noktasında rate veya size limit'leri uygulayın.
ntfy'yi tahmin yürütmeden upgrade edin
Her deployment sonrasında ntfy smoke test'i olarak curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin. Bunun destekleyici metric'leri uzun süreli subscriber bağlantıları, attachment boyutu, cache retention'ı ve outbound push relay'leridir; bu kaynakların user action'ı bozacak bir noktaya yaklaştığı durumlarda alert üretin.
Temel change riski şudur: ntfy'yi güncellemeden önce configuration key'leri, auth database migration'ları ve client beklentileri kontrol edilmelidir. Güvenli bir release, geri yüklenebilir bir snapshot ile başlar ve traffic taşınmadan önce tek yönlü state değişikliklerini doğrular. Cache ephemeral olduğunda veya WebSocket/SSE bağlantıları proxy üzerinde zaman aşımına uğradığında, configuration'ı ve ilk hatayı okuyabilmek için başarısız container'ı yeterince uzun süre koruyun.
ntfy release gate'i
ntfy için bir release candidate, sabit bir senaryoyu tamamlayarak traffic almaya hak kazanır: curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin. Bu senaryo için image digest'ini, effective non-secret configuration'ı, public origin'i ve timestamp'leri kaydedin. Test verileri disposable olmalı, ancak user'ların kullandığı path'in aynısını çalıştıracak kadar gerçekçi olmalıdır.
Runtime'ı değiştirdikten sonra testi çalıştırın; ardından service'i configuration, auth database ve korunması gereken attachment'lardan yeniden build edin. Recovery; user'lar, ACL'ler, configuration ve korunan attachment'lar geri geldiğinde ve kimlik doğrulaması yapılmış bir subscriber yeni bir mesaj aldığında başarılıdır. Uzun süreli subscriber bağlantıları, attachment boyutu, cache retention'ı ve outbound push relay'ler için resource ölçümlerini önceki release ile karşılaştırın ve promotion'dan önce anlamlı sapmaları araştırın.
Son olarak şu kontrollü hatayı çalıştırın: bu boundary ile ilişkili resource veya format limitine yakın, zararsız bir input gönderin: cache ephemeral olabilir veya WebSocket/SSE bağlantıları proxy üzerinde zaman aşımına uğrayabilir. ntfy'nin hatayı açıkladığını, mevcut state'e zarar vermediğini ve geçerli koşul geri döndüğünde çalışmaya devam ettiğini doğrulayın. Redact edilmiş bir log excerpt'i ve recovery süresini kaydedin. Bu kontroller birlikte yalnızca process uptime'ını değil, behavior, durability ve operability'yi de kapsar.
Dockup routing'i yönetirken ntfy'yi açıkça yapılandırın
Routing, certificate'lar, service replacement ve bağlı storage makul automation hedefleridir. Dockup bunları ntfy için yönetir ve ilgili managed database'i provision edebilir veya müşterinin kendi server'ındaki service'lere bağlanabilir.
Ancak ntfy trust policy'sini kendiliğinden oluşturmamalıdır. Deployment sonrasında base-url değerini publisher'lar ve subscriber'lar tarafından kullanılan public HTTPS origin olarak ayarlayın, şu sınırı uygulayın — tahmin edilmesi zor topic name'leri operational message'lar için güçlü bir authorization yöntemi değildir; bu nedenle topic ACL'lerini kullanın — ve şu senaryonun sonucunu doğrulayın: curl ile bir mesaj yayınlayın, HTTP ve WebSocket subscription'ları üzerinden alın, bir dosya ekleyin ve kimlik doğrulaması yapılmış bir topic'i test edin. Sonuç, application-specific acceptance test'i olan one-click infrastructure'dır.
Sık sorulan sorular
Production deployment için ntfy'nin neye ihtiyacı vardır?
ntfy container'ını 80 portunda tek bir HTTPS origin üzerinden route edin. Local runtime gereksinimi bir config volume'ü ve isteğe bağlı bir auth database'dir. curl ile bir mesaj yayınlayıp HTTP ve WebSocket subscription'ları üzerinden alamadığınız, bir dosya ekleyemediğiniz ve kimlik doğrulaması yapılmış bir topic'i test edemediğiniz sürece ntfy'yi hazır kabul etmeyin.
Hangi ntfy verileri backup'a dahil edilmelidir?
/var/cache/ntfy'yi persistent hâle getirin ve aynı recovery manifest'ine configuration, auth database ve korunması gereken attachment'ları dahil edin. Temiz bir ntfy restore işlemi yalnızca user'lar, ACL'ler, configuration ve korunan attachment'lar geri geldiğinde ve kimlik doğrulaması yapılmış bir subscriber yeni bir mesaj aldığında başarılıdır.
ntfy'nin reverse proxy arkasında HTTPS kullanması gerekir mi?
Public ntfy origin'i için HTTPS kullanın ve 80 portunu internal route üzerinde tutun. ntfy ayarını doğru uygulayın: base-url değerini publisher'lar ve subscriber'lar tarafından kullanılan public HTTPS origin olarak ayarlayın. ntfy 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.
Bir ntfy upgrade'i nasıl test edilmelidir?
Mevcut ntfy state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. ntfy'yi güncellemeden önce configuration key'lerinin, auth database migration'larının ve client beklentilerinin kontrol edilmesi gerektiğinden özellikle bu noktalara dikkat edin. Data migration ve rollback sınırları anlaşılana kadar önceki ntfy image'ını koruyun.