blumeops/docs/reference/services/ntfy.md
Erich Blume 813ce2ddaf Recurring review sweep: 4 doc cards + nvidia-device-plugin v0.19.2
Doc review (last-reviewed 2026-06-04):
- cluster.md: k8s v1.34.0→v1.35.0; ringtail workload list updated for
  the in-progress minikube→k3s migration
- ntfy/tempo/alloy: images are now locally-built registry.ops.eblu.me
  nix containers (v2.19.2 / v2.10.3 / v1.16.0); Fly alloy binary v1.16.1

Service review:
- nvidia-device-plugin v0.19.0→v0.19.2 (upstream patch, no breaking
  changes for our CDI + RuntimeClass manifests)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-04 13:23:03 -07:00

64 lines
2 KiB
Markdown

---
title: Ntfy
modified: 2026-06-04
last-reviewed: 2026-06-04
tags:
- service
- notifications
---
# Ntfy
Self-hosted push notification service. Ntfy receives HTTP POST messages and delivers them to subscribed clients (mobile apps, web UI, CLI).
## Quick Reference
| Property | Value |
|----------|-------|
| **URL** | https://ntfy.ops.eblu.me |
| **Tailscale URL** | https://ntfy.tail8d86e.ts.net |
| **Namespace** | `ntfy` |
| **Image** | `registry.ops.eblu.me/blumeops/ntfy:v2.19.2-fd0bebb-nix` (locally built) |
| **Upstream** | https://github.com/binwiederhier/ntfy |
| **Manifests** | `argocd/manifests/ntfy/` |
## Architecture
Ntfy runs as a single pod with no persistent storage — message cache and attachments use an `emptyDir` volume. This is intentional: ntfy is treated as an ephemeral delivery channel, not a message store. Messages lost on pod restart are acceptable.
The upstream relay (`ntfy.sh`) is configured so mobile app clients can receive push notifications via Google FCM / Apple APNs without self-hosting those integrations.
## Producers
Currently the only producer is **frigate-notify**, which polls Frigate's webapi for camera detection alerts (person, vehicle, animal) and forwards them to ntfy:
```
Frigate → frigate-notify (webapi polling) → ntfy → mobile clients
```
The frigate-notify config points to ntfy's cluster-internal address:
```
http://ntfy.ntfy.svc.cluster.local:80
```
Other services could publish to ntfy in the future — any HTTP client can POST to a topic.
## Configuration
Server config is in a ConfigMap (`ntfy-config`):
| Setting | Value |
|---------|-------|
| `base-url` | `https://ntfy.ops.eblu.me` |
| `upstream-base-url` | `https://ntfy.sh` |
| `attachment-total-size-limit` | 1 GB |
| `attachment-file-size-limit` | 10 MB |
| `attachment-expiry-duration` | 24h |
No authentication is configured — access is restricted by Tailscale ACLs (only tailnet clients can reach the service).
## Related
- [[routing]] - How ntfy is exposed via Caddy
- [[observability]] - Monitoring and alerting infrastructure