Fly.io

为什么选择 Fly.io？

Fly.io 填补了全托管平台（PaaS）与底层基础设施之间的空白。应用被打包为容器镜像，但开发者可以直接控制机器规格、生命周期、进程布局以及地域分布。

当标准 PaaS 限制过多，而手动管理虚拟网络、负载均衡器、实例组和底层云权限又会带来不必要的开销时，这种模式非常有用。它的核心价值不仅在于部署的便捷性，更在于能够将全球分布的计算资源视为应用层的基础原语。

需要注意的是，Fly.io 并非 AI 编码助手或 IDE。它对 AI 开发的价值在于托管编码工具生成的 Agent 后端、API、推理网关、沙箱、队列等服务。对于新的 GPU 项目，建议使用其他供应商或查阅最新的迁移指南，因为 Fly.io 的官方定价文档已将 GPU 机器列为弃用状态，并计划在 2026 年 8 月 1 日后停止提供。

核心工作流

典型的部署从现有应用和 Dockerfile 开始。运行 fly launch 会检查项目、创建应用并生成 fly.toml 文件，该文件是服务、端口、健康检查、地域、挂载点、进程和扩缩容行为的版本化描述。

操作流程有意以 CLI 为中心：

1. 在本地构建或由 Fly.io 构建容器镜像。
2. 使用 fly deploy 进行部署。
3. 在代码库之外存储运行时的机密信息（Secrets）。
4. 监控日志、健康检查、指标和机器状态。
5. 根据流量变化调整机器规格、数量或地域分布。
6. 通过 GitHub Actions 或其他 CI 系统实现自动化部署。

这种工作流比“一键部署”的 PaaS 更明确。虽然这增加了配置工作，但也让基础设施决策在代码中清晰可见，且更易于在不同环境中复现。

对于平台构建者来说，Machines API 是一个重要的差异化特性。应用可以通过编程方式创建、停止、恢复、更新和销毁机器，而不仅仅是将其视为一种发布事件。这支持了诸如隔离的客户环境、临时代码运行器、开发工作空间、后台任务和按需分配的 Agent 沙箱等模式。

适用场景

Fly.io 非常适合全球访问的 API、Websocket 服务、多玩家协作服务、开发者工具以及需要将计算资源置于用户附近以降低网络延迟的应用后端。

对于每个客户或任务需要独立隔离运行环境的产品，它同样实用。机器可以作为一次性执行单元进行管理，而私有网络则能将内部服务与公网隔离。使用此模式的团队仍应设计严格的租户隔离、机密边界、资源限制和防滥用控制，而不是假设基础设施边界能解决所有应用层风险。

低流量服务可以利用自动启停（autostop/autostart）功能来减少活跃计算费用。成本规划必须考虑 CPU 运行时间以外的项目：已停止机器的根文件系统、卷（Volumes）、快照、出站流量、超出额度的证书以及固定 IP 资源都可能产生费用。

状态化应用需要更多关注。Fly Volumes 是绑定在特定地域特定服务器上的本地 NVMe 存储，并非共享网络磁盘。一个卷只能挂载到一台机器，且数据不会自动同步到另一个卷。这适用于开发、缓存、可重建的状态或具有自身复制策略的应用，但不应将其误认为全托管的多地域存储。

竞品对比

与 Railway 相比，Fly.io 提供了更多关于地域分布、网络和机器生命周期的控制权。对于更看重简洁的项目仪表盘和托管服务流程，而非底层基础设施控制的团队，Railway 通常更易上手。

与 Render 相比，Fly.io 更接近可编程基础设施。Render 遵循传统的面向服务的 PaaS 模式，而 Fly.io 鼓励团队从机器、进程组、私有网络和明确的地域拓扑角度进行思考。

与 Heroku 相比，Fly.io 使用了更原生的 Docker 和基础设施感知操作模型。对于习惯了 Buildpacks、Dynos 和托管插件的团队，Heroku 依然更容易理解，但 Fly.io 为自定义网络和部署架构提供了更大的灵活性。

与 Google Cloud Run 相比，Fly.io 更适合需要长连接机器、自定义进程布局、私有网络或挂载本地卷的工作负载。对于应在托管 Serverless 模型下运行的无状态请求驱动型容器，Cloud Run 通常是更干净的选择。

对于希望在容器部署中集成流水线和环境管理的团队，Northflank 是一个更接近的选择。当直接的机器编排或地理位置分布是产品架构的核心时，Fly.io 更具吸引力。

最佳配置建议

生产环境的 Fly.io 配置应从无状态应用镜像和明确的主地域开始。将应用绑定到 fly.toml 中配置的内部端口 0.0.0.0，添加健康检查，并在启用激进的自动停止功能前确认优雅关机行为。

在重视可用性的场景下，请至少运行两台机器。单台机器对于开发或容错性高的服务是可以接受的，但会导致明显的单点故障和部署停机窗口。多地域部署应由实测的用户延迟和数据拓扑驱动，而不是盲目增加区域。

将持久化数据保持在容器根文件系统之外。如果应用不具备处理复制和故障转移的能力，请使用托管 Postgres 或其他托管数据库。仅在确实需要本地持久化时使用 Fly Volumes，并且即使启用了快照，也要保持独立的备份。

为了保障运行的可预测性：

• 将 fly.toml 随应用代码一起提交。
• 固定关键运行时和基础镜像的版本。
• 分离 Web、Worker、调度器和数据库迁移进程。
• 使用 Secrets，不要将环境文件提交到代码仓库。
• 在启用自动化重启或扩缩容之前配置好健康检查。
• 设置预算提醒，并检查存储、快照、网络和 IP 费用。
• 在生产 CI 工作流中固定 flyctl 的版本。
• 在更改关键生产拓扑之前，先在独立的应用环境中测试部署。

迁移建议

从 Heroku、Render 或 Railway 迁移应用通常不仅是更换部署命令。需要重新审查进程模型、监听地址、内部端口、文件系统假设、后台作业、发布命令、数据库连接和健康检查行为。

容器根文件系统是临时性的。任何写入其中的用户上传、生成的资产、SQLite 数据库或运行时状态都可能在重启或部署期间消失。在生产迁移之前，请将持久化数据移动到合适的卷、对象存储或托管数据库中。

迁移数据库的团队必须决定是使用托管 Postgres、外部供应商，还是在机器上自建数据库。最后一种方案提供了控制力，但会将备份、恢复、复制、升级、监控和事故响应的责任转移给应用团队。

网络方面也需要独立的迁移清单。出站 IP 地址默认不是静态的，跨地域私有流量可能会产生费用，依赖 IP 白名单的服务可能需要静态出口地址。在切换流量前，确认 DNS、证书颁发、代理请求头、Websocket 行为以及客户端 IP 处理逻辑。

当团队将部署拓扑视为应用设计的一部分时，Fly.io 的效果最为理想。如果团队期望的是一个完全透明、无感的托管层，可能会觉得该平台操作负担过重；而对于需要在不采用完整云堆栈的情况下获得可编程计算能力的团队来说，这种权衡是非常值得的。