Uptime Kuma with ntfy 2.5.7

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened Uptime Kuma, Gatus & Uptime and Status Pages AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose One-click launch from AWS Marketplace, or Launch from EC2 Console for the full launch wizard. In Version, choose Uptime Kuma with ntfy 2.5.7 on Ubuntu 24.04, then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and the software charge is $0.04 per vCPU per hour.
• Set the security group to allow SSH (22), HTTP (80), HTTPS (443) and 8443 (ntfy, where your phone, browser or scripts subscribe). Restrict SSH to your own IP address, 80 and 443 to the people who use the dashboard, and 8443 to the devices that subscribe.
• Choose your VPC and a subnet that gives the instance a public IP. Leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch.

Option B: AWS CLI

Run this command on your own workstation. It creates a security group that allows SSH, the dashboard and ntfy from your management address only, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and CIDR with your own values.

SG=$(aws ec2 create-security-group --group-name uptime-kuma-ntfy \
  --description "Uptime Kuma with ntfy" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text) for p in 22 80 443 8443; do aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port "$p" --cidr <your-mgmt-cidr> done aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=uptime-kuma-ntfy}]'

You do not need --metadata-options, because the AMI already makes IMDSv2 required.

Connect as ubuntu with the key pair you chose.

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It creates the certificate, both applications' databases and accounts, and the ntfy token and topic, then lets the services start. Read your credentials from the root-only file.

sudo cat /root/uptime-kuma-ntfy-credentials.txt

# Uptime Kuma with ntfy - generated on this instance's first boot by uptime-kuma-ntfy-firstboot.service. # Unique to this instance; nothing here shipped in the image. Store it somewhere safe. KUMA_URL=https://ec2-35-174-111-13.compute-1.amazonaws.com/ KUMA_ADMIN_USERNAME=admin KUMA_ADMIN_PASSWORD=<KUMA_ADMIN_PASSWORD> NTFY_URL=https://ec2-35-174-111-13.compute-1.amazonaws.com:8443/ NTFY_USERNAME=sac NTFY_PASSWORD=<NTFY_PASSWORD> NTFY_TOKEN=<NTFY_TOKEN> NTFY_TOPIC=<NTFY_TOPIC> NTFY_SUBSCRIBE_URL=https://ec2-35-174-111-13.compute-1.amazonaws.com:8443/<NTFY_TOPIC> # # Uptime Kuma: open KUMA_URL and sign in as admin (self-signed certificate minted on this instance; port 80 redirects). # Every monitor you create alerts through the default "ntfy (this instance)" channel to NTFY_TOPIC. # ntfy: subscribe to NTFY_SUBSCRIBE_URL in the ntfy app or a browser as NTFY_USERNAME / NTFY_PASSWORD, or with # curl -H "Authorization: Bearer <NTFY_TOKEN>" https://<host>:8443/<NTFY_TOPIC>/json # Change the name both are served as:
sudo uptime-kuma-ntfy-set-hostname <your-dns-name>
# Restrict 80/443/8443 in the security group to the people and devices that need them.
# Guide: https://secureanycloud.com/stacks/uptime-kuma-with-ntfy-2-5-7/

KUMA_ADMIN_PASSWORD, NTFY_PASSWORD, NTFY_TOKEN and NTFY_TOPIC hold your instance's own values. The topic name is long and random, so it cannot be guessed. ntfy also refuses the topic to anyone without your credentials.

Check that first boot, Uptime Kuma, ntfy and nginx are active. Confirm that the two applications run as their own unprivileged users, that ntfy reports healthy, and that the start guard passes. The guard runs before every start of the three services.

systemctl is-active uptime-kuma-ntfy-firstboot.service uptime-kuma.service ntfy.service nginx.service ps -o user=,comm= -p "$(systemctl show -p MainPID --value uptime-kuma.service),$(systemctl show -p MainPID --value ntfy.service)" curl -sf http://127.0.0.1:8088/v1/health | jq -e '.healthy == true'
sudo /usr/local/sbin/uptime-kuma-ntfy-guard

active active active active ntfy ntfy kuma uptime-kuma true GUARD_OK

If a service ever refuses to start, run the guard. It names the exact reason.

List the TCP ports the instance listens on.

sudo ss -Hltn | awk '{print $4}' | sort -u

0.0.0.0:22 0.0.0.0:443 0.0.0.0:80 0.0.0.0:8443 127.0.0.1:3001 127.0.0.1:8088 127.0.0.53%lo:53 127.0.0.54:53 [::]:22 [::]:443 [::]:80 [::]:8443

Uptime Kuma (3001) and ntfy (8088) listen on loopback only; nginx publishes them on 443 and 8443. The loopback port 53 entries are Ubuntu's local stub resolver (systemd-resolved).

Check the versions and the build record.

/opt/ntfy/bin/ntfy --version node --version grep -E '^(Uptime Kuma|ntfy|Node.js| source| binary sha256| govulncheck)' /usr/share/doc/sac-uptime-kuma-ntfy/BUILD-INFO.txt

ntfy version 2.34.0 v22.23.4 Uptime Kuma 2.5.7 with ntfy 2.34.0 - sac build (d-320, d-304, d-094) Uptime Kuma 2.5.7 (MIT, uptime-kuma-LICENSE) source https://github.com/louislam/uptime-kuma/archive/refs/tags/2.5.7.tar.gz ntfy 2.34.0 (Apache-2.0 / GPL-2.0 dual licence, ntfy-LICENSE + ntfy-LICENSE.GPLv2) source https://github.com/binwiederhier/ntfy/archive/refs/tags/v2.34.0.tar.gz binary sha256 96092dc8fc817e8b3f64643725b8a73c086a373fc3fb73c012ebea646dcdbd2f govulncheck v1.9.0 -mode=binary and source mode: 0 reachable vulnerabilities (DB updated: 2026-10-21 00:27:29 +0000 UTC) Node.js v22.23.4 (MIT, nodejs-LICENSE)

Browse to the KUMA_URL from Step 2, for example https://ec2-35-174-111-13.compute-1.amazonaws.com/. The certificate is self-signed, so your browser warns once. Accept the warning, or install your own certificate (Step 9). Because the administrator already exists, Uptime Kuma asks you to sign in instead of creating an account.

Sign in as admin with KUMA_ADMIN_PASSWORD. The dashboard lists your monitors. A new instance has one, a self-check of the local ntfy server. The screenshot below is from an instance with two more monitors added, one of them pointing at a closed port so it is down.

You can also confirm from the command line that the first-run pages are closed. Port 80 only redirects to HTTPS. Uptime Kuma reports that neither the database setup nor the account setup is needed, and the account table holds only your admin. Uptime Kuma's update check is off, it reads client addresses from the header nginx writes, and its public URL is your instance's name. The block stops with an error if any answer is not the expected one.

H=$(sudo sed -n 's/^set $ukn_host "\(.*\)";$/\1/p' /etc/nginx/sac-ukn-host.conf)
R=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' --resolve "$H:80:127.0.0.1" "http://$H/"); echo "$R"
S=$(curl -s --cacert /etc/ssl/sac/uptime-kuma-ntfy.crt --resolve "$H:443:127.0.0.1" "https://$H/setup-database-info"); echo "$S"
U=$(sudo sqlite3 "file:/var/lib/uptime-kuma/kuma.db?mode=ro" "SELECT username FROM user;"); echo "$U"
sudo sqlite3 "file:/var/lib/uptime-kuma/kuma.db?mode=ro" "SELECT key, value FROM setting WHERE key IN ('checkUpdate','trustProxy','primaryBaseURL') ORDER BY key;" [ "$R" = "301 https://$H/" ] && [ "$S" = '{"runningSetup":false,"needSetup":false}' ] && [ "$U" = admin ]

301 https://ec2-35-174-111-13.compute-1.amazonaws.com/ {"runningSetup":false,"needSetup":false} admin checkUpdate|false primaryBaseURL|"https://ec2-35-174-111-13.compute-1.amazonaws.com" trustProxy|true

In Uptime Kuma, open the profile menu, then choose Settings, then Notifications. The channel ntfy (this instance) is already there.

It publishes to the ntfy server on this instance with your access token. It is marked as the default, so it is pre-selected on every new monitor.

CH=$(sudo sqlite3 "file:/var/lib/uptime-kuma/kuma.db?mode=ro" \
  "SELECT name, is_default, json_extract(config,'$.ntfyserverurl'), json_extract(config,'$.ntfyAuthenticationMethod') FROM notification;")
echo "$CH" [ "$CH" = 'ntfy (this instance)|1|http://127.0.0.1:8088|accessToken' ]

ntfy (this instance)|1|http://127.0.0.1:8088|accessToken

Choose Add New Monitor. Pick a monitor type (HTTP(s), keyword, TCP port, ping, DNS and many more), give it a name and a target, and save. Leave ntfy (this instance) ticked under Notifications. When a monitor cannot reach its target, it goes red and fires an alert. Its page shows the check history.

Uptime Kuma checks your endpoints from this instance, so the instance needs a network path to them. Monitoring requires no inbound rules in the security group.

Alerts land on your instance's ntfy topic on port 8443. Anything that speaks HTTP can subscribe.

From a browser, open NTFY_URL and sign in with NTFY_USERNAME and NTFY_PASSWORD. Then subscribe to NTFY_TOPIC.

From the ntfy app for Android or iOS, add a subscription with Use another server. Enter NTFY_URL and your topic, and sign in with the same user. Your phone must trust the instance's certificate, so install your own certificate first (Step 9). Without an upstream relay, the iOS app delivers notifications when it polls instead of instantly (see Step 10).

From a script, use the access token. This block publishes a test message with the token and reads it back from the topic. It then shows that a request without credentials is refused. The token is passed to curl as a header file, never on the command line.

H=$(sudo sed -n 's/^set $ukn_host "\(.*\)";$/\1/p' /etc/nginx/sac-ukn-host.conf)
T=$(sudo sed -n 's/^NTFY_TOPIC=//p' /root/uptime-kuma-ntfy-credentials.txt) C=(--cacert /etc/ssl/sac/uptime-kuma-ntfy.crt --resolve "$H:8443:127.0.0.1") M="test from $(hostname) at $(date -u +%H:%M:%S)"
P=$(curl -s "${C[@]}" -H @<(sudo sed -n 's/^NTFY_TOKEN=/Authorization: Bearer /p' /root/uptime-kuma-ntfy-credentials.txt) -d "$M" "https://$H:8443/$T" | jq -r .event)
G=$(curl -s "${C[@]}" -H @<(sudo sed -n 's/^NTFY_TOKEN=/Authorization: Bearer /p' /root/uptime-kuma-ntfy-credentials.txt) "https://$H:8443/$T/json?poll=1" | jq -r 'select(.event == "message") | .message' | grep -cxF "$M")
A=$(curl -s "${C[@]}" -o /dev/null -w '%{http_code}' "https://$H:8443/$T/json?poll=1")
N=$(curl -s "${C[@]}" -o /dev/null -w '%{http_code}' -d 'anonymous publish' "https://$H:8443/$T")
echo "publish with token : $P";
echo "read back with token : $G message";
echo "anonymous subscribe : $A";
echo "anonymous publish : $N" [ "$P" = message ] && [ "$G" = 1 ] && [ "$A" = 403 ] && [ "$N" = 403 ]

publish with token : message read back with token : 1 message anonymous subscribe : 403 anonymous publish : 403

To stream alerts as they arrive, drop ?poll=1 and keep the connection open (https://<host>:8443/<topic>/json). You can also use /<topic>/sse or /<topic>/ws. From another machine, use your instance's address and the same Authorization: Bearer header.

Run the self-test that ships with the image. It exercises the real path. It signs in to Uptime Kuma through nginx with your administrator credentials and creates a temporary monitor pointing at a closed port, so the monitor must go down. It waits for the alert, then reads the alert back from your ntfy topic through nginx on 8443 with your access token, as a subscriber would. It deletes the temporary monitor afterwards.

OUT=$(sudo /usr/local/sbin/sac-uptime-kuma-e2e-probe 2>&1) || { echo "$OUT"; exit 1; } echo "$OUT" | grep -E '^(probe: (signed in|default ntfy channel|ALERT| title| message)|E2E_PIPELINE_OK)' grep -qx 'E2E_PIPELINE_OK' <<<"$OUT"

probe: signed in to Uptime Kuma as admin (JWT issued) probe: default ntfy channel present (id 1) -> topic <NTFY_TOPIC> probe: ALERT DELIVERED to an authenticated subscriber of https://ec2-35-174-111-13.compute-1.amazonaws.com:8443/<NTFY_TOPIC> probe: title = sac e2e probe 1792610335769 Down [Uptime-Kuma] probe: message = connect ECONNREFUSED 127.0.0.1:1 E2E_PIPELINE_OK

Run it after any change to the instance. If it fails, alerts are not reaching your subscribers.

First boot created the certificate for the instance's public DNS name, public IP, private IP and localhost. The key, the credentials file and both data directories are readable only by their owners. Inspect the certificate with this command.

sudo openssl x509 -in /etc/ssl/sac/uptime-kuma-ntfy.crt -noout -subject -ext subjectAltName
sudo stat -c '%a %U:%G %n' /etc/ssl/sac/uptime-kuma-ntfy.key /root/uptime-kuma-ntfy-credentials.txt /var/lib/uptime-kuma /var/lib/ntfy /etc/ntfy/server.yml

subject=CN = ec2-35-174-111-13.compute-1.amazonaws.com, O = sac X509v3 Subject Alternative Name: DNS:ec2-35-174-111-13.compute-1.amazonaws.com, IP Address:35.174.111.13, IP Address:172.31.91.150, IP Address:127.0.0.1, DNS:localhost 600 root:root /etc/ssl/sac/uptime-kuma-ntfy.key 600 root:root /root/uptime-kuma-ntfy-credentials.txt 750 kuma:kuma /var/lib/uptime-kuma 750 ntfy:ntfy /var/lib/ntfy 640 root:ntfy /etc/ntfy/server.yml

To serve both under your own DNS name, run the helper. An example name is status.example.com, pointed at this instance. The helper records the name and creates a new self-signed certificate for it. It updates nginx, ntfy's base URL and Uptime Kuma's Primary Base URL (used in alert links), restarts what is running and rewrites the URLs in the credentials file.

sudo uptime-kuma-ntfy-set-hostname status.example.com

If the instance's public address changes after a stop and start, run the helper again.

To use a certificate from your own certificate authority, replace /etc/ssl/sac/uptime-kuma-ntfy.key (keep it 0600 root) and /etc/ssl/sac/uptime-kuma-ntfy.crt. Then run sudo systemctl reload nginx. This is recommended before you subscribe phones.

ntfy listens on loopback, denies anonymous access, allows no self-registration, and has no relay, push service or mail server configured. The last line of the output counts upstream-base-url, firebase-key-file, web-push-public-key and smtp-sender-addr entries, and the count is none. The three services cannot reach the instance metadata service, while the Amazon Time Sync Service at 169.254.169.123 keeps working. The firmware-metadata refresh is masked. Run this block to check each setting.

sudo grep -E '^(listen-http|auth-default-access|enable-signup|enable-reservations|require-login|behind-proxy)' /etc/ntfy/server.yml
OUTBOUND=$(sudo grep -cE '^(upstream-base-url|firebase-key-file|web-push-public-key|smtp-sender-addr):' /etc/ntfy/server.yml || true); echo "$OUTBOUND" systemctl show -p IPAddressDeny uptime-kuma.service ntfy.service nginx.service chronyc -n sources | grep 169.254
FW=$(systemctl is-enabled fwupd-refresh.timer fwupd-refresh.service || true); echo "$FW" [ "$OUTBOUND" = 0 ] && [ "$(sort -u <<<"$FW")" = masked ] && [ "$(systemctl show -p IPAddressDeny --value uptime-kuma.service ntfy.service nginx.service | grep -c 169.254.169.254)" = 3 ]

listen-http: "127.0.0.1:8088" auth-default-access: "deny-all" enable-signup: false require-login: true enable-reservations: false behind-proxy: true 0 IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 IPAddressDeny=168.63.129.16/32 fd00:ec2::254/128 169.254.169.254/32 ^* 169.254.169.123 3 4 377 7 +373ns[ +410ns] +/- 482us masked masked

To use features that need an outside service, configure them yourself in /etc/ntfy/server.yml. Then restart ntfy with sudo systemctl restart ntfy.

• Instant delivery to the iOS app needs upstream-base-url: "https://ntfy.sh". It forwards a poll request (not the message) for each notification to ntfy.sh.
• Email notifications need an smtp-sender-* mail server.
• Firebase (firebase-key-file) and web push (web-push-* keys) need their own credentials.

You can add Uptime Kuma's own notification providers (email, Slack, Teams, Telegram and around 90 others) in Settings → Notifications, next to the ntfy channel. To turn Uptime Kuma's update check back on, use Settings → About.