2026'da Uptime Kuma Nasıl Self-Host Edilir: Uyarılar, TLS ve Kalıcı Veriler

Uptime Kuma kurulum notlarının çoğu ilk sayfa yüklemesinde sona erer. Bu çok erkendir: veri volume'ü salt okunur olabilir veya container DNS'i izlenen host adlarını çözemeyebilir. Kullanışlı bir production testi daha kapsamlıdır — HTTP ve TCP monitor'leri oluşturun, kontrollü bir hata tetikleyin ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alın.

Uptime Kuma'nın rolü basittir: mevcut servisleri izlemek ve 90'dan fazla hedefe uyarı göndermek. Operasyonel sınırları web process'inden daha geniştir; bu nedenle gerçek veriler gelmeden önce dependency'yi, saklanan state'i ve public route'u açıkça tanımlamanız gerekir.

Önce Uptime Kuma için başarı kriterlerini tanımlayın

Kullanışlı bir Uptime Kuma diyagramı public route'u, private port 3001'i, state sınırını ve tüm supporting requirement'ları gösterir. Hangi okların credential taşıdığını, hangilerinin sıradan user traffic olduğunu belirtin. Uptime Kuma için dış gereksinim, izlenen her endpoint'e ve alert provider'a outbound erişimdir. Başka bir inbound servis yayınlamadan outbound DNS, TLS ve provider davranışını test edin.

Diyagramı gerçek bir işlemle doğrulayın: HTTP ve TCP monitor'leri oluşturun, kontrollü bir hata tetikleyin ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alın. Asıl baskı monitor interval'ından, retry count'tan, status-page traffic'ten ve aynı saniyede yapılan outbound probe sayısından gelebilir; tüm HTTP request'lerini eşit kabul etmek yerine bu yolu izleyin.

Uptime Kuma'yı gerçek darboğazı etrafında işletin

Uptime Kuma için ilk kullanışlı operasyonel metrik, HTTP ve TCP monitor'leri oluşturabilmesi, kontrollü bir hata tetikleyebilmesi ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alabilmesidir. Bunu monitor interval'ı, retry count, status-page traffic ve aynı saniyede yapılan outbound probe sayısına ilişkin saturation sinyalleriyle birlikte değerlendirin. Yalnızca process'i kontrol eden bir probe, pahalı dependency'leri çağırmamalı veya upstream kısa süreliğine kullanılamadığında container'ı yeniden başlatmamalıdır.

SQLite migration'ları ve notification-provider değişiklikleri, hızlı bir image pull işlemini stateful application upgrade'ine dönüştürebileceğinden upgrade'leri veri değişikliği olarak ele alın. Version'ları sabitleyin, geri yüklenmiş state üzerinde prova yapın ve rollback geçerli kalana kadar önceki image'ı erişilebilir tutun. Veri volume'ü salt okunursa veya container DNS'i izlenen host adlarını çözemezse restart öncesindeki log'ları koruyun; nedensel mesaj genellikle burada bulunur.

Bilinen iyi durumdaki bir Uptime Kuma deployment'ını kaydedin

Uptime Kuma için launch öncesinde bilinen iyi durumdaki bir transaction tanımlayın: HTTP ve TCP monitor'leri oluşturun, kontrollü bir hata tetikleyin ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alın. Prerequisite'larını, beklenen response'u ve cleanup adımlarını secret değerleri olmadan version control'e ekleyin. Bu referansı oluşturmak için kullanılan image'ı sabitleyin.

Bir replacement'ı ve bağımsız bir restore işlemini doğrulamak için bu transaction'ı kullanın. Geri yüklenen servis yalnızca monitor history, notification credential'ları ve maintenance window'ları geri geldiğinde ve bir test alert'i hâlâ iletildiğinde kabul edilebilir. Aynı zamanda monitor interval'ını, retry count'u, status-page traffic'i ve aynı saniyede yapılan outbound probe sayısını izleyin; en yavaş veya en kısıtlı bölümü service-level alert'e dönüştürün.

Gate ayrıca negatif bir durum da içermelidir: outbound erişimin izlenen her endpoint'e ve alert provider'a ulaşmak için kullandığı test path'ini geçici olarak engelleyin. Uptime Kuma'nın verileri korurken işlem yapılabilir bir hata ürettiğini doğrulayın, geçerli koşulu geri yükleyin ve bilinen iyi durumdaki transaction'ı tekrarlayın. Her iki sonucu saklamak, yüzeysel bir health endpoint'inin tek production kanıtı hâline gelmesini önler.

İncelenmeye değer container ayarları

Container'ı gerçeğin tutulduğu yer olarak değil, değiştirilebilir bir runtime olarak kullanın.

docker run -d \
  --name uptime-kuma \
  --restart unless-stopped \
  -p 127.0.0.1:3001:3001 \
  -v uptime-kuma-data:/app/data \
  -e UPTIME_KUMA_PORT=3001 \
  louislam/uptime-kuma:1

İzlenen her endpoint'e ve alert provider'a outbound erişim için gereken outbound veya client-side path'i açın ve doğrulayın. Dışarıya açmadan önce container user'ını, yazılabilir path'leri ve bind edilmiş listener'ı inceleyin. Eksiksiz işlemi gerçekleştirin — HTTP ve TCP monitor'leri oluşturun, kontrollü bir hata tetikleyin ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alın — ardından sonucu üreten tam image reference'ını kaydedin.

Uptime Kuma'yı boş bir host üzerinde geri yükleyin

Container'ını optimize etmeden önce Uptime Kuma'nın state'ini koruyun. Gerekli set, SQLite database'i ve /app/data içindeki yüklenmiş asset'lerdir. Bootstrap işleminden önce /app/data'yı mount edin, zararsız örnek veriler yazın ve bu path'in gerçekten kalıcı 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 işlemi, monitor history, notification credential'ları ve maintenance window'lar geri geldiğinde ve bir test alert'i hâlâ iletildiğinde başarılıdır. Kalıcı mount ile bağımsız bir kopya arasındaki fark persistent storage and snapshots bölümünde ele alınır.

Uptime Kuma'ya tek bir canonical adres verin

Reverse proxy üzerinden tek bir stable HTTPS origin yayınlayın. Seçtiğiniz hostname'i container port 3001'e yönlendirin, original host ile HTTPS scheme'i forward edin ve ikinci bir direct origin yayınlamaktan kaçının.

Uptime Kuma'yı temiz bir external client üzerinden test edin. Ingress hatasını bilinen application boundary'den ayırın — veri volume'ü salt okunur olabilir veya container DNS'i izlenen host adlarını çözemeyebilir. Certificate, DNS veya 502 hatası routing'e aittir; Uptime Kuma'ya ulaşan ve daha sonra başarısız olan bir request ise application state'ine, capacity'ye veya supporting requirement'a aittir. custom-domain TLS guide ilk grubu ele alır.

Uptime Kuma'ya özgü security kararları

Uygulamaya özgü security riski, first-user setup işlemini public olarak erişilebilen bir instance üzerinde çalıştırmaktır. Operasyonel çözüm, first-user setup'ı private olarak tamamlamak, ardından dashboard'ları ve status-page administration'ı ayrı ayrı korumaktır. Bootstrap işlemini restricted bir route üzerinden tamamlayın ve geçici setup erişimini hemen ardından kaldırın.

UPTIME_KUMA_PORT, confidentiality yerine davranışı kontrol eder; türünü ve değerini doğrulayın, gerçek Uptime Kuma credential'larını ayrı saklayın. Uptime Kuma process'ine yalnızca dokümante edilmiş mount'ları ve dependency route'larını verin; host root ve Docker socket erişiminden kaçının. Başarısız authentication ve configuration hatalarını log'layın, ancak token'ları, connection string'leri ve user content'i redact edin.

Dockup deployment'ı yine de bir Uptime Kuma acceptance test'i gerektirir

Routing, certificate'lar, service replacement ve attached storage makul automation hedefleridir. Dockup bunları Uptime Kuma için yönetir ve ilgili managed database'i provision edebilir veya müşterinin kendi server'ındaki servislere bağlanabilir.

Uptime Kuma'nın trust policy'sini ise kendisi icat etmemelidir. Deployment sonrasında reverse proxy üzerinden tek bir stable HTTPS origin yayınlayın, şu boundary'yi uygulayın — first-user setup'ı private olarak tamamlayın, ardından dashboard'ları ve status-page administration'ı ayrı ayrı koruyun — ve şu senaryonun sonucunu doğrulayın: HTTP ve TCP monitor'leri oluşturun, kontrollü bir hata tetikleyin ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alın. Sonuç, uygulamaya özgü bir acceptance test'i olan one-click infrastructure'dır.

Sık sorulan sorular

Production deployment için Uptime Kuma neye ihtiyaç duyar?

Uptime Kuma container'ını port 3001 üzerinden tek bir HTTPS origin'e route edin. Dış delivery gereksinimi, izlenen her endpoint'e ve alert provider'a outbound erişimdir. HTTP ve TCP monitor'leri oluşturamadığınız, kontrollü bir hata tetikleyemediğiniz ve seçtiğiniz provider üzerinden uyarı ile kurtarma bildirimini alamadığınız sürece Uptime Kuma'yı hazır kabul etmeyin.

Hangi Uptime Kuma verileri backup'a dahil edilmelidir?

/app/data'yı persist edin ve SQLite database'i ile /app/data içindeki yüklenmiş asset'leri aynı recovery manifest'ine dahil edin. Temiz bir Uptime Kuma restore işlemi yalnızca monitor history, notification credential'ları ve maintenance window'lar geri geldiğinde ve bir test alert'i hâlâ iletildiğinde başarılıdır.

Reverse proxy arkasındaki Uptime Kuma HTTPS gerektirir mi?

Public Uptime Kuma origin'i için HTTPS kullanın ve port 3001'i internal route üzerinde tutun. Uptime Kuma ayarını doğru uygulayın: reverse proxy üzerinden tek bir stable HTTPS origin yayınlayın. Uptime Kuma 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 Uptime Kuma upgrade'i nasıl test edilmelidir?

Mevcut Uptime Kuma state'ini izole bir deployment'a restore edin, candidate version'ı uygulayın ve acceptance transaction'ını tekrarlayın. SQLite migration'ları ve notification-provider değişiklikleri, hızlı bir image pull işlemini stateful application upgrade'ine dönüştürebileceğinden özellikle dikkatli olun. Data migration ve rollback sınırları anlaşılana kadar önceki Uptime Kuma image'ını saklayın.