Plausible、Umami 自部署怎么选？先算网站统计的维护成本

搜「Plausible 部署」或「Umami 部署」时，你可能只是想知道：网站有没有人看，访客从哪里来，哪篇内容能带来注册。先确定愿意承担多少维护工作，再选统计工具，往往比先照抄一份 Docker 配置更省时间。

如果你已经维护数据库、备份和服务器，自建值得评估。如果只是想每天打开报表看一次流量，托管服务能省掉一组长期维护任务。两种方式都可能划算，关键是把自己的时间也计入成本。

自部署实际要维护什么

Plausible 提供自行运行的 Community Edition；官方云服务与 CE 的更新、功能范围需要分别核对。不要把云版介绍里的每个功能自动当成自建版已有能力。安装应从 Plausible 官方自托管说明进入当前 CE 仓库，按对应版本准备服务和数据库。

Umami 的官方安装文档提供源码、Docker Compose 等方式，当前文档列出 PostgreSQL 数据库要求。它也需要数据库持久化、环境变量配置和应用更新。不要把旧教程中的数据库选项直接套到新版本。

不论选哪一个，都先回答这些问题：

• 持久化在哪里？ 容器重建后，历史访问记录是否还在？
• 备份由谁恢复？ 有备份文件不等于能够恢复到可用的仪表盘。
• 升级怎样验证？ 应用更新和数据库变更出问题时，有没有恢复路径？
• 统计断流谁发现？ 网站正常、统计服务挂掉，也会让数据悄悄缺一段。
• 谁管理访问权限？ 报表、共享链接、后台账号不能混着公开。

这些都是部署之后的工作。仅把网页打开一次，不能算统计系统已经交付。

用自己的数算一遍，而不是只比服务器月租

下面是一份可直接在浏览器控制台或 Node.js 运行的计算器。所有金额都是演示假设，不是任何服务商报价；把参数改成你自己的成本和实际订阅报价，再看结果。

const input = {
  serverPerMonth: 40,
  backupPerMonth: 10,
  maintenanceHoursPerMonth: 1,
  setupHours: 3,
  hourlyCost: 100,
  hostedPerMonth: 80,
};
const selfHostedYear =
  12 * (input.serverPerMonth + input.backupPerMonth) +
  (12 * input.maintenanceHoursPerMonth + input.setupHours) *
    input.hourlyCost;
const hostedYear = 12 * input.hostedPerMonth;
console.log({ selfHostedYear, hostedYear });
// 演示结果：{ selfHostedYear: 2100, hostedYear: 960 }

这里刻意没有把故障损失算进去，因为每个网站的数据价值不同，也没有把网站接入脚本的时间算作自建独有成本——托管同样需要接入。

如果服务器已有富余资源，且维护工作能被现有流程吸收，自建的增量成本会下降；如果每次升级都要临时查文档，工时可能比机器费用更高。托管报价还要核对站点数、流量限制、数据保留和可用功能，不能只拿首页最低价相比。

哪种情况更适合自建

团队已经有负责运维的人，能把数据库备份、升级验证和可用性监控并入日常工作，而且确实需要掌握实例配置或数据存储位置时，自建更有理由。

准备部署时按下面顺序做，比先把容器跑起来再补配置更稳妥：

1. 选择产品与发行版本，阅读该版本官方安装和升级说明。
2. 明确访问量、保留周期、磁盘容量及数据库备份位置。
3. 设置域名、HTTPS、后台访问和正式账号，修改默认凭据。
4. 先接一个测试站点，验证页面访问、来源和一个关键事件。
5. 做一次备份恢复检查，确认报表仍可读，再接正式站点。

具体资源配置要按产品当前版本和你的流量测算；本文不提供未经验证的「最低配承载百万 PV」承诺。

哪种情况更适合托管

如果团队的主要工作是写产品、写内容，而不是维护统计实例，可以评估不墨网站统计。它提供基于 Plausible 的托管服务，公开产品页说明了访客、来源、热门页面、设备地区和自定义事件等能力，并由平台负责部署、版本升级与运维。

这里指的是不墨提供的服务，不能把它等同于 Plausible 官方 Cloud 的套餐或功能承诺。公开页面没有展示本轮可核实的完整报价，具体套餐、配额与到期时间应在开通页面确认。数据导出、迁移和保留期限如果影响你的选择，也应在采用前核实。

接入主流程只有三步：

1. 登录产品页开通服务，在统计后台添加站点域名。
2. 复制该站点后台生成的统计脚本，粘贴到网站的公共页面模板。
3. 访问真实线上页面，检查实时访问和来源，再配置需要的事件。

不同版本的脚本格式可能不同，直接复制自己后台给出的整段代码，不要拿别人的域名、站点 ID 或脚本地址替换一半。具体框架位置可参考Hexo、Next.js、VuePress 接统计的教程。

最后验收的是数据，而不只是页面能打开

挑一篇新文章，用另一台设备访问，确认它出现在报表中；从你可控的外部测试链接进入，检查来源是否符合预期；再触发一次自定义事件，确认只记一次。浏览器拦截器、同意管理或脚本加载失败都可能影响结果，零访问首先应查浏览器请求。

比较自建与托管时，用同一个站点、同一段时间和相同指标口径测试。不同工具对访客、会话、机器人流量的定义可能不同，不能看到数字不一致就断言其中一个漏数。

如果你的目标只是稳定看到「哪篇文章把人带进产品」，先用托管网站统计跑通一个站点；如果维护成本已在团队能力范围内，就按官方部署文档建一个可备份、可恢复的实例。选择的标准是持续拿到可信数据所需的总投入。

相关阅读

• Hexo、Next.js、VuePress 接统计教程
• 接口健康检查与关键字监控
• Uptime Kuma 企业微信告警
• 小团队 RAG：托管还是自建
• 向量数据库选型指南

还没确定要看哪些数据，可先用网站访问量统计工具选型的六个问题核对访客口径、转化事件和开通验收。