一台名为 Mercury 的服务器：从 Heroku 到自建 PaaS 的回归

背景

在云原生和 Serverless 架构大行其道的今天，开发者往往被引导至 AWS、Azure 或 Google Cloud 等巨型云平台，或者使用 Heroku、Vercel 等托管服务。这种趋势的核心逻辑是“抽象”：通过层层抽象屏蔽底层基础设施的复杂性，让开发者专注于业务代码。

然而，这种便利性背后隐藏着成本失控、供应商锁定（Vendor Lock-in）以及平台政策突变的风险。作者 Kenneth Reitz 曾是 Heroku 的核心工程师，亲历了该平台从“开发者友好”到“商业化优先”的转变。本周，他购买了一台来自 Hetzner 的独立服务器，命名为 mercury，并决定将个人所有的网站和服务迁移至此。这不仅仅是一次基础设施的迁移，更是一次对“部署即正义”这一理念的重新审视，以及对开源、可控、低成本计算环境的回归。

核心内容

1. 部署体验：被遗忘的 UX 重要性

作者回顾了在 Heroku 工作的经历，指出 Heroku 最伟大的贡献在于它将“部署”从一种负担转变为创作过程的一部分。git push heroku main 不仅是一条命令，更是一个承诺：你只需提交代码，平台负责其余一切。

然而，随着行业进步，部署的复杂度反而增加了。YAML 配置、Ingress 控制器设置、Dashboard 的反复跳转，这些额外的步骤构成了“创建冲动税”（tax on the impulse to create）。作者强调，部署的用户体验（UX）是软件开发中最重要的 UX 之一。从“做出一个东西”到“它在 URL 上运行”之间的距离，是大多数副项目夭折的地方。Heroku 在 2009 年理解了这一点，而行业随后却通过增加步骤来所谓的“进步”。

2. 技术选型：Dokploy 与 Docker Compose 的回归

在 mercury 服务器上，作者选择了 Dokploy 作为核心平台。Dokploy 是一个开源的 PaaS（平台即服务），被视为 Heroku 精神的开源继承者。

• 原生支持 Docker Compose：这是说服作者的关键特性。Dokploy 不是将 docker-compose.yml 视为二等公民或仅作为导入的 shim，而是将其视为一等公民的部署单元。
• 基础设施即代码（IaC）的直观体现：作者的照片网站包含 Django 应用、Celery 工作进程和 Postgres 数据库，整个生产拓扑结构仅由仓库中的一个 compose.prod.yml 文件定义。
• 可维护性与可追溯性：对于拥有二十年经验的开发者来说，记忆基础设施细节是不现实的。将基础设施定义为仓库中的文本文件，使其具备版本控制、可审查性，且本地与生产环境保持一致。这种“真理单一来源”极大地降低了认知负荷。

3. AI 驱动的迁移：Claude Code 的角色

这次迁移并非由作者手动完成，而是主要由 Claude Opus 4.8（通过 Claude Code 运行）协助完成。这展示了 AI 在 DevOps 领域的成熟应用：

• 自动化流程：AI 通过对话交互，逐一处理应用迁移。它通过 Dokploy API 创建项目和应用，生成部署密钥并集成到 GitHub，配置 Webhook 实现自动部署。
• 数据迁移与 DNS 管理：AI 从旧主机导出生产环境的 Postgres 数据库并在 mercury 上恢复，甚至直接通过 DNSimple API 更新 DNS 记录。
• 故障排除：当照片网站的 Celery 工作进程因 psycopg2 与 psycopg3 版本不匹配而崩溃循环时，AI 读取堆栈跟踪，修复了 Broker URL，并解释了 compose 文件中的错误。
• 效率对比：过去需要团队花费数周完成的迁移（涉及六个站点、数据库、对象存储、证书和自动部署），如今在几个小时内由 AI 完成。尽管过程并非完美无缺，但具备“可恢复性”（recoverably），这意味着流程能够适应现实世界的复杂性。

4. 基础设施现状：自建服务的多样性

mercury 服务器目前运行着多种服务，形成了一个小型的“工作坊”：

• Glance：运行在 home.kennethreitz.org，用于监控服务器健康状态（CPU、磁盘）、展示文章订阅源、镜像 iCloud Drive 以及管理书签。这是一个面向“一人受众”的状态页。
• Gitea：运行在 git.kennethreitz.org，每八小时镜像作者所有的约 300 个 GitHub 仓库。GitHub 仍是主源，但本地镜像提供了数据保险。记录服务器配置的仓库也托管在该服务器上，形成了自引用的闭环。
• Umami：替代了之前的 Gauges。由于 Gauges 被再次出售，作者转向了开源、无 Cookie 追踪的 Umami。所有站点的数据汇总到一个仪表盘，数据存储在作者自己的磁盘上，避免了第三方资产被收购的风险。

5. 对现代云平台的批判性反思

作者提出了一个关于现代云平台的理论：平台最初为了吸引开发者而提供极致的愉悦体验（Delight），但当用户基数足够大后，平台的真正客户变成了“财务报表”（Spreadsheets）。

• 从用户到报表：平台开始优化“可持续性”，这往往意味着削减免费额度、取消补贴、按秒计费。
• 价值观的背离：曾经为深夜灵感而建的友好平台，最终变成了为那些从未部署过代码、只关注资本回报的群体服务的工具。
• 选择权：开发者可以选择运行在优化自身生存的平台之上，成为他人可持续性故事中的舍入误差；或者选择运行在一台名为罗马神祇、月费低于午餐费、由开源工具构建的小机器上。后者虽然需要一定的维护，但它完全属于开发者自己，不受外部资本波动的影响。

关键要点

• 部署 UX 的核心地位：部署流程的复杂度直接决定了开发者的创作意愿。简化从代码到 URL 的路径是降低副项目失败率的关键。
• Docker Compose 作为基础设施真理：使用 docker-compose.yml 作为部署单元，实现了基础设施的版本控制、可审查性和环境一致性，解决了长期记忆基础设施配置的难题。
• AI 在 DevOps 中的实战能力：AI（如 Claude Code）能够处理复杂的迁移任务，包括 API 调用、数据迁移、DNS 配置甚至故障排查，极大地提升了运维效率，使个人开发者具备了过去需要团队才能完成的迁移能力。
• 数据主权与供应商锁定风险：依赖第三方托管服务（如 Gauges）存在资产被收购或政策突变的风险。自建或采用开源方案（如 Umami、Gitea）能确保数据和控制权掌握在自己手中。
• 云平台的商业化悖论：现代云平台往往在获得足够用户后，从“开发者友好”转向“利润导向”，导致用户体验下降和成本上升。自建服务器提供了一种规避这一风险的替代方案。
• 低成本与高自主性的平衡：通过 Hetzner 等廉价 VPS 提供商结合开源 PaaS（如 Dokploy），开发者可以以极低的成本获得高度可控、无供应商锁定的计算环境。

意义与影响

这篇文章不仅是个人技术博客，更是对当前云计算行业趋势的一种温和而坚定的抵抗。它揭示了在云巨头垄断和 SaaS 化浪潮下，开发者面临的隐性成本：不仅是金钱，更是控制权的丧失和创造力的受阻。

1. 对开发者心态的重塑 作者提倡的“Don't panic. Self-host.”（别慌，自建）并非要求所有人抛弃云，而是提醒开发者重新评估“便利性”的代价。它鼓励开发者在享受云服务红利的同时，保留自建基础设施的能力，以应对平台政策突变或成本激增的风险。

2. 开源 PaaS 的价值重估 Dokploy 等开源 PaaS 的兴起，证明了“Heroku 体验”可以在本地或私有服务器上复现。这为那些受够了云厂商“免费套餐日落”政策的开发者提供了可行的技术路径。它强调了开源工具在构建可持续、可预测的开发环境中的核心作用。

**3. AI 赋能的个体开发者崛起