1 前言
在之前的文章中,我有2篇关于自建Umami的文章,一篇是搭建1.33.1版(参见文章:docker系列 搭建基于umami的网站流量监测系统),一篇是搭建2.11.3版(参见文章:家庭数据中心系列 当下最新版umami(2.11.3)详细搭建教程)。虽然我也部署了Google Analytics 4,但 Umami 的确是一个非常好的补充工具——界面简洁、数据直观,非常适合快速查看访客行为和趋势,从个人使用的角度来说,比 GA4 的使用体验还更轻量、友好。
但自建 Umami 也有让我略感“心累”的地方:每次大版本升级(比如从 1.x 到 2.x,或从 2.x 到 3.x),数据结构发声变动,旧数据就不一定能无缝兼容。比如这次推出的 v3 版本,甚至直接移除了对 MySQL 的支持,只保留了 PostgreSQL,这对那些建在 MySQL 上的旧站点来说就很尴尬:要么费劲做全盘迁移,要么丢弃历史数据重头来过。当然,还有一种选择,就是一个版本用一辈子,不过知道有了新版本还能坚持不升级的,都是拥有强大忍耐力的狠人,不是普通人可比~。
我现在就又面临要不要升级Umami到v3版本的选择,想看看新版本界面又多了什么功能,但是又的确不想再折腾了,毕竟之前已经弄过一次v1版本到v2版本了,就算这次又从v2升级到v3,以后还有不知多少次大版本升级呢,毕竟每年Umami几乎都有一次大版本升级。虽然理论上可以手动备份、迁移数据库,再按照升级文档一点一点处理,但实际操作下来,总有种在给数据库做“开颅手术”的感觉——稍不注意就是报错、数据缺失、甚至重建服务。正因为这个原因,很多人干脆就在大版本切换时直接全新部署,不留历史数据了。
另一方面,自建 Umami 实际对资源的消耗并不算轻。尤其如果你像我一样是用 WordPress 搭建博客,VPS 上已经跑了 WordPress+MariaDB,再加上 Docker 版本的 Umami(以及 PostgreSQL),**2 vCPU + 2GB 内存这种“中配”机型性能也不算很充裕,更别说大多数人服务器上肯定不只跑这两个服务,日志、备份、代理等一堆小东西都要抢资源。
那么,有没有一种方式,既可以享受 Umami 好用的统计,又不用自己搭建服务端、不折腾升级,还能一直保持使用最新版本呢?
当然有,这就是本文要介绍的 —— Umami Cloud 托管服务。通过官方托管,你可以一直体验最新版Umami的功能,省去自己运维折腾,关键免费版配额对一般的个人博客来说其实已经完全够用了。
2 自建Umami 和 Umami Cloud 托管方式优劣势对比
虽说我觉得 Umami Cloud 的免费版配额对一般的个人博客完全够用,但是每个人的实际需求都不同,而 Umami Cloud 的免费版确有其不足,所以这一章我简单把 自建 Umami 和 Umami Cloud 托管的优缺点列出来,让大家能够一目了然,对比后可以根据自身情况选择最合适的方式。
| 维度 | 自建 Umami | Umami Cloud 托管 |
|---|---|---|
| 部署与维护 | 需要自己搭建服务器和数据库(从v3版开始只支持PostgreSQL数据库),灵活度高,维护成本也高。 | 只需注册账号后创建对应站点,生成并在站点代码中嵌入追踪代码即可使用,服务器和数据库由官方托管,无需维护,升级自动完成,省心。 |
| 数据迁移与升级 | 跨大版本升级时数据库结构可能变化,需手动处理数据迁移,一旦操作不慎可能导致报错或丢失历史数据。 | 数据迁移与兼容由官方负责,升级透明,稳定可靠,但免费版仅保存最近 12 个月数据。 |
| 性能与资源消耗 | 对 VPS 或服务器性能要求较高,尤其是同时运行 WordPress + Umami 时,2 vCPU + 2GB 内存的中配机型性能也不算轻松。 | 性能由官方承担,不占用本地服务器资源,无需担心流量波动的资源瓶颈,适合轻量使用场景。 |
| 成本 | 软件开源免费,但需承担运行软件的VPS费用 | 免去运维成本,免费版支持最多3个站点,每月支持 100 万事件,个人博客一般足够;付费版按功能与事件量计费。 |
| 隐私与数据控制 | 数据存储在自己服务器上,完全掌控,包括备份、删除、导出,符合自有隐私策略。 | 数据存储在 Umami Cloud,隐私与合规性由官方保障,可用于合法站点,但数据最终不在自己完全掌控之中。 |
| 安全性 | 需自行做好服务器安全、数据库访问控制、防火墙规则、bot防护、HTTPS 配置等,安全性取决于配置是否得当,存在人为风险。 | 使用官方云端服务,默认 HTTPS,内置安全机制和隔离环境,减少运维风险,但需信任官方的数据托管安全性。 |
| 使用灵活性 | 可自由修改源码、自定义配置、扩展功能和集成系统,适合二次开发或复杂场景。 | 功能受限于官方提供的界面与 API,定制性不高,但对大多数普通监控需求来说功能已足够。 |
| 适用场景 | 适合对历史数据依赖大、注重自主性或热衷折腾系统的用户,以及希望完全控制隐私和接口开放性的场景。 | 适合希望省心、快速部署,关注数据可视化而不想维护后端的用户,尤其是个人博主、小企业、小型站点等。 |
总结:
从整体对比来看,自建 Umami 最大的优势在于 完全掌控数据、历史记录无限制、监控站点无限制,但同时需要 自己维护服务器、手动升级、承担性能压力。而 Umami Cloud 的优势则是 无需运维、升级自动、性能稳定、快速上手,非常省心。
当然,Umami Cloud 免费版也有明显的劣势:只支持最多3个站点,数据只能保留最近 12 个月。如果你能够接受这两点,那么对于个人博客或小型网站来说,Umami Cloud 无疑是最省心、最直接的方案。
3 注册Umami Cloud并完成基础配置步骤
访问官网注册链接——https://cloud.umami.is/signup,根据以下图文教程进行配置:

然后Umami Cloud会给注册邮箱发送一封确认邮件:

在确认邮件中,复制6位确认码,并点击”Login”按钮跳转到登录验证界面:

在登录界面使用注册时的用户名和登录密码进行登录,进入确认界面,输入确认邮件中的6位确认码进行确认:


Umami Cloud 注册时需选择数据存储区域(美国或欧盟)。选择的区域决定数据存放在哪个数据中心,以及适用的法律和隐私保护规则。一般来说,欧盟区域更符合 GDPR 要求,适合注重隐私与合规的用户;美国区域则可能对全球访问更快、法律环境简单一些。如果你的访客主要不来自欧盟,建议选择美国区域。


生成包含追踪代码的js脚本:


同理可以添加其他站点(免费账号最多可以添加3个站点),之后只需要把保存的站点追踪代码脚本插入需要监控的站点代码中即可(WordPress建站的朋友代码插入方式可以参见以下链接:WordPress中插入Umami追踪代码)。
如果有Cloudflare账号,且站点是通过Cloudflare进行发布,则可以直接通过zaraz技术直接从云端加载js脚本,不用直接添加到网站代码中,感兴趣的朋友参见文章:家庭数据中心系列 优化网站加载速度:通过 Cloudflare Zaraz 实现第三方脚本的云端加载及管理。另,现在Cloudflare的UI又有了很大的变化,zaraz功能已经迁至以下位置,我都找了半天~:

最后,点击网站名称即可进入监控见面:


注:偷一下懒,我就不逐一为每个功能项截图了,大家有兴趣的话自己注册个Umami Cloud账号试试就知道了。
4 启用分享专用链接
在上一章最后,我简单介绍了Umami Cloud官方UI界面中可以看到的站点统计内容,不过,这个UI只能自己登录Umami Cloud后才能看到,不能用来对外发布。如果要对外发布的话,需要启用”共享链接”功能,在官方UI的右上方有个分享按钮:


之后即可让任何人通过这个链接以只读方式查看访问站点的统计数据了,大家可以直接看这个链接展示效果:Umami Cloud统计效果展示链接。
5 数据导出
Umami Cloud比自建的Umami多了一个功能,就是统计数据的导出,所以,对于那些不太确认自己是否需要自行搭建Umami的博主而言,完全可以先使用Umami Cloud体验一段时间,如果真觉得满意并且确认需要长时间保留数据,可以将Umami Cloud的统计数据导出并按照官方手册导入自建的Umami里。

点击”设置”按钮:



随后注册邮箱里会收到一封包含了下载导出数据链接的邮件:

点击下载链接会下载一个zip文件,解压缩后得到的文件夹里有3个csv文件:

主要是”website_event.csv”这个文件,打开后可以看到统计内容:

剩下的就是如何把csv文件导入自建Umami对应的PostgreSQL数据库或者Mysql数据库的事了,网上教程很多,有兴趣的朋友自行研究即可。
6 总结
选择自建还是用云服务,本质上就是一个“自己掌控”还是“交给别人”之间的平衡,没有绝对的好坏,只有适不适合。
例如,很多博主选择自建 Umami,正是看重了它完全可控、无限制、大版本升级自主可控的灵活性;而有些人后来又从 Umami Cloud 迁回自建,也是因为不愿意受限于免费版 12 个月数据保存的限制。
但如果你只是想要一个简单稳定的访问统计,不依赖长周期数据,也不强求各种高度自定义的能力,那 Umami Cloud 免费版的功能其实已经足够了,尤其是对于个人博客、静态站点和一些轻量的信息页面来说。
所以,关键还是看需求:
- 如果你有高程度的控制欲、想长期保留详细数据、愿意维护服务,自建是绝对正确的选择。
- 如果你想快速上手统计分析、不想折腾、不介意历史数据最多保存 12 个月,那么 Umami Cloud 免费版其实就是最优解。
对大多数个人博客来说,「过去 12 个月的数据」足以完整反映读者趋势、内容表现、SEO 效果等关键指标。Umami Cloud 免费版能保证 1 年的数据保留,那其实已经覆盖了绝大多数使用需求。
往往只有对长期数据有严格分析需求的用户,才会觉得“必须保留 3~5 年数据”这种诉求是刚需。但坦白讲,对大部分个人博主来说,这更多是一种执念或“强迫症”——尤其是在访问量不大的情况下,长期放着很少回看的旧数据,除了占用存储,也并没多少实际价值。
以我自己来说,除了最开始部署Umami的时候图新鲜还天天看一下,现在平时都懒得去看Umami的统计了,毕竟,一天撑死了几百的访问,看不看都那样,最多有时候心血来潮看看最近24小时的访问量。为了一个偶尔想起点开来看看的应用,还耗费VPS资源去搭建和维护(每年还要来一次大版本升级),现在想来也不太划算的感觉(仅仅是对我而言)。
所以,对我这类人来讲,Umami Cloud就是比较适合的选择了。
我在2.X时就用的PostgreSQL版本的,倒是没什么感觉直接就升级到3.X。唯一就是残留了一个小bug,2.X时代,默认页是跳转「/dashboard」的。3.X默认页变成了「/websites」,升级3.X后,直接访问应用的域名,还是会跳「/dashboard」直接404了。
如果一直是PostgreSQL的话,跨大版本升级正常应该没问题,怕的就是不正常嘛。如果真的对历史数据非常在意的话,升级前常规的备份预防手段还是应该要做的,毕竟不怕一万,只怕万一。我之前从1.x升级到2.x,主要是部署方式都变了,从docker compose的一体化部署方式变成了linux容器部署Umami服务端+docker部署POstgreSQL的分离式部署,所以才瞎折腾了半天。不过,关键还是对历史数据到底有没有那么在意的问题,不在意的话,一年的数据足够用了,这种情况下Umami Cloud托管的方式就最省心了。