关掉 Vercel 上的 Umami，把 13 个站的数据搬回自己服务器

我关掉了挂在 Vercel 上的 Umami。

Umami 是开源的网站分析，可以理解成隐私友好版的 Google Analytics，不种 cookie，不做跨站追踪。我用它看 13 个站的数据：个人博客、几个产品站。哪个页面有人看、流量从哪来、哪天突然涨了，全靠它。

这套东西之前跑在 Vercel 上，数据库放在 Neon。白嫖额度，跑得也稳，很长时间我都没多想。

搬家的念头不是一天形成的

第一件事是我想导历史数据。Umami 的数据全在 Postgres 里，但托管的数据库你只有一条连接串，备份、导出、盯慢查询，都得按人家的规矩来。我想要一份完整的本地备份，折腾半天，体验像在别人家书房借书。

第二件事是最近 Railway 出问题。同行的 PaaS，说抖就抖。我的第一反应不是看热闹，是照镜子：我的分析链路是 Vercel 跑应用、Neon 存数据，两环都在别人手里。任何一环改政策、砍免费额度、或者单纯出个故障，13 个站的仪表盘就一起黑屏。

免费 PaaS 的账，很多人只算钱。其实钱是最小的部分，真正的成本是：你的数据在别人的数据库里，长多大、放多久、怎么带走，都由不得你。

正好有台闲着的机器

我之前自托管过短链服务，前几天刚下线，那台 2C2G 的云服务器正好空出来。租金照付，资源闲着也是闲着，Umami 搬过去，边际成本为零。

新架构简单到有点过分：

• 一台 2C2G 云服务器，硅谷机房
• 两个 Docker 容器：Umami 官方镜像的 PostgreSQL 变体，加一个 postgres:17
• 前面挂 Caddy 做反代，自动 HTTPS

Umami 的全部状态都在数据库里，迁移就是标准的 Postgres 导出再导入。一晚上搞定，13 个站的历史数据一条不少。

自己托管之后才知道的事

托管的时候你只面对一个黑盒面板。自己接管数据库之后，才真正摸清它的脾气。举一个例子：Umami v3 的 API 有个怪癖，同一个统计字段，列表接口返回数字，详情接口返回字符串。写脚本对接的人迟早被坑一次。这种问题以前只能去 GitHub issue 里翻，现在我自己查库，一眼就知道是哪回事。

顺便说，Umami 自带团队功能，站点按团队分组管理，一个人管十几个站也不乱。迁移的时候团队结构原样保留，用起来零变化。

什么该自托管，什么不该

我不是自托管原教旨主义者。原型期、没有流量的周末项目，白嫖 Vercel 很香，没必要跟自己过不去。

我的判断标准就一条：如果这份数据明天突然消失，我会不会心疼。会心疼的，就不该放在一个我登不进数据库的地方。分析数据恰好是最典型的，它是有积累的，看三个月前的对比才有意义，丢了就是丢了，没法补。

想抄作业的，最小配置就是：一台最便宜的 VPS，Umami 官方的 compose 文件，改掉数据库密码，域名指过去。想更稳一点，参考我之前写短链那篇的思路，前面套一层 Cloudflare Tunnel，源站 IP 都不用暴露。