Kendi ntfy sunucunuzu Docker ile kurma rehberi

Kendi kendine barındırılan bir ntfy sunucusu ne işe yarar

Kendi kendine barındırılan bir ntfy sunucusu, bir HTTP POST isteğini telefonunuza gelen bir push bildirimine dönüştürür. curl ile yayın yaparsınız ve mesaj Android uygulamasına, iOS uygulamasına, bir tarayıcı sekmesine veya açık bir HTTP bağlantısını sürdürebilen herhangi bir yere ulaşır. Kurulacak bir istemci kütüphanesi veya çalıştırılacak bir mesaj aracısı yoktur.

ntfy, mesajları konu (topic) üzerinden adresler. Konu, https://ntfy.example.com/alerts gibi URL yolundaki bir isimdir ve birisi ona ilk yayınını yaptığı anda var olur. Varsayılan kurulumda, ismi bilen herkes konuyu okuyabilir ve konuya yazabilir; bu nedenle projenin kendi belgeleri bir konu ismini bir parolaya benzetir. Bu model, herkese açık ntfy.sh servisi için uygundur. Yedekleme hatalarınız gibi verileri taşıyan bir sunucu için ise uygun değildir; bu yüzden bu rehber, ilk mesaj gönderilmeden önce kimlik doğrulamasını etkinleştirir.

Başlamadan önce gerekenler

Ubuntu 24.04 veya Debian 13 çalıştıran, Docker Engine ve Compose eklentisi kurulu bir VPS'ye, bir alan adına ve çok az miktarda RAM'e ihtiyacınız vardır. Sunucunun genel IP adresine işaret eden bir DNS (domain name system) A kaydı oluşturun ntfy.example.com ve başka bir işleme geçmeden önce kaydın çözümlendiğini doğrulayın.

dig +short ntfy.example.com
sudo ufw allow 80,443/tcp
sudo ufw status

dig komutu sunucunuzun IP adresini döndürmelidir. Sertifika yetkilisi alan adını dışarıdan kontrol ettiği için, komut herhangi bir çıktı vermezse sertifika oluşturma işlemi başarısız olur. Let's Encrypt protokolünün temelini oluşturan ACME (automatic certificate management environment) HTTP doğrulaması için 80 numaralı portu kullandığından, bu portun açık kalması gerekir. ntfy container'ı ise hiçbir zaman genel bir port üzerinden dışarıya açılmaz.

ntfy yapılandırma dosyasını oluşturma

Docker imajı bir yapılandırma dosyası içermediğinden, bir tane oluşturmanız gerekir. Bu kılavuzdaki sonraki tüm komutlar bu dosyayı okur. Öncelikle container'ın çalışacağı kullanıcı kimliğini (UID) ve grup kimliğini (GID) bulun.

id -u
id -g
sudo install -d -o "$(id -u)" -g "$(id -g)" /etc/ntfy /var/cache/ntfy /var/lib/ntfy
sudo nano /etc/ntfy/server.yml

base-url: "https://ntfy.example.com"
listen-http: ":2586"
behind-proxy: true
cache-file: "/var/cache/ntfy/cache.db"
cache-duration: "12h"
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "deny-all"
enable-login: true
enable-signup: false

Bu satırlardan dördü kritik öneme sahiptir. base-url, tam HTTPS genel adresi olmalıdır; çünkü ntfy ek bağlantılarını ve web uygulamasının kendi isteklerini bu adrese göre oluşturur. Yanlış bir değer, web uygulamasının yüklenmesine rağmen her işlemde hata vermesine neden olur. listen-http: ":2586", container içindeki tüm arayüzlere bağlanır; bu durum güvensiz görünebilir ancak doğrudur. Container kendi ağ ad alanına (network namespace) sahip olduğundan, 127.0.0.1 adresine bağlanmak portu ana makineden erişilemez kılar ve Docker'ın yayınladığı port asla bağlantı kuramaz. auth-default-access: "deny-all", tüm güvenlik duruşunu belirler; açık bir yetkilendirme olmadan okuma ve yazma işlemlerini reddeder. behind-proxy: true, ntfy'a istemci adresini X-Forwarded-For başlığından almasını söyler; böylece hız sınırlamaları (rate limits), reverse proxy'yi tek bir yoğun istemci olarak saymak yerine gerçek ziyaretçileri sayar.

enable-login: true, web uygulamasının ve telefon uygulamalarının bir parola ile oturum açmasına olanak tanır. enable-signup değeri false olarak kalmalıdır; çünkü özel bir sunucuda self-servis hesap oluşturma özelliği, yetkisiz erişimlere davetiye çıkaran bir güvenlik açığıdır.

sudo chown "$(id -u):$(id -g)" /etc/ntfy/server.yml
sudo chmod 600 /etc/ntfy/server.yml

Docker Compose ile ntfy çalıştırma

Bunu /opt/ntfy/compose.yaml içine yerleştirin ve 1000:1000 ifadesini yukarıda yazılı olan id -u ve id -g sayılarıyla değiştirin.

services:
  ntfy:
    image: binwiederhier/ntfy:v2.27.0
    container_name: ntfy
    command: serve
    user: "1000:1000"
    environment:
      - TZ=UTC
    volumes:
      - /etc/ntfy:/etc/ntfy
      - /var/cache/ntfy:/var/cache/ntfy
      - /var/lib/ntfy:/var/lib/ntfy
    ports:
      - "127.0.0.1:2586:2586"
    restart: unless-stopped

cd /opt/ntfy
sudo docker compose up -d
sudo docker compose logs ntfy
curl -s http://127.0.0.1:2586/v1/health

Sağlıklı bir sunucu {"healthy":true} yanıtını verir. Bu compose dosyasındaki iki detay kasıtlıdır. İmaj, latest yerine Ağustos 2026 itibarıyla güncel sürüm olan v2.27.0 sürümüne sabitlenmiştir; çünkü latest kullanıldığında bir sonraki docker compose pull sunucu sürümünüzü değiştirir ve durumu ancak sonrasında değişiklik günlüğünden (changelog) fark edersiniz. Port 127.0.0.1:2586:2586 olarak yayınlanmıştır, bu sayede container'a yalnızca ana makinenin loopback adresi üzerinden erişilebilir. Bunun yerine 2586:2586 yazarsanız Docker, kendi güvenlik duvarı kurallarını sizinkilerin önüne ekler; bu da ufw status portun kapalı olduğunu söylese bile portun internetten yanıt vermesine neden olur.

Eğer curl Connection refused çıktısını verirse container günlüğünü okuyun. /var/lib/ntfy/user.db üzerindeki bir izin hatası, user: satırının bu dizinlerin sahibiyle eşleşmediği anlamına gelir; bu durumda süreç kendi veritabanını oluşturamaz ve sonlanır. VPS için Docker Compose temel rehberi, birim sahipliği ve yeniden başlatma politikalarını daha ayrıntılı olarak ele almaktadır.

Caddy ile TLS yapılandırması

Caddy, sertifikayı kendi başına talep eder ve yeniler; bu, çalışan bir TLS (transport layer security) elde etmenin en kısa yoludur.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

/etc/caddy/Caddyfile dosyasının içeriğini üç satır ile değiştirin.

ntfy.example.com {
    reverse_proxy 127.0.0.1:2586
}

sudo systemctl reload caddy
curl -s https://ntfy.example.com/v1/health

HTTPS üzerinden aynı {"healthy":true}, tüm yolun çalıştığı anlamına gelir. Caddy'den gelen bir 502, ntfy'nin dinlemede olmadığını gösterir: sudo ss -lntp | grep 2586 ile kontrol edin. Sertifika hatası genellikle DNS kaydının yanlış olduğu veya 80 numaralı portun engellendiği anlamına gelir; sudo journalctl -u caddy -n 50 hangisinin hatalı olduğunu belirtir.

Halihazırda nginx kullanıyorsanız, ntfy belgelerinde belirtilen proxy ayarlarını kopyalayın: proxy_http_version 1.1, proxy_buffering off, proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ve okuma/gönderme zaman aşımlarını en az üç dakika olarak ayarlayın. Bir abone, dinleme yaptığı sürece bir HTTP bağlantısını açık tutar; nginx ise boşta kalan bir upstream bağlantısını varsayılan olarak 60 saniye sonra kapatır. Bu durumda aboneler sürekli yeniden bağlanır ve bu boşluk sırasında gönderilen iletiler kaybolur.

Kullanıcı oluşturma ve konu kısıtlamaları

Kimlik doğrulama etkinleştirildi ve henüz kimsenin hiçbir şeye erişimi yok; amaç da zaten bu. Kendiniz için bir yönetici hesabı ve betikler için bir makine hesabı oluşturun. Bu komutlar /etc/ntfy/server.yml dosyasını container içinden okur, bu nedenle yapılandırma dosyası bir volume mount olarak tanımlanmıştır.

sudo docker compose exec ntfy ntfy user add --role=admin admin
sudo docker compose exec ntfy ntfy user add robot
sudo docker compose exec ntfy ntfy user list

Her komut bir parola ister. Yönetici, erişim listesini yok sayar ve her konuyu okuyup yazabilir; bu yüzden bu hesabı kendiniz ve mobil uygulama için saklayın. robot, siz izin verene kadar hiçbir erişimi olmayan sıradan bir kullanıcıdır.

sudo docker compose exec ntfy ntfy access robot alerts write
sudo docker compose exec ntfy ntfy access robot "alerts_*" write
sudo docker compose exec ntfy ntfy access

Bir ACL (erişim kontrol listesi) girdisi; bir kullanıcı, bir konu ve bir izinden oluşur. Konu, doğrudan bir isim veya * ifadesinin her şeyle eşleştiği bir desen olabilir; bu sayede alerts_* ifadesi, her ana bilgisayar için ayrı komut girmeye gerek kalmadan alerts_backup ve alerts_db konularını kapsar. write izni yalnızca yayınlama (publish) yetkisi verir; böylece bir cron işinden çalınan token, gönderilen verileri abone olup okuyamaz. Özel everyone kullanıcı adı, kimliği doğrulanmamış ziyaretçilerin ne yapabileceğini belirler; bunu yalnızca ntfy access everyone status read gibi kasıtlı olarak herkese açık bir alan oluşturmak istediğinizde kullanmalısınız.

Betikler parolanızı değil, bir token taşımalıdır.

sudo docker compose exec ntfy ntfy token add robot

Komut, tk_ ile başlayan bir token çıktısı verir. Bir token, ait olduğu kullanıcının erişim yetkilerini aynen devralır; bu nedenle bu token yalnızca alerts konularına yayın yapabilir ve başka hiçbir işlem yapamaz. ntfy token list mevcut olanları listeler, ntfy token remove ise kullanıcının parolasına dokunmadan bir token'ı iptal eder.

İlk mesajınızı gönderin ve kilidin çalıştığını doğrulayın

Öncelikle kapının kapalı olduğundan emin olun.

curl -s -o /dev/null -w '%{http_code}\n' -d "hello" https://ntfy.example.com/alerts

Bu komut 403 çıktısını verir ve 403 doğru cevaptır: auth-default-access: "deny-all" anonim yayınları reddeder. Şimdi gerçek bir mesaj gönderin.

curl -H "Authorization: Bearer tk_REPLACE_WITH_YOUR_TOKEN" \
  -H "Title: Nightly backup finished" \
  -H "Priority: default" \
  -H "Tags: white_check_mark" \
  -d "42 GB copied in 11 minutes" \
  https://ntfy.example.com/alerts

Sunucu, mesajın yutulmak yerine kabul edildiğini anlamanızı sağlayan JSON formatındaki saklanan mesajla yanıt verir. Title kalın yazılmış ilk satırdır. Priority 1 ile 5 arasında bir değer alır veya min ile urgent arasında bir isimle belirtilir; telefonun ses çıkarıp çıkarmayacağına bu değer karar verir. Tags, isim bilinen bir emoji kısa koduyla eşleştiğinde bildirimde emojiye dönüşür, eşleşmediğinde ise düz metin olarak kalır.

Bir konuyu terminal üzerinden izlemek için akışı başlatın:

curl -s -u admin https://ntfy.example.com/alerts/raw

curl şifreyi ister. Her mesaj tek bir satır olarak gelir; zaman zaman görünen boş satırlar ise bağlantıyı canlı tutan (keepalive) sinyallerdir. https://ntfy.example.com adresini bir tarayıcıda açıp aynı hesapla giriş yapmak, aynı akışın web uygulaması sürümünü sunar.

Sunucunun aşırı yüklenmesini önlemek için hız sınırlamalarını yapılandırın

Varsayılan olarak her ziyaretçiye 60 isteklik bir kota tanımlanır ve bu kota her 5 saniyede bir istek yenilenir. Bu değer kişisel bir sunucu için oldukça cömerttir; ancak bir yeniden deneme döngüsüne giren betik, bu kotanın tamamını tüketebilir. server.yml dosyasına limitleri ekleyin.

visitor-request-limit-burst: 30
visitor-request-limit-replenish: "10s"
visitor-message-daily-limit: 500

sudo docker compose restart ntfy

Limiti aşan bir ziyaretçi, içeriği almak yerine HTTP 429 yanıtı alır. Limit, ziyaretçi adresi bazında hesaplanır; bu nedenle behind-proxy: true ayarı kritik öneme sahiptir. Bu ayar yapılmadığında ntfy yalnızca Caddy'nin adresini görür; tüm istemciler aynı ziyaretçi olarak sayılır ve hatalı çalışan tek bir betik, telefonunuzun ve diğer sunucularınızın paylaştığı kotayı tüketir.

Başarısız olan bir cron işinden gelen uyarı

Token bilgisini komut satırından uzak tutun. ps aux, sunucudaki her kullanıcıya çalışan tüm süreçlerin tam komut satırını gösterir; bu nedenle -H ile iletilen bir token, curl çalıştığı sürece herhangi bir yerel hesap tarafından okunabilir. Bir curl yapılandırma dosyası bu durumu engeller.

sudo install -d -m 700 /etc/ntfy-alert
printf 'header = "Authorization: Bearer tk_REPLACE_WITH_YOUR_TOKEN"\n' | sudo tee /etc/ntfy-alert/curlrc
sudo chmod 600 /etc/ntfy-alert/curlrc

Şimdi işi sarmalayın. Bunu /usr/local/bin/backup-with-alert.sh olarak kaydedin ve chmod 750 ile yetkilendirin.

#!/bin/bash
out=$(/usr/local/bin/backup.sh 2>&1)
code=$?
if [ "$code" -ne 0 ]; then
  printf '%s' "$out" | tail -c 1000 | curl -K /etc/ntfy-alert/curlrc \
    -H "Title: backup.sh failed with exit $code" \
    -H "Priority: high" \
    -H "Tags: warning" \
    --data-binary @- \
    https://ntfy.example.com/alerts
fi
exit "$code"

17 3 * * * /usr/local/bin/backup-with-alert.sh >> /var/log/backup-alert.log 2>&1

$?, komuttan hemen sonraki satırda yakalanır; çünkü çalıştırılacak bir sonraki komut onu üzerine yazacaktır. Çıktı tail -c 1000 üzerinden geçirilir; çünkü ntfy maksimum mesaj boyutunu zorunlu tutar ve bir bildirim, günlük görüntüleyici değildir. Kapanıştaki exit "$code", orijinal durumu korur; böylece bu işi izleyen diğer süreçler hala bir hata görür. Tüm yapıyı, betiği bir kerelik /bin/false adresine yönlendirerek test edin.

Hiç çalışmayan bir hata dalı, hiç uyarı vermemekten daha kötüdür; çünkü sessizliğin başarı anlamına geldiği izlenimini yaratır. Cron, işinize neredeyse boş bir ortam ve oturum açma kabuğunuzdan çok daha kısa bir PATH sağlar; bu nedenle elle çalıştırdığınızda sorunsuz işleyen bir betik, curl satırına ulaşamadan sonlanabilir. Cron işinin neden çalışmadığına dair rehber, bu ortam tuzaklarını ele almaktadır. Her yerde mutlak yollar (absolute paths) kullanın ve varsayımda bulunmak yerine, ilk zamanlanmış çalışmadan sonra günlük dosyasını okuyun.

Bir systemd birimi başarısız olduğunda uyarı alma

Cron, zamanlanmış işleri kapsar. Uzun süre çalışan servisler, bir birim failed durumuna girdiğinde systemd tarafından çalıştırılan OnFailure= mekanizmasına ihtiyaç duyar. Bir şablon birim oluşturun ve bunu sunucudaki her servis için yeniden kullanın. Bunu /etc/systemd/system/ntfy-unit-failed@.service olarak kaydedin.

[Unit]
Description=Send an ntfy alert because %i failed

[Service]
Type=oneshot
ExecStart=/usr/local/bin/ntfy-unit-failed %i

Ardından /usr/local/bin/ntfy-unit-failed komutunu 750 modunda çalıştırın:

#!/bin/bash
unit="$1"
journalctl -u "$unit" -n 15 --no-pager -o cat | tail -c 1000 | curl -K /etc/ntfy-alert/curlrc \
  -H "Title: $unit failed on $(hostname -s)" \
  -H "Priority: urgent" \
  -H "Tags: rotating_light" \
  --data-binary @- \
  https://ntfy.example.com/alerts

Bunu bir drop-in dosyası ile servise bağlayın; böylece paket yükseltmeleri yaptığınız düzenlemeyi üzerine yazamaz.

sudo systemctl edit myapp.service

[Unit]
OnFailure=ntfy-unit-failed@%n.service

%n, tam birim adına genişletilir, bu nedenle örnek ntfy-unit-failed@myapp.service haline gelir ve şablon içindeki %i, myapp.service değerini betiğe ilk argüman olarak iletir. Tek bir şablonun her birime hizmet etmesini sağlayan şey budur. /etc/systemd/system/ntfy-selftest.service olarak kaydedilen ve kasten başarısız olan bir birimle çalıştığını doğrulayın.

[Unit]
Description=Deliberately failing unit
OnFailure=ntfy-unit-failed@%n.service

[Service]
Type=oneshot
ExecStart=/bin/false

sudo systemctl daemon-reload
sudo systemctl start ntfy-selftest.service

Başlatma komutu sıfır olmayan bir değerle çıkar ve Job for ntfy-selftest.service failed because the control process exited with error code çıktısını verir; telefonunuz yaklaşık bir saniye sonra bildirim almalıdır. Test birimini sonrasında silin.

Bir tuzak dikkat gerektirir. OnFailure= yalnızca bir birim failed durumuna ulaştığında çalışır; Restart=always özelliğine sahip bir servis, systemd onu sürekli yeniden başlattığı için bu duruma asla ulaşamayabilir. Birim, yalnızca StartLimitIntervalSec süresi içinde StartLimitBurst yeniden başlatma sınırını aştığında başarısız sayılır. Haberdar olmak istediğiniz her serviste bu iki değeri ayarlayın, aksi takdirde bir çökme döngüsü günlerce sessizce devam edebilir. Zamanlayıcılar (timers), yukarıdaki cron modelinin daha temiz bir alternatifidir; çünkü bir zamanlayıcının servis birimi OnFailure= özelliğine kendiliğinden sahiptir ve bir VPS üzerinde systemd servisleri ve zamanlayıcıları rehberi, bir servisin dönüştürülmesini adım adım açıklar.

Uptime izleyicisini aynı konuya bağlama

Kendi kendine barındırılan durum izleyicisi Uptime Kuma, yerleşik bir ntfy bildirim türü ile gelir. Settings, ardından Notifications ve Setup Notification yolunu izleyin, Ntfy seçeneğini belirleyin, sunucu URL'sini https://ntfy.example.com olarak, konuyu ise alerts olarak ayarlayın, bir öncelik seçin ve robot erişim belirtecini yapıştırın. Kaydetmeden önce test bildirimini gönderin; çünkü yanlış bir konu adı, onu kapsamayan bir write yetkisi üzerinde sessizce başarısız olur.

Bu kurulumun dürüst sınırı şudur: Aynı VPS üzerinde çalışan bir izleyici, size VPS'nin kapalı olduğunu söyleyemez ve ntfy, ntfy'nin kapalı olduğu haberini iletemez. İzleyiciyi farklı bir makinede çalıştırın ve ntfy'nin kendisini izleyen monitör için e-posta gibi ikinci bir bildirim kanalı tanımlayın. Uptime Kuma'nın Push monitör türü diğer kör noktayı kapsar: cron işiniz başarılı bir çalışmadan sonra bir push URL'sini çağırır ve Kuma, bu çağrılar gelmeyi bıraktığında uyarı verir. Bir hata dalı yalnızca iş çalıştığında tetiklenir, bu nedenle hiç başlamayan iş hakkında hiçbir bilgi vermez.

Self-hosted ntfy, Android ve iPhone üzerinde çalışır mı?

Android üzerinde, evet, hiçbir kısıtlama olmaksızın çalışır. Uygulamayı Google Play veya F-Droid üzerinden yükleyin, Ayarlar'ı açın, varsayılan sunucuyu https://ntfy.example.com olarak ayarlayın, kullanıcı yönetimi ekranından hesabınızı ekleyin ve ardından alerts kanalına abone olun. Anlık teslimat özelliği, telefon "doze" modundayken bile mesajların ulaşması için bir ön plan servisini çalışır durumda tutar; bununla birlikte gelen kalıcı bildirim bir hata değil, Android'in ön plan servisleri için zorunlu kıldığı bir gerekliliktir. F-Droid sürümü hiçbir Firebase kodu içermez, bu nedenle her abonelik anlık teslimat kullanır. ntfy ayrıca Google'ın push servisine açık bir alternatif olan UnifiedPush dağıtıcısı olarak da görev yapabilir; böylece UnifiedPush destekleyen diğer uygulamalar da mesajlarını sizin sunucunuz üzerinden iletebilir.

iOS üzerinde ise kaldıramayacağınız tek bir bağımlılıkla çalışır. Apple, arka plana atılmış bir uygulamayı yalnızca APNs (Apple push bildirim servisi) aracılığıyla uyandırır ve uygulamaya yalnızca imzalama kimlik bilgilerine sahip olan taraf bildirim gönderebilir; bu nedenle sunucunuzun uygulamaya doğrudan ulaşma imkanı yoktur. ntfy bu sorunu bir aktarıcı (relay) ile çözer: sunucunuz, mesaj kimliğini içeren bir poll_request bilgisini ntfy.sh adresine gönderir; burası da Firebase ve APNs üzerinden uygulamayı uyandırır ve uygulama daha sonra mesaj içeriğini sizin sunucunuzdan çeker.

upstream-base-url: "https://ntfy.sh"

Bunun maliyeti konusunda net olunmalıdır. Mesaj içeriği sizin sunucunuzda kalır, ancak bir mesajın ulaştığı bilgisi ve mesajın kimliği, sizin yönetmediğiniz bir altyapı üzerinden geçer. Bu ayar olmadan, self-hosted bir sunucudan iPhone'a gelen bildirimler geç ulaşır veya hiç ulaşmaz, çünkü uygulamayı uyandıracak bir mekanizma yoktur. Aktarıcıyı devreden çıkarmanın tek yolu, iOS uygulamasını kendi Apple geliştirici hesabınız ve kendi APNs anahtarlarınızla derleyip yayınlamaktır; bu da yıllık bir ücret ve her güncelleme için yeniden derleme yapmanız anlamına gelir. Eğer aktarıcı kullanımı sizin için kabul edilemezse, bildirimleri Android veya masaüstü web uygulaması üzerinden takip edin.

Yedeklemeler, yükseltmeler ve imaj sabitleme

İki yol yeniden oluşturulamaz: /etc/ntfy/server.yml ve /var/lib/ntfy/user.db. İkincisi tüm kullanıcıları, parola özetlerini, ACL girişlerini ve belirteçleri barındırır; bu nedenle dosyayı özel bir anahtar gibi koruyun.

sudo tar czf ntfy-backup.tgz -C / etc/ntfy var/lib/ntfy
sudo chmod 600 ntfy-backup.tgz

Bu dosyayı sunucudan dışarı kopyalayın. cache.db yalnızca yakın zamana ait iletileri, yukarıdaki cache-duration ile 12 saatlik veriyi tutar; bu yüzden kaybı, korunmaya değer bir veri kaybı oluşturmaz. Yükseltme işlemi, compose dosyasındaki etiketi düzenleyip imajı çekmek (pull) anlamına gelir.

sudo docker compose pull
sudo docker compose up -d
curl -s https://ntfy.example.com/v1/health

Önce sürüm notlarını okuyun. SQLite veritabanları başlatma sırasında geçiş yapar; bu nedenle şema değişikliğinden sonra eski bir etikete geri dönmek güvenli değildir. Yeni sürüm bir gün boyunca sorunsuz çalışana kadar aldığınız yedeği saklayın.

Gotify ve Apprise

Gotify daha küçük bir seçenektir: web arayüzüne ve Android uygulamasına sahip tek bir binary dosyadan oluşur; konu joker karakterleri (wildcard) ve resmi bir iOS istemcisi yoktur, bu da yalnızca Android'in hedef olduğu özel bir sunucu için uygundur. Apprise bir sunucudan ziyade bir Python kütüphanesi ve komut satırı aracıdır; tek bir mesajı ntfy dahil yüzden fazla servise dağıtır, bu da aynı anda birçok yere ulaşması gereken betikler için uygundur. ntfy ise size bir sunucu, HTTP API ve her iki mobil platformda da uygulama sunan çözümdür; bu nedenle kiralanan bir sunucudan bildirim göndermek için genellikle tercih edilen yanıt budur.

FAQ

ntfy sunucuma yayın yaparken neden 403 hatası alıyorum?

auth-default-access: "deny-all", server.yml içinde etkinleştirildiğinde anonim yayınlar reddedilir; bu beklenen bir davranıştır. -u user:pass veya -H "Authorization: Bearer tk_..." ile kimlik bilgilerinizi gönderin. Zaten bir token gönderiyor ve hala 403 hatası alıyorsanız, ilgili token'a sahip kullanıcının konu (topic) için eşleşen bir ACL girişi yoktur. Tam listeyi görüntülemek için ntfy access komutunu çalıştırın. Bir write izninin abone olmayı kapsamadığını unutmayın; bu nedenle yayın yapabilen bir hesap, aynı konuyu okumaya çalıştığında reddedilebilir.

Kendi barındırdığım ntfy sunucusu ile iPhone üzerinde bildirimler çalışır mı?

Bildirimler, kaçınılmaz bir aktarıcı (relay) aracılığıyla çalışır. Apple, uygulamaları yalnızca APNs (Apple push notification service) üzerinden uyandırır ve buna yalnızca uygulamanın yayıncısı gönderim yapabilir. Bu nedenle ntfy, mesaj kimliğini içeren bir poll_request paketini ntfy.sh adresine iletir ve o da cihazınıza aktarır. server.yml dosyasında upstream-base-url: "https://ntfy.sh" ayarını yapılandırın ve container'ı yeniden başlatın. Mesaj içeriği yine de doğrudan sizin sunucunuzdan çekilir. Bu ayar yapılmadığında, iOS bildirimleri gecikir veya hiç görünmez.

Cron işimden gelen ntfy uyarısı neden hiç ulaşmadı?

Token ve konu bilgilerinin doğruluğunu kanıtlamak için önce curl komutunu manuel olarak çalıştırın. Komut manuel olarak çalışıyor ancak cron üzerinde çalışmıyorsa, sorun uyarının öncesindedir: cron işleri kısıtlı bir ortam ve kısa bir PATH ile çalıştırır; bu nedenle komutları sadece isimleriyle çağıran bir betik, curl satırına ulaşamadan sonlanabilir. Mutlak yolları (absolute paths) kullanın, işin çıktısını bir günlük dosyasına yönlendirin ve bir sonraki çalıştırmadan sonra bu dosyayı inceleyin. Teslimat yerine 429 yanıtı alıyorsanız, hız sınırlaması (rate limit) devreye girmiş demektir ve betiğiniz çok sık yeniden deneme yapıyordur.

ntfy'ı genel internete açmalı mıyım?

Mobil uygulamaların sunucuya mobil ağlar üzerinden erişebilmesi gerekir; bu nedenle auth-default-access: "deny-all" ve konu bazlı ACL'lere sahip genel bir HTTPS uç noktası standart kurulumdur. Hiçbir konu everyone tarafından okunabilir olmadığı sürece bu yapı güvenlidir. Yalnızca VPN üzerinden erişilen bir kurulum, tüm abonelerin kontrolünüz altındaki makineler olduğu durumlar için mantıklıdır. Telefonlar için uygun bir yöntem değildir; çünkü uygulama yalnızca tünel aktifken veri alabilir, bu nedenle uyarılar telefon tekrar bağlanana kadar kuyrukta bekler.