Heroku

为什么选择 Heroku？

当工程时间的成本高于基础设施抽象的成本时，Heroku 的价值最为突出。它将应用构建、进程管理、路由、证书、运行时补丁、日志记录、版本发布以及许多运维任务打包成一个统一的平台工作流。

这使得小型团队无需设计虚拟网络、配置负载均衡器、维护基础镜像、运行容器集群或构建自定义部署系统，即可部署生产环境应用。作为代价，用户对底层基础设施的控制力会有所降低，且单位成本高于许多原始算力服务。

Heroku 的进程模型异常稳定。Web 服务器、后台任务、调度程序、数据库迁移和一次性管理任务都遵循相同的发布和配置系统。随着应用的增长，这减少了团队必须维护的运维模式数量。

该平台并非 AI IDE 或编码 Agent。它在 AI 开发栈中的角色是托管由编码助手生成的模型 API、检索服务、Agent 后端、异步任务、连接 MCP 的工具以及其他应用程序。

核心工作流

标准的 Heroku 部署始于应用源代码和依赖清单。Heroku 会自动检测语言、选择合适的 Buildpack、安装依赖、创建可部署构件并启动应用声明的进程。

应用也可以作为 Docker 镜像交付。当运行时需要特定的操作系统软件包、自定义构建序列或需要与现有容器工作流保持一致时，这种方式非常有用。如果官方支持的 Buildpack 已能满足应用需求，基于源码的部署仍然是更简单的选择。

运行时配置通过配置变量（Config Vars）保存在代码仓库之外。每次部署都会将构建构件与当前配置结合，生成一个不可变的发行版（Release）。因此，团队可以在不修改源代码的情况下更改凭据、功能开关或外部服务端点，尽管更改配置变量会触发新版本的发布并通常会重启应用。

Procfile 将应用划分为不同的进程类型。一个典型的系统可能会使用 web 进程处理 HTTP 流量，使用一个或多个 worker 进程处理队列，使用调度程序执行定期任务，并使用发布进程（Release Phase）进行数据库迁移。每种进程类型都可以独立扩展。

对于使用 GitHub 的团队，Heroku Pipelines 可以连接开发、预发布和生产环境应用。Review Apps 可以为每个拉取请求（PR）创建一个临时环境，而 Heroku CI 则在与部署运行时高度相似的环境中执行测试。Review Apps 和 CI 资源像其他临时 Heroku 资源一样计费，因此自动清理策略非常重要。

适用场景

Heroku 非常适合传统的 Web 产品，即应用团队希望掌握代码和架构，但不愿管理容器平台。SaaS 应用、内部服务、REST API、GraphQL API、Webhook 处理程序、管理系统和后端服务都能自然地融入其进程模型。

后台处理是一个特别强悍的用例。Web 流量和队列消费者可以使用相同的源码版本和配置作为独立的进程类型运行。团队可以独立扩展 Worker 能力，而无需创建另一个部署环境。

对于运营多个客户应用的开发机构和咨询团队来说，Heroku 也很实用。共享部署模型减少了项目间的运维差异，而流水线和应用级协作使管理访问权限和发布变得更加容易。

对于 AI 应用，Heroku 可以托管聊天后端、检索增强生成（RAG）服务、编排 API、工具服务器、评估任务和异步文档处理任务。Heroku Managed Inference 和 Agents 为支持的模型和 Agent 能力提供了更集成的路径，而 MCP 支持则实现了面向工具的工作流。

如果应用需要持久性本地磁盘、特权容器、自定义内核行为、专用加速器、不受限的 Kubernetes 资源或对网络和实例部署位置的精细控制，则 Heroku 较不适用。

Fir 的定位

Fir 是 Heroku 的下一代平台，采用了云原生技术，包括 Cloud Native Buildpacks 和基于 Kubernetes 的运行时。它提供更明确的 CPU 和内存配置、专用计算资源、区域内构建和遥测，并为未来平台开发奠定了现代基础。

截至核实日期，Fir Dynos 需要 Fir 世代的 Private Space。这使得 Fir 目前最适合那些已经在评估私有网络或企业级部署的组织，而非 Common Runtime（公共运行时）中的低成本个人应用。

Cedar 和 Fir 使用的构建系统并不相同。Cedar 应用通常使用传统的 Heroku Buildpacks，而 Fir 应用使用 Cloud Native Buildpacks。在迁移前，应检查自定义传统 Buildpack、插件、网络假设、观测工具和发布行为。

Heroku 建议在支持 Fir 的地区为新项目和活跃开发的项目选用 Fir，但 Cedar 仍会持续受到支持。团队应评估实际的功能对等情况，而不是将其视为简单的技术栈升级。

竞品对比

Render 遵循类似的托管服务模式，支持 Web 服务、Worker、定时任务、数据库和预览环境。对于新项目，它可能感觉更现代且价格更亲民；而 Heroku 则拥有更悠久的生态系统、成熟的发布模型和更深厚的企业服务历史。

Railway 提供了高度可视化的开发体验，采用按需计费的基础设施，并能轻松部署关联服务。它对原型开发和小型团队很有吸引力，而 Heroku 则提供更正式的流水线、应用生命周期规范和企业级治理。

Fly.io 通过全球分布的 Machines 和私有网络暴露了更多的基础设施行为。当地理位置部署和机器生命周期是产品级需求时，它更为理想。如果团队希望主要关注应用进程而非虚拟机，Heroku 会更简单。

Northflank 结合了容器部署、环境、任务、数据库和交付自动化。它提供了更多面向容器的编排选项，而 Heroku 提供的是更具倾向性的进程模型以及庞大的 Buildpack 和插件遗产生态。

Google Cloud Run 是无状态、请求驱动型容器的强力替代方案，支持缩减至零。它与 Google Cloud 深度集成，但需要团队自行组装更多的数据库、网络、访问和交付架构。

DigitalOcean App Platform 在 DigitalOcean 生态内提供托管的源码和容器部署。对于简单的工作负载，它的性价比很高；而 Heroku 则提供更成熟的工作流规范和企业部署选项。

最佳配置建议

生产环境应用应设计为一组无状态进程。写入 Dyno 内部的文件会在 Dyno 重启或更换时消失，且不会与其他 Dyno 共享。因此，用户上传的文件和生成的资产应发送到对象存储，而非存储在本地文件系统中。

Web 进程应快速启动，绑定到环境提供的端口，响应终止信号，并避免在内存中保留核心状态。耗时较长的任务应移至由队列驱动的 Worker，而不是阻塞 HTTP 请求。

使用发布进程（Release Phase）执行数据库迁移、模式检查和其他必须在新代码上线前完成的任务。如果发布命令失败，新构建将不会被部署，从而降低了代码与不兼容数据库模式匹配的风险。

为开发、预发布和生产环境保留独立的应用。通过流水线（Pipeline）晋升相同的编译版本，而不是为每个环境独立重新构建。这减少了由依赖解析或构建时变化引起的差异。

为了可靠的生产部署：

• 明确锁定语言和依赖版本。
• 尽可能使用维护良好的官方 Buildpack。
• 将应用日志发送到标准输出（stdout）和标准错误（stderr）。
• 将机密信息存储在配置变量或经批准的外部机密管理器中。
• 在上线前配置应用和数据库监控。
• 在重视可用性时，至少运行两个 Web Dyno。
• 在接近生产环境的副本上测试数据库迁移。
• 仅在确认新旧版本可以安全共存后才启用 Preboot。
• 自动删除过期的 Review Apps 和未使用的插件。
• 统一追踪 Dyno、数据库、CI、Review App 和插件的成本。

托管 Postgres 方案的选择应基于停机容忍度、存储空间、连接数、内存、副本、回滚和高可用需求，而非仅看数据库大小。Essential 方案适用于小型、容忍中断的项目，而生产系统可能需要 Advanced、Premium、Private 或 Shield 能力。

迁移备注

迁移到 Heroku 通常需要将应用适配为无状态、环境配置的进程模型。本地文件系统上传、硬编码端口、Web 请求中的后台任务、手动管理的环境文件以及特定服务器的 cron 任务在部署前都应重新设计。

从传统 VPS 迁移的应用应将运行时配置与源代码分离，通过流式传输日志而非写入永久日志文件，将计划任务移至调度程序或 Worker，并将持久化数据发送至外部服务。

基于 Docker 的迁移可以保留更多现有的构建环境，但 Heroku 仍会控制运行时行为。镜像必须符合 Heroku 的容器要求，监听分配的端口，不依赖持久容器存储，并支持 Container Registry 接受的架构。

从 Cedar 迁移到 Fir 的团队应盘点 Buildpack、技术栈软件包、插件、DNS 行为、私有网络、指标、日志流（Log Drains）、发布命令和 CI 集成。在切换生产流量前，应在独立应用或空间中验证 Fir 迁移。

Heroku-22 已被弃用，并计划于 2027 年 4 月 30 日停止支持。仍在使用该技术栈的应用应尽早测试 Heroku-24 或 Heroku-26，特别是当应用依赖原生包、二进制库、无头浏览器、图像处理工具或自定义 Buildpack 时。

如果应用遵循 “Twelve-Factor” 原则，那么在代码层面离开 Heroku 通常很简单，但托管服务的依赖项仍需规划。数据库备份、插件数据、配置变量、域名、证书、计划任务、日志流、流水线设置和 Buildpack 行为都必须在目标平台上重建。

最具移植性的 Heroku 架构应保持应用代码独立于私有插件 API，使用标准的 PostgreSQL 或 Redis 兼容客户端，将文件存储在专用对象服务中，并在 Dashboard 之外记录每一个外部依赖项。