Gotify 3.1.1 介绍与选型指南

Gotify 3.1.1 联网溯源认知与选型：Go 单二进制自托管推送通知服务的定位、三模型架构、版本演进时间线（2.x→3.x 破坏性变更）与 ntfy/Novu 量化对比，全部标注来源与查询日期 2026-10-21。

Gotify即时通信Gotify2026/10/21

Gotify 3.1.1 介绍与选型指南

目标：面向正在评估「自托管推送通知服务端」的技术团队，系统介绍 Gotify 的定位、架构、功能特性、版本演进与同类横向对比，帮助完成「选不选它」的判断。本篇为认知与选型篇，全部信息基于官方公开资料联网溯源整理，关键数据均标注来源与查询日期（2026-10-21），不含本地实测内容；安装、配置与 API 的逐条实测见本专栏《Ubuntu 22.04 安装 Gotify 3.1.1 指南》、《Gotify 3.1.1 配置参数详解》与《Gotify 3.1.1 API 使用详解》。

一、环境信息

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

  • 溯源方式：纯联网溯源（官方文档站 gotify.net、GitHub Releases、shields.io 徽章数据），未包含任何本地实测环节；
  • 版本认定日期：2026-10-21；
  • Gotify 最新稳定版本：3.1.1（发布于 2026-09-15）；
  • 版本认定依据（双源交叉）：
    • 来源一：GitHub gotify/server 仓库 Releases Atom 流（https://github.com/gotify/server/releases.atom），最新 Release 标题为 v3.1.1，updated 时间 2026-09-15T18:45:27Z（查询日期 2026-10-21）；
    • 来源二：GitHub gotify/server releases/latest 访问重定向（https://github.com/gotify/server/releases/latest → https://github.com/gotify/server/releases/tag/v3.1.1，查询日期 2026-10-21）；
  • 仓库地址说明：项目原仓库为 gotify/gotify，当前官方仓库为 gotify/server（官方文档站 gotify.net 全站链接均指向 github.com/gotify/server，查询日期 2026-10-21）；Go module 路径自 3.1.0 起为 github.com/gotify/server/v3（来源：Release Notes v3.1.0「Update go module path to github.com/gotify/server/v3」）；
  • 社区规模：GitHub 星数 16k（来源：shields.io 徽章接口 https://img.shields.io/github/stars/gotify/server.json 返回 "message":"16k"，查询日期 2026-10-21）；
  • 许可证：MIT License（来源：官方发布包 gotify-linux-amd64.zip 内 LICENSE 文件，"Copyright (c) 2018 jmattheis"；另有 GitHub 仓库 LICENSE 声明，查询日期 2026-10-21）。

二、软件概述

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

Gotify 是一个用 Go 编写的、以单二进制形式分发的自托管推送通知服务端：业务系统、脚本或 AI Agent 通过 REST API 向它推送消息，用户通过内嵌 WebUI 与 Android 客户端实时接收消息（REST 轮询 + WebSocket 流式下发）。它解决的核心痛点是——当你不想把服务器状态、告警、任务结果发到第三方 SaaS 通知服务时，可以在自己的服务器上跑一个纯开源、数据完全自持的通知中枢。

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

维度事实来源
项目名Gotify官网 gotify.net
官方仓库github.com/gotify/server（原 gotify/gotify）gotify.net 首页链接，2026-10-21
实现语言Go（go1.26.0 构建）发布包 gotify version 构建信息口径；官方仓库 go.mod
许可证MIT发布包 LICENSE，2026-10-21
最新稳定版3.1.1（2026-09-15）Releases Atom 流，2026-10-21
官方分发形态per-platform zip（内含单二进制）+ Docker 多架构镜像gotify.net/docs/install，2026-10-21
支持平台linux-amd64 / linux-386 / linux-arm-7 / linux-arm64 / linux-riscv64 / windows-386 / windows-amd64gotify.net/docs/install，2026-10-21
官方客户端Android App（gotify/android）+ 服务端内嵌 WebUI；iOS 无官方客户端gotify.net 与 GitHub gotify/android，2026-10-21
数据库SQLite（默认，单文件）/ MySQL / PostgreSQLgotify.net/docs/config，2026-10-21
部署形态单机服务（非分布式），配置全走环境变量（3.x）gotify.net/docs/config，2026-10-21

💡 说明：Ubuntu/Debian 官方仓库与 PPA 均无 Gotify 的 apt 包，官方安装文档仅提供「per-platform zip 二进制」与「Docker 镜像」两条路径；Alpine 社区仓库收录了 gotify 包（2.9.1-r4，来源：pkgs.alpinelinux.org，查询日期 2026-10-21）。因此在 Ubuntu 服务器上的标准落地方式是「官方 zip 二进制 + systemd 托管」。

三、核心架构

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

3.1 进程形态：单二进制 + 内嵌 WebUI

Gotify 服务端是一个静态编译的 Go 可执行文件（发布包解压后单个 ELF 文件约 40MB），WebUI（React 前端，v2.7.1 起构建链为 Vite，来源：Release Notes v2.7.1「move to vite for building the ui」）以静态资源形式内嵌在二进制中，启动后由同一进程同时提供：

  • WebUI 页面：登录、应用/客户端/消息管理，路径 /；
  • REST API：消息推送与全部管理操作；
  • WebSocket 流：/stream 端点，客户端长连接实时接收新消息；
  • Swagger 文档：/swagger 页面内嵌完整 API 规范。

数据面默认使用 SQLite 单文件数据库，建表、迁移全部自动完成，无需外部数据库即可运行；也可切换到 MySQL / PostgreSQL（3.2 节）。日志在 3.0.0 起切换为 zerolog 结构化输出（来源：Release Notes v3.0.0「Switch logging to zerolog」）。

3.2 数据模型：application / message / client 三模型

Gotify 的权限与消息模型由三个实体构成，这也是它与「topic 制」推送服务最本质的差异：

实体含义令牌前缀典型用途
application（应用）消息的发送方身份，如「备份服务器」「监控告警」gtfya.（application token）每个对接业务系统建一个应用，拿应用令牌推消息
message（消息）应用推送的一条通知，含 title / message / priority / extras—消息按应用归属，可分页查询、单条或全部删除
client（客户端）消息的接收方身份，如「我的手机」「运维 CLI」gtfyc.（client token）每个接收设备/程序建一个客户端，拿客户端令牌订阅消息流

三个实体之上是 user（用户）：一个用户拥有多个应用与多个客户端；管理员用户可管理全部用户。从 3.0.0 起令牌「仅创建时展示一次」（tokens are only shown once），不再明文入库（Release Notes v3.0.0「Don't store tokens in plain text」「API tokens are no longer returned in the GET endpoints」），并在 3.1.1 中进一步要求「创建用户等敏感操作必须使用提权会话」（安全通告 GHSA-phfm-q6fr-wv34）。

3.3 通信通道与认证

  • 推送（写）：POST /message，认证使用 application token，支持三种携带形态——Authorization: Bearer <token> 请求头、X-Gotify-Key: <token> 请求头、?token=<token> 查询参数（来源：服务端 /swagger 内嵌规范 securityDefinitions，2026-10-21 核对）；
  • 订阅（读）：GET /stream WebSocket 长连接，使用 client token 认证，新消息实时帧下发；WebUI 与 Android 客户端即基于该通道；
  • 管理（读写）：application / client / user 全套 CRUD API，认证可使用 client token 或 HTTP Basic 认证（用户名+密码），敏感操作（创建/修改用户、轮换令牌）要求提权会话或 Basic 认证；
  • 会话：WebUI 登录（POST /auth/local/login）签发 HTTP-only 会话 Cookie（3.0.0 起弃用 localStorage 存令牌），登录即创建一个会话客户端，默认提权窗口 1 小时；
  • 扩展通道：3.x 文档已收录「AI Agents (MCP)」指南——服务端提供 MCP 端点 /mcp（Streamable HTTP 传输），供 Claude Code、VS Code Copilot 等 AI Agent 用 send_message 工具发通知（来源：gotify.net/docs/mcp，2026-10-21）。注意：该端点当前随 master 分支文档发布，在 3.1.1 稳定版中尚未提供（对 3.1.1 实例请求 /mcp 返回 404），属于下一版本的能力预告，选型时应以当期 Release Notes 为准。

四、功能特性

本节按「推送能力 → 安全模型 → 运维能力」归纳 Gotify 的功能清单，每项均标注官方来源。

4.1 推送与消息能力

  • REST 推送：一条 POST /message 即完成推送，消息体支持 title、message（允许 Markdown，禁 HTML）、priority、extras；
  • 消息优先级：0-10 整数，客户端据此决定打扰程度。Android 官方 App 的映射：0 不通知、1-3 通知栏图标、4-7 图标+声音、8-10 图标+声音+震动；WebUI 对 priority ≥ 4 的消息播放提示音（来源：gotify.net/docs/priority，2026-10-21）。应用可设置 defaultPriority，消息未带 priority 时自动采用；
  • 消息 extras：键值对扩展字段，键格式 <顶级命名空间>::[<子命名空间>::]<action>，官方客户端保留 client:: 命名空间，如 client::display（Markdown 渲染）、client::notification（点击跳转 URL）；
  • WebSocket 实时流：/stream 端点，ping 周期默认 45 秒（GOTIFY_SERVER_STREAM_PINGPERIODSECONDS），支持按 Origin 白名单限制跨域连接；
  • 消息管理：按应用维度与全局维度分页查询（limit/since），支持单条与批量删除。

4.2 账户与安全

  • 用户体系：多用户隔离，用户各自管理自己的应用与客户端；管理员可增删用户；
  • 会话提权（Session Elevation）：3.0.0 引入（安全通告 GHSA-3hcj-9m7p-wwm9），创建用户、轮换令牌等敏感操作要求「近期重新认证」的提权会话；3.1.1 将「创建用户」也纳入提权要求（GHSA-phfm-q6fr-wv34）；
  • 令牌安全：3.0.0 起令牌哈希存储、仅在创建/轮换时展示一次，支持通过 PUT /application/{id}/security 主动轮换（需提权）；
  • OIDC 单点登录：3.0.0 引入对 OpenID Connect 身份提供方（Authelia、Dex、Keycloak 等，需支持 PKCE）的登录支持；3.1.0 增加从 OIDC claims 映射管理员身份、GOTIFY_LOCALAUTH_ENABLED 可关闭本地密码认证、GOTIFY_OIDC_AUTO_REDIRECT 自动跳转 IdP 等（来源：Release Notes v3.0.0 / v3.1.0）；
  • 公开注册开关：GOTIFY_REGISTRATION 默认 false，可按需开放自注册。

4.3 运维与扩展

  • 自动清理：3.0.0 起自动删除长期不活跃的客户端/会话（「Automatically delete inactive clients/sessions」），客户端可设置 expiresAfterInactivitySeconds；
  • 插件机制：支持以 Go 共享库（.so）形式扩展，服务端按目录扫描加载（GOTIFY_PLUGINSDIR），WebUI 可启用/禁用/配置插件；
  • 多数据库：SQLite（默认零依赖）/ MySQL / PostgreSQL，连接串经环境变量切换；
  • TLS：内建 HTTPS 监听（证书文件或 Let's Encrypt 自动签发，支持 ACME staging 环境与自定义 directory URL）；
  • 配置即环境变量：3.0.0 起全面采用环境变量配置（含 _FILE 后缀读密钥文件、text-list CSV 语法、json-map JSON 语法），并提供 gotify migrate-config 子命令把 2.x config.yml 一键转换（来源：Release Notes v3.0.0、gotify.net/docs/config）。

4.4 版本演进时间线

以下时间线取自 GitHub Releases Atom 流（查询日期 2026-10-21），可看出 2026 年的发布节奏约为每季度一个 feature 版本：

版本发布日期要点
v2.7.32025-09-21Let's Encrypt 证书操作日志与 TLS challenge 修复
v2.8.02026-01-02应用图片删除、Markdown 内嵌图渲染修复、GORM 升级
v2.9.02026-02-13WebUI「推送消息」对话框、拖拽排序应用
v2.9.12026-02-28MySQL 启动崩溃修复、Go 1.26
v3.0.02026-07-18大版本：OIDC 登录、会话提权、配置迁移到环境变量（config.yml 弃用）、令牌哈希存储且仅展示一次、新增 CLI（serve/version/migrate-config）、自动清理不活跃客户端
v3.1.02026-08-27GOTIFY_LOCALAUTH_ENABLED、OIDC 管理员映射与按钮命名/自动跳转、插件活跃期崩溃修复
v3.1.12026-09-15安全修复：创建用户要求提权会话（GHSA-phfm-q6fr-wv34）、Let's Encrypt 请求失败崩溃修复

⚠️ 注意：从 2.x 升级到 3.x 是破坏性升级——config.yml 不再被读取，需用 gotify migrate-config 转换为环境变量格式；令牌只展示一次的语义也影响既有脚本（若脚本此前依赖 GET 接口回读令牌，需要改造）。

五、快速开始

本节给出官方文档口径的最小可用路径，命令与步骤转述自官方安装文档（来源：gotify.net/docs/install，查询日期 2026-10-21），本篇不做本地实测；完整的 Ubuntu 服务器从零到 systemd 托管的逐命令实测见本专栏《Ubuntu 22.04 安装 Gotify 3.1.1 指南》。

官方安装文档给出的二进制安装路径为「下载对应平台 zip → 解压 → 运行二进制 → 浏览器打开 WebUI」：

  1. 从 https://github.com/gotify/server/releases/download/v3.1.1/gotify-linux-amd64.zip 下载发布包（官方文档 URL 模板 gotify-{platform}.zip，替换版本与平台名）；
  2. 解压得到单文件可执行程序 gotify-linux-amd64；
  3. 直接运行该程序，服务默认监听 80 端口（3.x 默认值，来源：gotify.net/docs/config 的 GOTIFY_SERVER_PORT=80 默认注释）；
  4. 浏览器打开 http://<服务器地址>/，首次登录使用初始管理员账号（默认用户名/口令由配置项 GOTIFY_DEFAULTUSER_NAME / GOTIFY_DEFAULTUSER_PASS 决定，默认均为 admin，仅在首次建库时生效）；
  5. 在 WebUI 中创建应用（application）拿到应用令牌，即可从任意业务系统 POST /message 推送第一条消息。

💡 说明：3.x 的全部行为（监听端口、数据库、初始账号、TLS、OIDC 等）都通过环境变量配置，可写在 env 文件中由 systemd 的 EnvironmentFile= 加载；具体参数逐项说明见本专栏《Gotify 3.1.1 配置参数详解》，REST API 逐条调用与 WebSocket 实测见本专栏《Gotify 3.1.1 API 使用详解》。

六、适用场景与限制

本节给出「什么场景该选/不该选」的边界判断，避免把通知服务错当聊天系统用。

6.1 适用场景

  1. 运维告警中枢：Zabbix/Prometheus/监控脚本的告警回调统一投递到自托管 Gotify，Android 客户端按 priority 分级提醒；
  2. CI/CD 与长任务通知：构建结束、备份完成、模型训练收敛等事件推送到值班手机；AI Agent（Claude Code 等）通过 MCP 端点在长任务结束时主动通知（能力随下一稳定版发布）；
  3. 家庭实验室/自托管生态的消息汇聚：家庭服务器上的下载、磁盘、门禁、摄像头事件统一进一个收件箱；
  4. 多应用隔离的团队通知：每个业务系统一个 application（独立令牌、独立消息流），每个成员一个 client（独立订阅、独立设备），管理员集中审计。

6.2 限制与边界

  1. 纯「机器到人」通知，不是聊天：消息单向流动（应用 → 用户），没有会话、回执、群组概念；人与人之间的实时沟通应选 XMPP/Matrix 类服务端（同批次的 ejabberd、Synapse 等，参见《ejabberd 26.09 介绍与选型指南》对 IM 服务端的量化对比）；
  2. 单机架构，无内建集群/高可用：官方不提供多节点集群方案，高可用依赖外部手段（反向代理多实例 + 共享数据库的方案官方未给出口径，需自行评估）；
  3. 无内建邮件/短信渠道：Gotify 只做「站内推送」（WebUI/Android/WebSocket），邮件、短信等外部渠道需自行桥接（如经 ntfy/邮件网关转发或自写插件）；
  4. iOS 无官方客户端：官方客户端为 Android App 与 WebUI，iPhone 侧无官方 App；
  5. 默认配置面向实验：默认监听 80 端口、默认初始账号口令均为 admin，生产部署必须改端口/改口令/上 TLS（或置于反代之后）；
  6. 3.x 配置破坏性变更：从 2.x 升级必须迁移配置并检查依赖「GET 回读令牌」的脚本。

七、同类选型对比

本节把 Gotify 与同类自托管推送/通知组件做量化横向对比。对比对象选型依据：ntfy 是与 Gotify 定位最接近的开源自托管推送服务端（同为 Go 单二进制），Novu 则代表「产品级多渠道通知基础设施」一档，三者合起来覆盖了「轻量通知中枢」从极简到重型的主要选择。

7.1 量化对比表

数据来源与口径：Gotify 版本/星数（GitHub Releases Atom 流、shields.io 徽章，2026-10-21）；ntfy 版本取自 binwiederhier/ntfy Releases Atom 流最新条目 v2.32.0、星数 35k（shields.io，2026-10-21）；Novu 星数 40k（shields.io，2026-10-21）。语言/部署形态以各自官方文档为准。

维度Gotify 3.1.1ntfy v2.32.0Novu
一句话定位自托管推送通知服务（账户制）自托管推送通知服务（topic 制、极简）产品级多渠道通知基础设施（in-app/邮件/短信/推送/聊天）
GitHub 星数16k35k40k
许可证MITApache-2.0（服务端）以其仓库声明为准
实现语言Go，单二进制（约 40MB）Go，单二进制TypeScript/Node.js，多组件编排
部署重量极轻：单进程 + SQLite 单文件，无外部依赖极轻：单进程 + SQLite重：自托管需多个配套服务（消息队列、缓存、数据库等）
消息模型三模型：application/message/client，令牌前缀 gtfya./gtfyc. 区分收发双方topic 模型：PUT/POST /<topic> 即推，默认无需账户subscriber/workflow 模型：面向终端用户的多渠道触达
身份与权限多用户 + 角色 + 会话提权 + OIDC 单点登录（3.x）匿名推送为默认哲学，可选访问令牌/权限面向产品用户的订阅关系管理
客户端官方 Android App + 内嵌 WebUI + WebSocket 流官方 Android + iOS App（iOS 经 APNs 中继）、WebSocket/JSON 流、UnifiedPushWeb/移动端 SDK 集成为主，自带收件箱组件
推送协议REST + WebSocket 流REST（含纯 PUT 一行推送）+ WebSocket 流 + UnifiedPushREST + 渠道 Provider 适配器
存储SQLite / MySQL / PostgreSQLSQLite（消息缓存与访问控制）MongoDB 等外部存储
TLS/反代内建 HTTPS + Let's Encrypt 自动签发内建 TLS，官方反代指南通常置于反代后
适合谁要「多应用多设备账户制通知中枢」的个人/小团队要「一行 curl 推手机」的脚本/IoT/极客场景要「产品内通知中台」的研发团队

7.2 选型建议

  • 如果你要的是「自持数据的多应用通知中枢」：每个业务系统有独立身份、每个设备有独立订阅、有 WebUI 管理面和用户体系——选 Gotify。它是三者中「账户制通知中枢」形态做得最纯粹的一个。
  • 如果你要的是「脚本一行命令推到手机」：不想要账户体系、IoT 设备只想 curl -d "msg" ntfy.sh/topic——选 ntfy。它的 topic 匿名模型和 UnifiedPush 生态是独有优势，官方 iOS App 也是三者中唯一覆盖 iOS 的。
  • 如果你要的是「产品里的通知中台」：一次事件要同时触达站内收件箱、邮件、短信、多个推送通道，并要工作流/去重/多语言模板——选 Novu，代价是自托管栈明显变重。
  • 如果你要的是「人与人的聊天」：Gotify/ntfy/Novu 都不合适，应看 XMPP（ejabberd/Prosody）、Matrix（Synapse）或团队聊天（Rocket.Chat/Zulip）等服务端。

💡 说明：ntfy 与 Gotify 并不互斥。常见组合是把 Gotify 作为「账户制收件箱」，把 ntfy 作为「匿名快速通道」，监控告警按敏感级别分流；两者同为 Go 单二进制，运维成本叠加很低。

八、参考链接