blip zip blog

At the moment, all my notifications (from my monitoring stack, and SSH login notifications) are sent via email, which is handled by a Power Automate notification. This works well enough, but I like the idea of handling everything in-house.

ntfy.sh looks like a really solid option. I've done the most basic of basic setups (installed via their package manager) on my production server and exposed it on this domain via my existing nginx reverse proxy. I haven't done enough reading to understand what the default config exposes from an administrative perspective, so for now I've added an IP allowlist to only permit traffic from my home IP.

There's a whole bunch of other config options to sort out, but right now, it looks like this:

nginx

server {
	server_name ntfy.blip.zip;
	allow ;
	deny all;
	location / {
		proxy_pass http://192.168.115.2:8081;
		proxy_set_header Host \$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;
	}
	location = /robots.txt { return 200 "User-agent: *\nDisallow: /\n"; }
}

nfty

# ntfy server config file
# Please refer to the documentation at https://ntfy.sh/docs/config/ for details.
base-url: "https://ntfy.blip.zip"

listen-http: ":8081"

# Debian/RPM package users:
#   Use /var/cache/ntfy/cache.db as cache file to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this cache file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
cache-file: "/var/cache/ntfy/cache.db"

# If set, access to the ntfy server and API can be controlled on a granular level using
# the 'ntfy user' and 'ntfy access' commands. See the --help pages for details, or check the docs.
#
# - auth-file is the SQLite user/access database; it is created automatically if it doesn't already exist
# - auth-default-access defines the default/fallback access if no access control entry is found; it can be
#   set to "read-write" (default), "read-only", "write-only" or "deny-all".
# - auth-startup-queries allows you to run commands when the database is initialized, e.g. to enable
#   WAL mode. This is similar to cache-startup-queries. See above for details.
#
# Debian/RPM package users:
#   Use /var/lib/ntfy/user.db as user database to avoid permission issues. The package
#   creates this folder for you.
#
# Check your permissions:
#   If you are running ntfy with systemd, make sure this user database file is owned by the
#   ntfy user and group by running: chown ntfy.ntfy <filename>.
#
auth-file: "/var/lib/ntfy/user.db"
auth-default-access: "read-write"
# auth-startup-queries:

# If set, the X-Forwarded-For header is used to determine the visitor IP address
# instead of the remote address of the connection.
#
# WARNING: If you are behind a proxy, you must set this, otherwise all visitors are rate limited
#          as if they are one.
#
behind-proxy: true
enable-metrics: false
metrics-listen-http: ":9101"