ntfy 2.32.0 介绍与选型指南

ntfy v2.32.0 联网溯源认知与选型：HTTP PUT/POST 到手机/桌面推送的 topic 制自托管通知服务，覆盖双端开源 App、UnifiedPush、邮件发布、附件与 ACL 能力面及同类量化对比，全部标注来源与查询日期 2026-10-21。

ntfyntfy即时通信2026/10/21

ntfy 2.32.0 介绍与选型指南

目标：面向正在评估「自托管推送通知服务端」的技术团队，系统介绍 ntfy 的定位、topic 制架构、功能特性、版本演进与同类横向对比，帮助完成「选不选它」的判断。本篇为认知与选型篇，全部信息基于官方公开资料联网溯源整理，关键数据均标注来源与查询日期（2026-10-21），不含本地实测环节。

一、环境信息

本章说明本篇溯源所用的信息源与版本认定依据，后续章节的事实均以此为基准。

  • 溯源方式：纯联网溯源（官方文档站 docs.ntfy.sh、GitHub binwiederhier/ntfy 仓库 Releases Atom 流、shields.io 徽章数据、官方 apt 仓库 archive.ntfy.sh 包索引），未包含任何本地实测环节；
  • 版本认定日期：2026-10-21；
  • ntfy 最新稳定版本：v2.32.0（Release 更新时间 2026-10-18）；
  • 版本认定依据（双源交叉）：
    • 来源一：GitHub binwiederhier/ntfy 仓库 Releases Atom 流（https://github.com/binwiederhier/ntfy/releases.atom），最新 entry 标题 v2.32.0，updated 时间 2026-10-18T13:57:25Z（查询日期 2026-10-21）；
    • 来源二：GitHub binwiederhier/ntfy releases/latest 访问重定向（https://github.com/binwiederhier/ntfy/releases/latest → .../releases/tag/v2.32.0，查询日期 2026-10-21）；
  • 官方 apt 仓库交叉验证：官方 Debian/Ubuntu 仓库 https://archive.ntfy.sh/apt（stable/main）中 ntfy 候选版本为 2.32.0，且可回溯安装 2.11.0 至 2.32.0 之间的全部历史版本（来源：apt-cache policy ntfy 对该仓库包索引的输出，查询日期 2026-10-21）；
  • 仓库地址说明：官方仓库为 binwiederhier/ntfy（docs.ntfy.sh 各页面与 GitHub Releases Atom 流均指向该仓库，查询日期 2026-10-21）。网络上流传的 ntfy-sh/ntfy、ntfy-org/ntfy 均为归一化别名，并不存在对应 GitHub 仓库；
  • 社区规模：GitHub 星数 35k（来源：shields.io 徽章接口 https://img.shields.io/github/stars/binwiederhier/ntfy.json 返回 "message":"35k"，查询日期 2026-10-21）；
  • 许可证：双许可（Apache License 2.0 与 GPLv2）——仓库根 LICENSE 文件正文为 Apache License 2.0（来源：https://raw.githubusercontent.com/binwiederhier/ntfy/main/LICENSE，查询日期 2026-10-21）；官方发布二进制的自述输出为「Copyright (C) Philipp C. Heckel, licensed under Apache License 2.0 & GPLv2」（来源：ntfy v2.32.0 官方 Linux 二进制 ntfy --version 版权行，2026-10-21 核对）；
  • 项目作者：Philipp C. Heckel（GitHub 账号 binwiederhier），ntfy.sh 公共服务与 ntfy Pro 订阅亦由其运营（来源：docs.ntfy.sh 站点页眉赞助信息，查询日期 2026-10-21）。

二、软件概述

本节给出 ntfy 的一句话定位与项目身份信息，回答「它是什么、谁在维护、以什么形式分发」。

ntfy 是一个用 Go 编写的、以单二进制形式分发的自托管 HTTP 发布/订阅（pub-sub）推送通知服务：任何能发 HTTP PUT/POST 的程序（curl、脚本、CI 任务、IoT 设备、自动化工具）向 <服务器>/<主题名> 发一条请求，消息即被推送到订阅了该主题的手机 App、桌面端、Web 页面或命令行。它解决的核心痛点是——把「往手机上弹一条通知」这件事简化为一次 HTTP 请求，同时数据完全自持：你可以完全脱离第三方 SaaS 推送服务运行。

与「注册应用拿令牌」的传统推送模型不同，ntfy 以 topic（主题）为中心：不需要注册、不需要创建应用实体，知道主题名就能发、订阅了主题就能收（配合可选的 ACL 访问控制可收紧）。官方对它的自我描述是「Send push notifications to your phone or desktop using PUT/POST」（来源：docs.ntfy.sh 首页，2026-10-21）。

关键身份信息汇总（均标注来源与查询日期）：

维度事实来源
项目名ntfy（官方口号「Send push notifications via PUT/POST」）docs.ntfy.sh，2026-10-21
官方仓库github.com/binwiederhier/ntfyReleases Atom 流，2026-10-21
实现语言Go（静态编译单二进制，官方声明 statically linked）docs.ntfy.sh/docs/install，2026-10-21
许可证Apache License 2.0 & GPLv2 双许可仓库 LICENSE + 官方二进制版权行，2026-10-21
最新稳定版v2.32.0（2026-10-18）Releases Atom 流，2026-10-21
官方分发形态tarball、deb/rpm 包、官方 Debian/Ubuntu apt 仓库、Docker 镜像、Windows/macOS 二进制、Homebrewdocs.ntfy.sh/docs/install，2026-10-21
支持架构amd64、armv6、armv7/armhf、arm64docs.ntfy.sh/docs/install，2026-10-21
官方客户端Android App（Google Play / F-Droid / GitHub APK）、iOS App（App Store）、Web App（服务端内嵌）、CLI、桌面端docs.ntfy.sh/docs/subscribe/phone 等，2026-10-21
存储消息缓存 SQLite（默认可关闭）或 PostgreSQL（database-url，2.32 版配置文件注释明示）；用户库 SQLite（auth-file）docs.ntfy.sh/docs/config，2026-10-21
部署形态单机服务（集群为 2.32 实验性特性，依赖 PostgreSQL 共享库）docs.ntfy.sh/docs/config，2026-10-21
公共托管服务ntfy.sh（免费限流层 + ntfy Pro 付费层）ntfy.sh，2026-10-21

💡 说明：ntfy 既是一个「可自托管的服务端软件」，也运营着一个「免费公共服务 ntfy.sh」。评估自托管时，二者能力同源（服务端同一套代码），但公共服务的限流、配额与付费层策略不适用于自建实例；本篇聚焦自托管视角。

三、核心架构

本节从进程形态、数据模型与通信通道三个层面拆解 ntfy 的架构，帮助理解它的能力边界。

3.1 进程形态：单二进制双角色（CLI 即客户端 + 服务端）

ntfy 的全部能力收敛在一个静态编译的 Go 二进制里，且这一个二进制同时承担两个角色（来源：docs.ntfy.sh/docs/install「The ntfy CLI allows you to publish messages, subscribe to topics as well as to self-host your own ntfy server」，2026-10-21）：

  • 客户端角色：ntfy publish（发消息）、ntfy subscribe（订阅主题）——不需要本地运行服务端即可对任意 ntfy 服务器（含公共服务 ntfy.sh）收发；
  • 服务端角色：ntfy serve——启动 HTTP 服务，提供发布 API、订阅流、内嵌 Web App 与附件服务。

Web App（管理/收信界面）以静态资源形式内嵌在二进制中，由 web-root 配置控制根路径或整体禁用（来源：docs.ntfy.sh/docs/config web-root 节，2026-10-21）。服务端同时通过 systemd 单元（deb/rpm 包自带 ntfy.service 与用户级 ntfy-client.service）托管（来源：docs.ntfy.sh/docs/install，2026-10-21）。

3.2 数据模型：topic 中心制 + 可选持久化

ntfy 的数据模型以 topic 为唯一组织单元，这是它与「application/client 模型」推送服务（如 Gotify）最本质的差异：

概念含义说明
topic主题，即消息频道命名即创建：向 mytopic 发消息它就存在；默认无鉴权（auth-default-access 默认 read-write），可切换 deny-all 并用 ACL 收紧
message一条通知含 title、message、priority(1-5)、tags、附件元数据等字段；进入缓存供 since=/poll=1 回放
attachment附件随消息上传，存于 attachment-cache-dir（本地目录或 S3 对象存储），带过期时间与配额
user / token / ACL可选的用户与访问控制auth-file SQLite 库存用户、访问令牌与每主题授权；token 形如 tk_...
tier服务等级（多租户配额）面向 ntfy.sh Pro 的按用户配额体系（消息量、附件空间、保留期等），自托管亦可配置

持久化链路：消息默认仅在内存中缓冲（重启即失）；设置 cache-file 后落 SQLite，支持重启后 since= 回放；2.32 起可用 database-url 把消息缓存、用户库与 Web Push 订阅整体迁到 PostgreSQL（来源：docs.ntfy.sh/docs/config database-url/cache-file 节，2026-10-21）。

3.3 通信通道与认证

  • 发布（写）：HTTP PUT/POST https://<host>/<topic>（消息体即正文），可用 HTTP 头或查询参数携带 title、priority、tags、delay、click、icon、actions、email、cache、firebase 等指令（来源：docs.ntfy.sh/docs/publish，2026-10-21）；CLI ntfy publish 是同一 API 的封装；
  • 邮件入口：配置 smtp-server-listen 后，直接给 <topic>@<域名> 发邮件即可发布消息（来源：docs.ntfy.sh/docs/config smtp-server 节，2026-10-21）；
  • 订阅（读）：四条通道任选——JSON stream（/topic/json，一行一个 JSON）、SSE（/topic/sse）、WebSocket（/topic/ws）、轮询（/topic/json?poll=1&since=...）（来源：docs.ntfy.sh/docs/subscribe/api，2026-10-21）；
  • 手机推送：Android App 自托管场景用「即时投递（foreground service 长连接）」或可选 FCM（firebase-key-file）；iOS 因系统后台限制，自托管服务器需设置 upstream-base-url: https://ntfy.sh，由官方服务器经 APNS 发「轮询请求」唤醒 App 回源拉取（来源：docs.ntfy.sh/docs/config upstream-base-url 节「If you use the iOS ntfy app, you MUST configure this to receive timely notifications」，2026-10-21）；
  • Web Push：配置 VAPID 密钥（ntfy webpush keys 生成）后，浏览器 Web App 关闭时也能收推送（来源：docs.ntfy.sh/docs/config web-push 节，2026-10-21）；
  • 认证方式：HTTP Basic（用户名+密码）与 Bearer token（tk_ 前缀访问令牌）两种，粒度到「用户 × 主题模式 × 读写」（来源：docs.ntfy.sh/docs/publish authentication 节，2026-10-21）；
  • UnifiedPush：ntfy 是 UnifiedPush 分发协议的主要服务端实现之一，up* 前缀主题承担 UnifiedPush 应用推送（来源：docs.ntfy.sh/docs/config visitor-subscriber-rate-limiting 节与 docs.ntfy.sh/publish UnifiedPush 相关内容，2026-10-21）。

💡 技术拓展：手机端「服务端如何触达设备」不止一条路，主流方案对比——

方案原理取舍
长连接（foreground service）App 常驻前台服务维持 TCP/WS无第三方依赖、省电差，Android 可行
厂商推送通道（FCM/APNS）系统级推送唤醒 App省电可靠，但依赖谷歌/苹果云，自托管需中转
UnifiedPush统一分发协议 + 可选分发器自由选择服务器与分发器，生态需 App 适配
Web Push（VAPID）浏览器订阅推送端点仅限浏览器场景

ntfy 四条全支持：Android 默认长连接+可选 FCM，iOS 走 APNS（经 ntfy.sh 中转轮询请求），任何 UnifiedPush 分发器可用，Web App 支持 Web Push；本文自托管场景推荐「Android 长连接 / iOS upstream」默认组合，无需额外配置 FCM。

四、功能特性

本节按「发布能力 → 客户端生态 → 安全模型 → 运维能力 → 版本演进」归纳 ntfy 的功能清单，每项均标注官方来源。

4.1 发布与消息能力

  • 消息字段：title（标题）、message（正文，支持 Markdown 渲染开关）、priority（1-5 五级：min/low/default/high/max）、tags（标签，自动映射 emoji shortcodes，如 warning、rotating_light）、click（点击跳转 URL）、icon（通知图标 URL）、actions（通知按钮，支持 view, http, broadcast 三类动作）（来源：docs.ntfy.sh/docs/publish，2026-10-21）；
  • 定时与延迟：Delay 头支持相对时长（30s、2h）与绝对时刻（8:30am、tue, 21:00），服务端缓存调度到期投递（来源：docs.ntfy.sh/docs/publish#delay，2026-10-21）；
  • 附件：X-Attach（外部 URL 引用）与 X-Filename + 请求体（直接上传），服务端落 attachment-cache-dir（本地目录或 S3），受每文件/总量配额与过期时间约束（来源：docs.ntfy.sh/docs/publish#attachments 与 docs/config attachment 节，2026-10-21）；
  • 邮件转发出口：X-Email 头把消息同时发成电子邮件（需配置 smtp-sender-*，支持 STARTTLS）（来源：docs.ntfy.sh/docs/config smtp-sender 节，2026-10-21）；
  • 电话外呼：X-Call 头经 Twilio 把消息转语音电话（需 twilio-* 配置）（来源：docs.ntfy.sh/docs/config twilio 节，2026-10-21）；
  • 消息模板：template-dir + X-Template 头，服务端用 Go 模板改写 title/message（如 Grafana 告警正文整形）（来源：docs.ntfy.sh/docs/config template-dir 节，2026-10-21）；
  • 消息尺寸：默认 4k 上限（message-size-limit），超限可配置但官方不建议（FCM/APNS 兼容性考虑）；若启用附件缓存，超限消息可自动转存为附件（来源：docs.ntfy.sh/docs/config message-size-limit 节，2026-10-21）；
  • 定时清理：cache-duration（默认 12h）到期消息从缓存清除；manager-interval 周期性整理（来源：docs.ntfy.sh/docs/config，2026-10-21）。

4.2 客户端生态

  • Android App：开源（binwiederhier/ntfy-android），分发渠道 Google Play、F-Droid、GitHub Releases APK（F-Droid 版不含 Firebase）；支持按优先级分通道通知、免打扰覆盖、即时投递、分享到主题、ntfy:// 链接、Tasker/MacroDict 等自动化集成（来源：docs.ntfy.sh/docs/subscribe/phone，2026-10-21）；
  • iOS App：开源（binwiederhier/ntfy-ios），App Store 分发；自托管服务器须配置 upstream-base-url 才能及时推送（见 3.3 节）（来源：docs.ntfy.sh/docs/subscribe/phone，2026-10-21）；
  • Web App / PWA：服务端内嵌，浏览器直接访问 https://<host>/ 使用，可添加到主屏幕作为 PWA（来源：docs.ntfy.sh/docs/subscribe/web，2026-10-21）；
  • 桌面端：Web App 之外的桌面订阅途径（来源：docs.ntfy.sh/docs/subscribe/desktop，2026-10-21）；
  • CLI：ntfy publish / ntfy subscribe（支持 --from-config 按配置文件常驻订阅、进程等待 --wait-cmd/--wait-pid 等）（来源：docs.ntfy.sh/docs/subscribe/cli 与 ntfy publish --help，2026-10-21）；
  • UnifiedPush：作为 UnifiedPush 网关服务端，任何适配 UnifiedPush 的应用（如 Tusky、Element Android 等）可选 ntfy 做推送通道（来源：docs.ntfy.sh/docs/subscribe/phone UnifiedPush 节，2026-10-21）。

4.3 安全与访问控制

  • ACL 访问控制：auth-file 开启后可用 ntfy user（用户管理）、ntfy access（按主题模式的读写授权）、ntfy token（访问令牌管理）三个服务端命令精细控制；auth-default-access 支持 read-write / read-only / write-only / deny-all（来源：docs.ntfy.sh/docs/config auth 节与 ntfy user --help，2026-10-21）；
  • 配置式用户注入：auth-users / auth-access / auth-tokens 可在 server.yml 中声明式预置用户、授权与令牌（来源：docs.ntfy.sh/docs/config，2026-10-21）；
  • 限流体系：按访客（IP）的多维限流——请求数、每日消息数、附件流量、订阅数、新主题创建速率、邮件数；支持前缀聚合（IPv4/IPv6 prefix bits）、代理头取真实 IP（behind-proxy）（来源：docs.ntfy.sh/docs/config rate limiting 节，2026-10-21）；
  • 防滥用联动：ban-file 把越权/超限的访客 IP 以固定格式追加到文件，供 fail2ban 直接封禁（来源：docs.ntfy.sh/docs/config ban-file 节，2026-10-21）；
  • TLS：listen-https + 证书文件内建 HTTPS 监听，亦可反代终结（来源：docs.ntfy.sh/docs/config，2026-10-21）。

4.4 运维与扩展

  • 可观测：enable-metrics 暴露 Prometheus 风格 /metrics；profile-listen-http 暴露 Go pprof 调试端点；结构化 JSON 日志（log-format: json）+ 按字段热调级（log-level-overrides）（来源：docs.ntfy.sh/docs/config metrics/profiling/logging 节，2026-10-21）；
  • 存储扩展：SQLite（默认）→ PostgreSQL（database-url，消息/用户/Web Push 三库合一，2.32 起支持连接池参数）（来源：docs.ntfy.sh/docs/config database-url 节，2026-10-21）；
  • 实验性集群：2.32 起可多节点共享 PostgreSQL 组成集群（experimental-cluster-*，active/passive 角色），官方明示「not ready for production」（来源：docs.ntfy.sh/docs/config experimental cluster 节与 Release Notes v2.32.0，2026-10-21）；
  • 系统托管：deb/rpm 包自带 systemd 单元（服务端 ntfy.service + 用户级客户端 ntfy-client.service）；官方文档亦提供 OpenRC、Windows 服务、macOS、Docker、Kubernetes（Kustomize/Helm）等形态（来源：docs.ntfy.sh/docs/install，2026-10-21）；
  • Web Push 密钥工具：ntfy webpush keys 一键生成 VAPID 密钥对（来源：docs.ntfy.sh/docs/config web-push 节，2026-10-21）。

4.5 版本演进要点

ntfy 版本节奏较快，近期（Releases Atom 流实查，查询日期 2026-10-21）：

版本Release updated 时间要点（来源：Releases Atom 流正文）
v2.32.02026-10-18为集群被动节点做准备（共享库上单例作业仅在 leader 执行）；流式订阅设置 RFC 10036 Incremental: ?1 头避免代理缓冲
v2.31.12026-10-17缺陷修复
v2.31.02026-10-16功能版本
v2.30.02026-10-12功能版本
v2.29.02026-10-07功能版本
v2.28.02026-08-27功能版本
v2.27.02026-08-04功能版本

💡 说明：v2.32.0 的 RFC 10036（RES——Redis Serialization Protocol 的 Incremental 扩展）头用于告知支持该语义的反向代理「流式响应不要缓冲」，对把 ntfy 置于 Nginx/CDN 之后的长连接订阅场景有实际意义。官方 apt 仓库（archive.ntfy.sh）对每个发布版均有 deb 存档（2.11.0~2.32.0 可查可装），版本回退方便。

五、快速开始（最小可用示例）

本节给出官方文档口径的最小可用示例（公共服务一条命令即可验证；自托管的最小安装三步），供快速建立体感。本节命令与步骤转述自官方文档（来源标注于各步），逐条命令的实测回显见本专栏实测篇：《Ubuntu 22.04 安装 ntfy 2.32.0 指南》、《ntfy 2.32.0 配置参数详解》、《ntfy 2.32.0 常用 CLI 命令与工具详解》。

① 公共服务发一条通知（零安装）——任何能发 HTTP 请求的环境直接可用（来源：docs.ntfy.sh/docs/publish「Sending a message」示例，2026-10-21）：

curl -d "Backup done, 3 files uploaded" https://ntfy.sh/mytopic

手机 App 订阅 mytopic 主题（填服务器 ntfy.sh）即可收到推送。

② 自托管最小安装（Debian/Ubuntu 官方 apt 仓库）（来源：docs.ntfy.sh/docs/install「Debian/Ubuntu repository」，仓库地址已迁移为 archive.ntfy.sh，2026-10-21）：

sudo mkdir -p /etc/apt/keyrings
sudo curl -L -o /etc/apt/keyrings/ntfy.gpg https://archive.ntfy.sh/apt/keyring.gpg
sudo apt install apt-transport-https
echo "deb [arch=amd64 signed-by=/etc/apt/keyrings/ntfy.gpg] https://archive.ntfy.sh/apt stable main" | sudo tee /etc/apt/sources.list.d/ntfy.list
sudo apt update && sudo apt install ntfy
sudo systemctl enable ntfy && sudo systemctl start ntfy

③ 自托管最小使用——发布与订阅（同上来源，2026-10-21）：

ntfy publish mytopic "Hello from self-hosted ntfy"   # CLI 发布
ntfy subscribe mytopic                               # CLI 订阅（长驻）

💡 说明：官方安装文档的重要时效信息——自 2025 年 9 月起，官方 Debian/Ubuntu 仓库已迁移至 archive.ntfy.sh，旧仓库 archive.heckel.io 仍可用但预计 2026 年初逐步淘汰（来源：docs.ntfy.sh/docs/install「As of September 2025, the official ntfy.sh Debian/Ubuntu repository has moved to archive.ntfy.sh」，查询日期 2026-10-21）。新部署应直接使用新仓库地址。

六、适用场景与限制

本节给出 ntfy 的典型适用场景与自托管时的硬性限制，作为选型判断的边界条件。

典型场景（依据：docs.ntfy.sh/examples 与 docs.ntfy.sh/docs/publish 全文，2026-10-21）：

  • 运维告警与任务通知：cron 任务、备份脚本、CI/CD 流水线结束时一条 curl 通知到手机；ntfy publish --wait-cmd 可在命令执行完成后自动发布结果；
  • 监控系统集成：Prometheus Alertmanager、Grafana 等支持 webhook 的监控系统经模板整形后推送；
  • 家庭自动化：Home Assistant 有官方 ntfy 集成；IoT 设备（ESP32 等）直接 HTTP POST 事件；
  • UnifiedPush 应用推送：为支持 UnifiedPush 的开源应用（Matrix 客户端 Element、Mastodon 客户端 Tusky 等）提供自托管推送通道；
  • 邮件/电话兜底通知：同一消息同时推手机、发邮件（X-Email）乃至语音外呼（X-Call + Twilio）。

已知限制（依据：docs.ntfy.sh/docs/config 与 docs.ntfy.sh/docs/install 相关约束，2026-10-21）：

限制说明
消息体默认 4Kmessage-size-limit 默认 4k，官方不建议调大（FCM/APNS 兼容）；大文本应转附件
iOS 自托管依赖 ntfy.shiOS 推送必须经官方服务器 APNS 中转轮询请求（upstream-base-url），完全离网环境 iOS 及时性受限
单机为主集群为 2.32 实验特性（官方明示 not ready for production），高可用需自建（如主备 + 共享存储）
消息保留有限缓存默认 12 小时（cache-duration），历史消息需自建下游持久化
无消息确认/重试语义通知类语义（at-least-once 到达设备），无消费组/应答机制，不适合做任务队列

💡 说明：ntfy 是「通知（notification）」而非「消息队列（message queue）」——没有 ack/nack、消费组、死信等队列语义。需要可靠投递队列时应用 RabbitMQ/NATS 等专业 MQ，ntfy 只做「最后一公里」的设备触达。

七、同类选型对比

本节把 ntfy 放入「自托管推送通知」同类工具中横向对比。社区数据口径：ntfy 星数取 shields.io（35k，2026-10-21）；Gotify 星数取 shields.io 同口径（16k，来源：《Gotify 3.1.1 介绍与选型指南》同日实查）。

维度ntfy 2.32.0Gotify 3.1.1Bark（iOS 侧）Apprise自建 Web Push
定位HTTP pub-sub 通知服务极简自托管推送服务端iOS 个人推送工具多通道通知聚合库/CLI自行实现推送协议
语言/形态Go 单二进制Go 单二进制GoPython 库/CLI自研
许可证Apache-2.0 & GPLv2MITMITMIT—
消息模型topic 中心，命名即用application/client/user 三实体URL path 即主题各通道适配器订阅端点
官方手机客户端Android（Play/F-Droid/APK）+ iOS（App Store）Android（Play/F-Droid），无官方 iOSiOS 专用无（走各通道 App）浏览器
统一推送协议UnifiedPush 服务端实现无无无无
附件支持（本地/S3，配额+过期）不支持支持依通道自研
邮件发布/转发双向（SMTP 入口 + X-Email 出口）无无有邮件通道无
电话外呼支持（Twilio）无无依通道无
访问控制ACL（用户×主题×读写）+ token + tieruser/application/client token单用户—自研
订阅通道JSON/SSE/WebSocket/轮询WebSocket/REST 轮询HTTP 轮询/长连接—浏览器 Push
存储SQLite / PostgreSQLSQLite / MySQL / PostgreSQL文件——
定时延迟发布支持（相对/绝对时刻）无无无无
社区规模35k★16k★数 k★ 量级数 k★ 量级—

如何选型（「如果…则…」建议）：

  • 如果要「最低门槛的手机通知」且团队全用 Android、不在意 iOS——Gotify 的 application/client 模型更简洁，运维面更小；
  • 如果需要 iOS 官方支持、UnifiedPush、附件、邮件双向、定时发布 中任意一项——选 ntfy（Gotify 无官方 iOS App，附件/定时/邮件均不支持）；
  • 如果消息源是几十种第三方服务（GitHub/Twitter/邮件等）而不是自家脚本——Apprise 这类聚合器更合适，它可以把同一条通知扇出到 ntfy/Gotify/Telegram 等多个通道；
  • 如果受众全是公司内部单一手机号、追求极简——Bark 足够（iOS）；
  • 如果要对接的客户系统只会「发 HTTP 请求」且无法管理令牌——ntfy 的 topic 命名即用模型集成成本最低（配合 ACL 收紧）；
  • 如果需要多租户配额运营一个公共服务——ntfy 有 tier/Stripe 体系（ntfy.sh 同款），Gotify 无此层。

社区活跃度与版本节奏量化（查询日期 2026-10-21）：

  • ntfy：35k★；官方 apt 仓库存档 2.11.0→2.32.0 共 27 个可装版本；近半年（2026-07→2026-10）发布 2.26.1~2.32.0 共 10 个版本，10 月单月连发 2.29/2.30/2.31/2.32 四个版本——开发活跃度高；
  • Gotify：16k★；当前稳定 3.1.1（2026-09-15），3.x 大版本（环境变量配置化、会话提权）演进中——节奏慢于 ntfy，但架构更稳；
  • 兼容矩阵：ntfy 官方发布物覆盖 amd64/armv6/armv7/arm64 四架构 + Windows/macOS/FreeBSD/Alpine/Homebrew/Docker/K8s，客户端覆盖 Android/iOS/Web/桌面/CLI 五端，矩阵明显宽于 Gotify（七架构 Linux/Windows + Android/Web）。

八、参考链接