Echobell 与 Gotify

自己维护一台服务器，还是让提醒真正送到 iPhone

Gotify 让你完整拥有一台推送服务器。Echobell 提供 iOS、Android 与 Apple Watch 送达，包括像来电一样响起的提醒，而且不需要你运维任何东西。

Echobell

G Gotify

下载 Echobell Google Play 查看文档

一句话结论

如果消息绝不能离开自己的机器，Gotify 是正确答案。如果提醒必须送到 iPhone 并且真的把人叫醒，Echobell 才是。

团队用 iOS，或者提醒不允许被漏掉，就选 Echobell；自托管是硬性要求，就继续用 Gotify。

一览

Echobell

G Gotify

你需要运维什么

什么都不用——建一个频道，往它的 URL 发 POST

一台 Go 服务、数据库、TLS 证书和备份

iOS 与 Apple Watch

原生 iOS、Android 与 Apple Watch 送达

官方只有 Android 和网页客户端，没有官方 iOS 应用

紧急程度

普通推送、时效性通知，或像来电一样响起

用 priority 数值映射到通知重要性

主要差异

两者都能推送消息，区别在于谁来运维，以及一条提醒最高能升级到什么程度。

维度

Echobell

G Gotify

托管方式

Echobell

思路不同

托管服务，无需自建

没有绝对优劣，取决于你想不想自己管这台机器。

G Gotify

思路不同

自托管，需要自己安装和维护

iOS 与 Apple Watch

Echobell

原生支持

一等公民级的 iOS 应用，并支持 Apple Watch

团队用 iPhone 时，Echobell 是更现实的选择。

G Gotify

不支持

没有官方 iOS 客户端，iOS 用户只能用第三方应用

升级上限

Echobell

原生支持

时效性通知与穿透专注模式的来电式提醒

Echobell 能叫醒睡着的人，普通推送做不到。

G Gotify

不支持

只有优先级，没有来电升级，叫不醒睡着的人

数据留存位置

Echobell

不支持

消息经过 Echobell 的托管服务

数据必须留在自己机器上时，Gotify 完胜。

G Gotify

原生支持

消息从不离开你自己控制的服务器

Echobell 的优势

Echobell 面向的是「这条提醒必须被处理」的时刻，而不只是被记录下来。

不用绕路就能送到 iPhone

有持续维护的 iOS 应用和 Apple Watch 支持，不必再去找第三方 Gotify 客户端。

会响起来的提醒

把频道设为来电模式，关键事件会以来电形式抵达，穿透静音与专注模式。

没有需要一直运行的东西

没有服务器、数据库、证书续期和升级路径——告警链路本身不会成为掉线的那一环。

最适合的场景

从 Gotify 迁移到 Echobell 的团队，通常是因为这几件事。

团队换成了 iPhone

官方 Android 客户端已经覆盖不了值班的人。

夜里的故障总被漏掉

静默推送不够用，必须把人叫醒。

没人想再照看推送服务器

维护 Gotify 花掉的精力已经超过这些提醒本身的价值。

从 Gotify 迁移

两套并行跑一段时间即可——Gotify 的 application 几乎可以一对一映射成 Echobell 频道。

1

把每个 Gotify application 重建为一个频道

一个服务一个频道，沿用你已经在用的名字。
2

把发送方指向频道 webhook

用 Echobell 的 webhook URL 替换 Gotify 的地址和 token，POST 的 JSON 结构不用动。
3

给重要的那些提高紧急级别

原本用 Gotify priority 8 以上的频道，改成时效性通知或来电模式。