/// article

Installing Self Host NTFY On Linux Using Docker Container

By rockitpinoy

Imagine receiving a notification on your smartphone whenever your Linux server experiences a problem. Your disk is almost full. A scheduled database backup fails. A website becomes unavailable. An application deployment finishes successfully. Instead of repeatedly connecting to your server to check its status, you receive a notification whenever something requires your attention. This is where ntfy becomes useful. ntfy is an open-source notification service that allows applications, scripts, and servers to send push notifications using simple HTTP requests. You can use the public ntfy.sh service or deploy your own instance on a Linux server. In this PinoyLinux tutorial, we will install ntfy using Docker Compose, configure authentication, enable persistent storage, secure it with Nginx and HTTPS, and demonstrate how to integrate notifications with Linux administration scripts. By the end of this guide, you will have your own notification server that can send alerts to your smartphone, desktop, or other applications. 1. What Is ntfy? ntfy, pronounced notify, is an open-source publish-subscribe notification service created by Philipp C. Heckel. It allows applications and scripts to publish messages to named topics using HTTP PUT or POST requests. Other devices can subscribe to those topics and receive the published notifications. For example, a backup script can publish a message when a scheduled backup finishes. Your phone can subscribe to that topic and display the notification. You do not need to build a custom mobile application or implement an entire messaging system. A simple cURL command can send a notification. curl \ -d "Backup completed successfully" \ https://ntfy.sh/example-backup-topic This example uses the public ntfy.sh service. Later in this guide, we will replace that address with our own self-hosted server. ntfy provides a web interface, HTTP API, mobile applications, message caching, access control, and other notification features. References: ntfy Official Website ntfy GitHub Repository 2. How Does ntfy Work? ntfy uses a publish-subscribe messaging model. There are three main components: Component Description Publisher An application or script that sends a notification. Topic A named channel where notifications are published. Subscriber A device or application that receives notifications from a topic. For example, imagine a Linux server running a scheduled backup. When the backup finishes, a Bash script sends an HTTP POST request to your ntfy server. The server receives the message and distributes it to subscribers of that topic. The same approach works for application deployments, server monitoring, security alerts, and scheduled maintenance tasks. ntfy also supports message caching, allowing clients to retrieve recent messages they may have missed while disconnected. References: ntfy Publishing Messages ntfy Subscribing to Topics 3. Why Self-Host ntfy? The public ntfy.sh service is useful for testing and general notification delivery. However, running your own instance gives you more control over how the service operates. For example, you can configure authentication, define topic permissions, maintain your own notification storage, and integrate the service with your existing infrastructure. You can also choose whether the service should be accessible publicly or only through a private network or VPN. Self-hosting is particularly useful when integrating ntfy with internal infrastructure. Some examples include: Monitoring Linux server health. Receiving database backup notifications. Tracking application deployment results. Receiving alerts from scheduled scripts. Sending messages from monitoring systems. Notifying administrators about failed services. Important: Self-hosting does not automatically provide end-to-end encryption. Configure HTTPS, access controls, storage permissions, and appropriate message content to protect notification data. Reference: ntfy Server Configuration 4. What We Will Build For this tutorial, we will deploy ntfy using the following architecture. Mobile devices and web browsers communicate with ntfy through the HTTPS endpoint provided by Nginx. Docker will publish ntfy only on the Linux host’s loopback interface. This prevents users from directly accessing the published container port through the server’s public IP address under normal host networking conditions. We will use the following example configuration. Component Configuration Operating System Ubuntu 24.04 LTS Container Runtime Docker Engine Deployment Method Docker Compose Application ntfy Reverse Proxy Nginx HTTPS Certificate Let’s Encrypt Public Domain ntfy.example.com Local Port 127.0.0.1:8089 Container Port 80 Application Directory /opt/ntfy Authentication Enabled Anonymous Topic Access Denied Replace ntfy.example.com with a domain or subdomain that you control. 5. System Requirements Before starting, prepare a Linux server with the following: Ubuntu 24.04 LTS or another compatible Linux distribution. Docker Engine and the Docker Compose plugin. Administrative or sudo access. An available TCP port for the local ntfy service. A domain name pointing to your server if you intend to enable public HTTPS. Nginx and a valid TLS certificate for internet access. For a small personal installation, ntfy does not require a dedicated high-performance server. A small virtual machine may be sufficient, depending on message volume, connected clients, retention settings, and attachments. This tutorial assumes Docker is already installed. If Docker is not yet available, follow the official installation instructions: Docker Engine Installation on Ubuntu Verify Docker Run: docker --version Example output: Docker version 28.x.x Verify Docker Compose: docker compose version Example: Docker Compose version v2.x.x Check whether the Docker daemon is running: sudo systemctl status docker If necessary: sudo systemctl enable --now docker PinoyLinux Tip: We will use docker compose, which is the Docker Compose plugin command, rather than the older standalone docker-compose executable. Reference: Docker Compose Documentation 6. Prepare the ntfy Application Directory We will store the application configuration and persistent data under /opt/ntfy. Create the directories: sudo mkdir -p /opt/ntfy/config sudo mkdir -p /opt/ntfy/cache Move into the application directory: cd /opt/ntfy Our directory structure will look like this: /opt/ntfy/ ├── compose.yaml ├── config/ │ └── server.yml └── cache/ ├── cache.db ├── auth.db └── attachments/ The database files will be created by ntfy when the service starts and authentication is configured. Storing configuration and data outside the container allows us to recreate or update the container without automatically discarding those files. The official Docker installation documentation recommends mounting persistent storage for the message cache and a configuration directory for server.yml. Reference: ntfy Installation Documentation 7. Create the ntfy Server Configuration The ntfy Docker image does not provide a default /etc/ntfy/server.yml file. We must create it ourselves if we want to manage the service using a configuration file. Open: sudo nano /opt/ntfy/config/server.yml Add the following configuration: # Public URL base-url: "https://ntfy.example.com" # Container HTTP listener listen-http: ":80" # Persistent message cache cache-file: "/var/cache/ntfy/cache.db" # Authentication database auth-file: "/var/cache/ntfy/auth.db" # Deny anonymous topic access auth-default-access: "deny-all" # Enable login in the web application enable-login: true # Reverse proxy support behind-proxy: true # Attachment storage attachment-cache-dir: "/var/cache/ntfy/attachments" # Logging log-level: "info" Save the file. Replace the example domain with your actual notification server hostname. Understanding the Configuration Setting Purpose base-url Public address of your ntfy instance. listen-http Internal HTTP listener used by the container. cache-file Location of the persistent message cache. auth-file Database containing users, permissions, and tokens. auth-default-access Default permission when no matching access rule exists. enable-login Enables the web application’s login functionality. behind-proxy Enables reverse proxy awareness, including forwarded client IP handling. attachment-cache-dir Directory used to store message attachments. log-level Controls application logging verbosity. Why Use deny-all? By default, ntfy can allow anonymous users to publish and subscribe to topics. For a private notification service, we should configure access explicitly. Setting: auth-default-access: "deny-all" prevents anonymous users from accessing topics unless permissions are granted. We will create users and assign permissions after the container starts. References: ntfy Server Configuration ntfy Access Control 8. Create the Docker Compose Configuration Now create the Compose file. sudo nano /opt/ntfy/compose.yaml Add: services: ntfy: image: binwiederhier/ntfy:latest container_name: ntfy restart: unless-stopped init: true command: - serve environment: TZ: Asia/Manila volumes: - ./config:/etc/ntfy:ro - ./cache:/var/cache/ntfy ports: - "127.0.0.1:8089:80" healthcheck: test: - CMD-SHELL - > wget -q --tries=1 http://localhost:80/v1/health -O - | grep -Eq '"healthy"[[:space:]]*:[[:space:]]*true' || exit 1 interval: 60s timeout: 10s retries: 3 start_period: 40s This follows ntfy’s documented Docker deployment approach, including persistent volumes and a health check. ntfy Important Notes Image version We use latest for simplicity in this tutorial. For production environments, consider pinning the container to a tested version or immutable image digest. Persistent volumes The configuration preserves: /etc/ntfy /var/cache/ntfy The configuration mount is read-only because the server only needs to read server.yml. The cache directory remains writable because ntfy must create and update its databases and attachment files. Port binding This configuration: ports: - "127.0.0.1:8089:80" binds port 8089 to the host’s loopback interface. It does not intentionally expose port 8089 on the server’s public interfaces. Health check The health check periodically requests: http://localhost:80/v1/health A healthy response indicates that the ntfy HTTP service is responding. However, container health does not guarantee that public HTTPS, authentication, DNS, and mobile notification delivery are functioning correctly. Reference: ntfy Docker Installation and Health Checks 9. Start the ntfy Container First, validate the Compose file. cd /opt/ntfy sudo docker compose config If the configuration is valid, start the container: sudo docker compose up -d Inspect the container: sudo docker compose ps Example: NAME IMAGE STATUS ntfy binwiederhier/ntfy:latest Up (healthy) The exact output depends on your Docker version and container state. Check the application logs: sudo docker compose logs -f ntfy Press Ctrl + C to stop following the logs. This does not stop the container. Test the Health Endpoint Run: curl -i http://127.0.0.1:8089/v1/health A healthy response should include: { "healthy": true } Inspect the published port: sudo ss -tulnp | grep 8089 The ntfy service should be reachable locally through: http://127.0.0.1:8089 Important: This is the local HTTP endpoint. HTTPS will be provided by Nginx later. Reference: ntfy Installation Documentation 10. Configure ntfy Authentication Our configuration denies anonymous topic access. We now need to create an administrator account and a dedicated account for automation. Create the Administrator Account Run: cd /opt/ntfy sudo docker compose exec ntfy \ ntfy user add --role=admin admin Follow the password prompts. The administrator can manage the notification server and access all topics. Use a strong password that is different from your Linux server’s administrative password. Create an Automation Account Instead of using administrator credentials inside monitoring and backup scripts, create a dedicated account. sudo docker compose exec ntfy \ ntfy user add backup-service This creates a regular user. We can now assign only the permissions required by that service. Grant Topic Permissions Allow the backup service to publish messages to the backup notification topic: sudo docker compose exec ntfy \ ntfy access backup-service server-backups write-only For system monitoring: sudo docker compose exec ntfy \ ntfy access backup-service server-alerts write-only The account can publish messages to those topics but cannot subscribe to them. The administrator can read and write to all topics. Verify the permissions: sudo docker compose exec ntfy \ ntfy access This approach allows us to separate notification publishing from administrative access. The ntfy documentation explains that administrator accounts have full topic access, while regular accounts can receive per-topic read and write permissions. ntfy Reference: ntfy Access Control 11. Generate an API Token Using passwords directly inside scripts is not a good practice. ntfy supports access tokens that can authenticate API requests. Create a token for the automation account: sudo docker compose exec ntfy \ ntfy token add --label="linux-automation" backup-service The command generates an access token. It will have a format similar to: tk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx Store the generated token securely. Important: ntfy access tokens inherit the account’s permissions. They are not independent, topic-scoped credentials. This is why we created a dedicated user with limited access. You can list existing tokens: sudo docker compose exec ntfy \ ntfy token list backup-service Reference: ntfy Access Tokens 12. Configure Nginx as a Reverse Proxy At this point, ntfy is working locally. However, we want to access it through: https://ntfy.example.com Nginx will accept incoming HTTPS requests and forward them to the ntfy container. Before continuing, make sure your domain points to the public IP address of the Linux server. Verify DNS resolution: dig +short ntfy.example.com Replace the example domain with your actual hostname. Install Nginx On Ubuntu: sudo apt update sudo apt install nginx Enable the service: sudo systemctl enable --now nginx If UFW is enabled, allow HTTP and HTTPS: sudo ufw allow 80/tcp sudo ufw allow 443/tcp Do not enable or modify a firewall remotely without confirming that SSH access is permitted. Create the Nginx Configuration Create: sudo nano /etc/nginx/sites-available/ntfy Add the initial HTTP configuration: server { listen 80; server_name ntfy.example.com; location / { proxy_pass http://127.0.0.1:8089; proxy_http_version 1.1; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_buffering off; proxy_request_buffering off; proxy_read_timeout 300s; proxy_send_timeout 300s; } } Replace the example domain. Enable the site: sudo ln -s \ /etc/nginx/sites-available/ntfy \ /etc/nginx/sites-enabled/ntfy Test the configuration: sudo nginx -t If the test succeeds: sudo systemctl reload nginx Why disable proxy buffering? ntfy supports streaming subscriptions. Disabling response buffering allows notifications to be forwarded to connected clients without waiting for Nginx to accumulate response data. The WebSocket-related headers also allow compatible clients to establish upgraded connections. The official ntfy reverse proxy documentation recommends enabling behind-proxy and forwarding the appropriate connection headers. ntfy References: ntfy Reverse Proxy Configuration Nginx HTTP Proxy Module 13. Enable HTTPS With Let’s Encrypt We now need a valid TLS certificate. For this tutorial, we will use Certbot. Install Certbot and its Nginx plugin: sudo apt install certbot python3-certbot-nginx Request a certificate: sudo certbot --nginx -d ntfy.example.com Follow the prompts. Certbot should configure the certificate and can configure HTTP-to-HTTPS redirection. Before requesting the certificate, ensure that: Your domain resolves to the correct server. Port 80 is reachable from the internet. Your Nginx configuration passes validation. No conflicting virtual host is intercepting the domain. After installation, verify: curl -I https://ntfy.example.com You can also inspect the certificate: openssl s_client \ -connect ntfy.example.com:443 \ -servername ntfy.example.com Test certificate renewal: sudo certbot renew --dry-run Your notification server should now be accessible through HTTPS. PinoyLinux Security Reminder: Do not use curl -k to bypass certificate verification as a permanent solution to TLS errors. Fix the certificate or trust configuration instead. References: Certbot Official Website Let’s Encrypt Documentation 14. Test Your Self-Hosted Notification Server We can now publish our first notification. Before proceeding, open the ntfy web interface: https://ntfy.example.com Log in using the administrator account created earlier. Subscribe to the following topic: server-backups The web interface can now receive notifications published to that topic. Publish a Message Using an API Token Set the automation token in your terminal. read -rsp "ntfy API token: " NTFY_TOKEN echo Press Enter after entering the token. Publish a message: curl --fail-with-body -sS \ -H "Authorization: Bearer ${NTFY_TOKEN}" \ -H "Title: PinoyLinux Test" \ -H "Priority: default" \ -d "Hello from our self-hosted ntfy server!" \ https://ntfy.example.com/server-backups If authentication and topic permissions are configured correctly, the message should appear in your subscribed topic. Notice that the destination is our self-hosted server: https://ntfy.example.com/server-backups We are no longer publishing to the public ntfy.sh service. Reference: ntfy Publishing Messages 15. Configure ntfy on Your Smartphone Now that the server is accessible through HTTPS, connect your mobile device. ntfy provides mobile applications for Android and iOS. You can find the official installation options through: https://ntfy.sh/ Install the application and configure your self-hosted server. Use: https://ntfy.example.com Subscribe to: server-backups Authenticate with an account that has permission to read the topic. For this tutorial, your administrator account has that access. You can then publish another test message from your Linux terminal. curl --fail-with-body -sS \ -H "Authorization: Bearer ${NTFY_TOKEN}" \ -H "Title: Linux Notification Test" \ -H "Tags: computer" \ -d "Our ntfy server is working!" \ https://ntfy.example.com/server-backups If your device is configured correctly, the notification should appear. Important Note for iOS Users Self-hosted ntfy installations may require additional configuration for reliable instant notifications on iOS. The official ntfy documentation describes an upstream notification mechanism that can be configured using: upstream-base-url: "https://ntfy.sh" Add this setting to server.yml if you intend to use the documented upstream method for iOS instant notifications. Restart the container after changing the configuration: cd /opt/ntfy sudo docker compose restart ntfy Ensure that the configured base-url matches the server URL used by the iOS application. Review the privacy implications of using an upstream notification service before enabling it. Reference: ntfy Known Issues, iOS Notifications 16. Practical Example: Linux Disk Usage Notifications Now that ntfy is working, let us create a real Linux administration example. We want to receive a notification when the root file system reaches 85% usage. This can help identify storage problems before they affect applications. Store the Notification Token For automation, create a protected environment file. sudo nano /etc/ntfy-monitor.env Add: NTFY_URL="https://ntfy.example.com" NTFY_TOKEN="REPLACE_WITH_YOUR_TOKEN" NTFY_TOPIC="server-alerts" Protect the file: sudo chown root:root /etc/ntfy-monitor.env sudo chmod 600 /etc/ntfy-monitor.env Do not commit this file to Git or publish it in your documentation. Create the Disk Monitoring Script Create: sudo nano /usr/local/bin/ntfy-disk-monitor.sh Add: #!/usr/bin/env bash set -euo pipefail source /etc/ntfy-monitor.env THRESHOLD=85 HOSTNAME=$(hostname) USAGE=$(df -P / | awk 'NR==2 { gsub("%", "", $5); print $5 }') if [ "$USAGE" -ge "$THRESHOLD" ]; then MESSAGE="Disk usage on ${HOSTNAME} reached ${USAGE}%." curl --fail-with-body -sS \ --retry 3 \ -H "Authorization: Bearer ${NTFY_TOKEN}" \ -H "Title: Linux Disk Space Alert" \ -H "Priority: high" \ -H "Tags: warning" \ -d "$MESSAGE" \ "${NTFY_URL}/${NTFY_TOPIC}" fi Save the file. Make it executable: sudo chown root:root /usr/local/bin/ntfy-disk-monitor.sh sudo chmod 750 /usr/local/bin/ntfy-disk-monitor.sh Run the script: sudo /usr/local/bin/ntfy-disk-monitor.sh If usage is below 85%, no notification is sent. If it reaches or exceeds the threshold, ntfy publishes an alert. For a safe test, temporarily lower the threshold in your lab environment. For example: THRESHOLD=1 Run the script, confirm that the notification arrives, and restore the intended threshold. Schedule the Script You can execute the script periodically through cron. Open root’s crontab: sudo crontab -e Add: */5 * * * * /usr/local/bin/ntfy-disk-monitor.sh This checks disk usage every five minutes. Production Note: This basic example sends another alert on every check while the threshold remains exceeded. For production monitoring, consider adding alert state tracking, recovery notifications, and notification suppression to prevent repeated messages. References: ntfy Message Publishing GNU Coreutils, df 17. Practical Example: Backup Success and Failure Notifications One of the most useful applications of ntfy is scheduled backup monitoring. Imagine a Linux server running a daily backup. You want to know whether the operation succeeded or failed without manually inspecting the backup directory every morning. Here is a simplified example. Create the script: sudo nano /usr/local/bin/ntfy-backup.sh Add: #!/usr/bin/env bash set -euo pipefail source /etc/ntfy-monitor.env BACKUP_SOURCE="/etc" BACKUP_DIR="/var/backups/pinoylinux" HOSTNAME=$(hostname) DATE=$(date +%F-%H%M%S) mkdir -p "$BACKUP_DIR" BACKUP_FILE="${BACKUP_DIR}/etc-${DATE}.tar.gz" if tar -czf "$BACKUP_FILE" \ -C / etc; then MESSAGE="Backup completed successfully on ${HOSTNAME}." PRIORITY="low" TITLE="Backup Completed" TAGS="white_check_mark" BACKUP_STATUS=0 else MESSAGE="Backup failed on ${HOSTNAME}." PRIORITY="high" TITLE="Backup Failed" TAGS="warning" BACKUP_STATUS=1 fi if ! curl --fail-with-body -sS \ --retry 3 \ -H "Authorization: Bearer ${NTFY_TOKEN}" \ -H "Title: ${TITLE}" \ -H "Priority: ${PRIORITY}" \ -H "Tags: ${TAGS}" \ -d "$MESSAGE" \ "${NTFY_URL}/server-backups"; then echo "Failed to deliver backup notification." >&2 fi exit "$BACKUP_STATUS" Make it executable: sudo chown root:root /usr/local/bin/ntfy-backup.sh sudo chmod 750 /usr/local/bin/ntfy-backup.sh Run: sudo /usr/local/bin/ntfy-backup.sh The script reports whether the archive command succeeded or failed. For a real production backup, additional checks are required. For example: Verify the created archive. Ensure sufficient storage is available. Transfer backups to another storage location. Periodically test restoration. Protect backups containing configuration files and credentials. A successful archive command alone does not guarantee that your complete backup and recovery procedure is reliable. Also ensure that the service account used by the script has permission to publish to server-backups. References: ntfy Publishing Messages GNU tar Documentation 18. Troubleshooting Common ntfy Problems Here are several problems you may encounter during installation. Problem Possible Cause What to Check Container does not start Invalid configuration or storage permission issue docker compose logs Port 8089 is unavailable Another application is using the port ss -tulnp Nginx returns 502 ntfy is stopped or proxy destination is incorrect Docker status and Nginx logs HTTP 401 Authentication is missing or invalid Credentials and API token HTTP 403 User lacks topic permissions ntfy access rules Notifications arrive late Mobile connectivity or push configuration Mobile settings and ntfy configuration HTTPS fails DNS, certificate, or Nginx problem Certbot and TLS configuration Messages disappear Persistent cache is missing or retention has expired Cache settings and mounted volumes Check Container Logs cd /opt/ntfy sudo docker compose logs --tail=100 ntfy Check Container Health sudo docker inspect \ --format '{{json .State.Health}}' \ ntfy Check Nginx Logs sudo tail -n 100 /var/log/nginx/error.log Check the Local Service curl -i http://127.0.0.1:8089/v1/health Check the Public Endpoint curl -i https://ntfy.example.com/v1/health If the local endpoint works but the public endpoint fails, investigate Nginx, DNS, TLS, and network access before modifying the container. References: ntfy Known Issues ntfy Server Configuration Docker Container Logs 19. Updating Your ntfy Container Keeping the application updated helps you receive software fixes and security updates. Before updating, back up your configuration and persistent data. Review the ntfy release notes: https://docs.ntfy.sh/releases/ When you are ready to update, move into the application directory: cd /opt/ntfy Pull the configured image: sudo docker compose pull ntfy Recreate the container using the updated image: sudo docker compose up -d Check its status: sudo docker compose ps Inspect logs: sudo docker compose logs --tail=100 ntfy Test the health endpoint: curl -i https://ntfy.example.com/v1/health Finally, publish and receive a test notification. For production systems, use a tested image version rather than relying on an uncontrolled update to latest. References: ntfy Release Notes Docker Compose Pull Docker Compose Up 20. Backing Up Your ntfy Installation Our ntfy installation stores its application configuration and data under: /opt/ntfy Important files include: /opt/ntfy/compose.yaml /opt/ntfy/config/server.yml /opt/ntfy/cache/cache.db /opt/ntfy/cache/auth.db Attachments are also stored under the cache directory when enabled. To create a consistent filesystem backup, stop ntfy before copying its active SQLite databases. cd /opt/ntfy sudo docker compose stop ntfy Create a backup directory: sudo mkdir -p /var/backups/ntfy Archive the application directory: sudo tar -czf \ "/var/backups/ntfy/ntfy-$(date +%F-%H%M%S).tar.gz" \ -C /opt \ ntfy Start the service again: sudo docker compose up -d Check its health and publish a test notification. This method involves a short service interruption. For installations requiring continuous availability, use a backup procedure that safely handles active SQLite databases. PinoyLinux Tip: Store a copy of your ntfy backup outside the server. If the server’s storage fails, backups located only on that same storage device may be lost. Treat the authentication database and configuration as sensitive backup data. References: ntfy Server Configuration SQLite Backup Documentation 21. Uninstalling ntfy If you no longer need the installation, you can remove the container. Move into the application directory: cd /opt/ntfy Stop and remove the Compose-managed container: sudo docker compose down This removes the container and its Compose-managed network, but leaves the bind-mounted application files in place. If you also want to remove the image: sudo docker image rm binwiederhier/ntfy:latest Docker may refuse image removal if another container still uses it. If you want to remove the Nginx configuration, disable the site and remove its configuration file after confirming that no other application uses it. Do not delete /opt/ntfy until you have confirmed that its configuration, databases, and backups are no longer needed. Reference: Docker Compose Down Final Thoughts ntfy provides a practical way to add push notifications to Linux administration and application workflows. With Docker Compose, you can deploy the service, preserve its data, manage authentication, and connect it to existing applications without developing a separate notification platform. In this tutorial, we installed ntfy, configured persistent storage, created users and API tokens, enabled HTTPS through Nginx, and demonstrated how to publish notifications from Linux scripts. These examples are only the beginning. You can integrate ntfy with backup systems, monitoring applications, website deployment pipelines, scheduled maintenance tasks, and other infrastructure services. For a Linux administrator, receiving an alert at the right time can make troubleshooting easier and help identify problems before they develop into larger service interruptions. Have you built a self-hosted notification system for your Linux infrastructure? Share your experience and configuration ideas with the PinoyLinux community. Visit PinoyLinux.org for more Linux, Docker, and open-source tutorials. References and Further Reading The installation procedures, configuration examples, and technical explanations in this article are based on official project documentation and practical Linux administration techniques. The following resources provide additional information for readers who want to explore ntfy or adapt the deployment to their environment. ntfy Documentation 1. ntfy Official Website https://ntfy.sh/ Introduces ntfy, its notification capabilities, and supported platforms. 2. ntfy Installation Documentation https://docs.ntfy.sh/install/ Explains installation methods, Docker deployment, Docker Compose, persistent volumes, and health checks. 3. ntfy Server Configuration https://docs.ntfy.sh/config/ Documents server configuration options, authentication, access control, message caching, reverse proxies, and attachment storage. 4. ntfy Publishing Messages https://docs.ntfy.sh/publish/ Explains how to send notifications using HTTP requests, message titles, priorities, tags, and authentication. 5. ntfy Subscribing to Topics https://docs.ntfy.sh/subscribe/ Documents subscription methods and message retrieval. 6. ntfy Known Issues https://docs.ntfy.sh/known-issues/ Provides information about known problems, including mobile notification delivery. 7. ntfy Release Notes https://docs.ntfy.sh/releases/ Documents software releases, changes, and fixes. 8. ntfy GitHub Repository https://github.com/binwiederhier/ntfy Contains the official source code, issue tracker, and release history. Docker Documentation 9. Docker Engine Installation on Ubuntu https://docs.docker.com/engine/install/ubuntu/ Provides installation instructions for Docker Engine on Ubuntu. 10. Docker Compose Documentation https://docs.docker.com/compose/ Explains Docker Compose services, volumes, networks, and container management. Web Server and HTTPS Documentation 11. Nginx HTTP Proxy Module https://nginx.org/en/docs/http/ngx_http_proxy_module.html Documents Nginx directives used to configure reverse proxy connections. 12. Certbot https://certbot.eff.org/ Provides information about obtaining and renewing TLS certificates. 13. Let’s Encrypt Documentation https://letsencrypt.org/docs/ Explains certificate issuance and related HTTPS concepts. Linux and Backup Documentation 14. GNU Coreutils Documentation https://www.gnu.org/software/coreutils/manual/ Provides documentation for common Linux utilities. 15. GNU tar Manual https://www.gnu.org/software/tar/manual/ Explains archive creation, extraction, and file backup operations. 16. SQLite Online Backup API https://www.sqlite.org/backup.html Documents methods for backing up SQLite databases while maintaining consistency.