教程 搜索 / 发布与基础设施 / 部署到 Fly.io
📝 文字 ● 中级 更新于 2026-05-13

如何从 LingCode 部署到 Fly.io?

TL;DR:先运行一次 fly auth login,再运行 fly launch 在项目中生成 fly.toml,然后 fly deploy 即可完成部署。Fly.io 会自动将你的 Docker 容器分发到 30+ 个地区——按 CPU 秒计费。

Fly.io 让 Docker 容器同时运行在全球 30 个城市。你提供镜像,fly deploy 自动将其部署到离用户最近的地方。比 VPS 省心,比普通 PaaS 更可控——是让"默认全球化"变得廉价的唯一主流选择。

传统云平台各有侧重。Heroku/Render/Railway 屏蔽了基础设施细节:部署简单,但你无法控制运行位置。DigitalOcean 的裸 VPS 则把一切暴露给你:你可以自由选择机器和地区,但 OS、进程管理、重启和扩容全要自己搞定。这两种模式对很多项目都够用,但都不太适合"我想让应用就近服务悉尼、圣保罗和法兰克福的用户,同时又不想学 Kubernetes"的场景。

Fly.io 的理念是"以容器为基本单元"。你给它一个 Docker 镜像(或者直接提供 Dockerfile 让它帮你构建),它就用名为"Machines"的轻量级 Firecracker 虚拟机在 30+ 个地区运行,按秒计费。你选择部署到哪些地区;Fly 的 fly-replay 请求头允许一个请求在某个地区落地后,再转发到另一个地区。原本只运行在某个城市一台服务器上的应用,变成了"用户在哪个地区出现,就在那里启动一个小进程"。

代价是,这套机制比大多数 PaaS 的概念复杂得多。你需要编写 fly.toml,考虑机器规格和扩容规则,如果需要持久化状态还得配置 volumes。定价基于按秒计费的计算资源、存储和带宽——可预测,但变量比 Render 的固定月费更多。对于需要全球覆盖或容器级别控制的项目,这些代价是值得的。但如果你只是想"部署一个 Next.js 站点,别让我多想",Vercel 更简单。

你将学到什么

第一步:安装 flyctl

1

Mac 上一条命令搞定

brew install flyctl
# 或:
curl -L https://fly.io/install.sh | sh

然后一条命令完成注册与鉴权:

fly auth signup    # 或:如果已有账号,运行 fly auth login

浏览器会打开 OAuth 流程。授权完成后,本地 CLI 会保存 token。Fly 要求在部署任何内容之前,必须先在控制台绑定支付方式(即使是在慷慨的免费额度期间)——请在控制台中添加。

第二步:确保你的应用可以 Docker 化

2

能在本地 Docker 跑起来,Fly 就能在生产环境跑起来

Fly 的部署单元是容器镜像。你可以选择:

  • 提供 Dockerfile——Fly 在部署时帮你构建。
  • 直接提供预构建镜像——指向 ghcr.io/you/myapp:latest 或类似地址。
  • 使用 buildpack——fly launch 能自动识别常见技术栈(Node、Python、Go、Rails)并生成 Dockerfile。

对大多数项目而言,在代码旁边写一个 Dockerfile 即可。只要应用能在本地以正确的端口通过 docker run my-image 运行,Fly 就能部署它。

第三步:fly launch

3

交互式首次部署

在项目根目录运行:

fly launch

向导会询问:应用名称(必须全局唯一)、主地区(开发时选离你最近的)、组织(默认使用你的个人组织),以及是否要一同创建 Postgres 或 Redis 实例。第一次部署时,建议跳过数据库选项,后续可随时添加。

Fly 会在项目中生成 fly.toml,构建镜像(如有需要),并询问是否立即部署。选是。大约一分钟后,你的应用就会上线,地址为 https://<app-name>.fly.dev

fly.toml 文件是你的部署配置:应用名称、主地区、构建设置、环境变量、服务及其端口、扩容参数。它应该被提交到 git;团队成员运行 fly deploy 时会使用完全相同的配置。

第四步:迭代部署

4

标准发布节奏

后续部署只需一条命令:

fly deploy

这会重新构建镜像(或者如果你指定了远程镜像,则推送新镜像),用新镜像创建新的 Machines,将流量切换到新实例,再销毁旧的 Machines。默认部署策略是"滚动更新"——对无状态应用实现零停机。

fly status 查看部署状态,用 fly logs 实时查看日志。需要进入应用 shell 时,fly ssh console 可以在运行中的 Machine 上打开一个 shell。

第五步:添加地区

5

一条命令实现全球化

初始部署会在主地区放一台 Machine。添加更多地区:

fly scale count 3 --region iad,fra,syd
# 3 台机器,分别在 Ashburn / Frankfurt / Sydney

Fly 的 anycast 路由会将每位用户的请求发送到最近的健康 Machine。对于无状态应用(大多数 Web 服务器和 API),开箱即用。对于有状态应用,你需要考虑哪个地区拥有可写数据库——Fly 的 fly-replay 请求头是官方推荐的解决方案。

第六步:绑定自定义域名

6

两条 DNS 记录加一个 Fly 命令

fly certs create mydomain.com

Fly 会告诉你需要添加哪些 DNS 记录——通常是一条指向 Fly anycast IP 的 A 或 AAAA 记录,以及一条用于验证的 _acme-challenge CNAME。在你的 DNS 服务商处添加这些记录。几分钟后,Fly 会验证域名、签发 Let's Encrypt 证书,你的应用就能通过自定义域名以 HTTPS 访问了。

第七步:何时不该用 Fly

7

三种真实情况

  • 你想要一条命令部署、零配置。Vercel 适合 Next.js,Railway 适合各种栈——两者的上手复杂度都低于哪怕最简单的 fly.toml。Fly 的复杂性只有在你真正用到那些功能时才值得。
  • 你不需要多地区部署。大多数应用在一个地区就够了。如果你的也是,Fly 的地理优势就用不上——而 DigitalOcean 可预测的月费账单更简单。
  • 你的应用不适合 Docker 化。如果你搞不定一个能用的 Dockerfile,用 Fly 会很痛苦。改用 Render 或 Railway,它们对非 Docker 技术栈的支持更好。
有状态比无状态难得多。Fly 的 Machines 有本地 volumes,但它们是绑定到特定地区的——Sydney 的 Machine 访问不到 Ashburn 的 volume。对于数据库,建议使用 Fly Postgres(他们的托管方案),或者更常见的做法是接入外部托管数据库(Neon、Supabase、PlanetScale)。除非你真的清楚自己在做什么,否则不要尝试在裸 volumes 之上自建多地区存储。

接下来