仅欧洲替代方案 Fly.io.

Fly.io（“Fly”）是一家总部位于美国的边缘计算平台，在包括阿姆斯特丹、法兰克福、巴黎、马德里和斯德哥尔摩的 30 多个地区运行 Firecracker microVM。Fly Inc. 是一家特拉华州公司，其欧盟地区在地理位置上位于欧盟境内，但受美国控制，CLOUD Act 适用于该公司。Fly 的技术方案（边缘 microVM、近乎即时冷启动、简单的 `fly deploy`）确实具有创新性；用主权欧盟技术栈取代它，意味着要用固定区域部署或在欧盟基础设施上自行搭建的等效方案，来替换这种特定的多区域边缘模式。

美国仅限 EU 的替代技术栈 10 已梳理的服务

预约通话先扫描您的域

供应商: Fly.io
总部: Chicago, IL
司法管辖区: 美国
法律制度: CLOUD Act, FISA 702

"欧盟区域"不等于主权。四个问题决定一切。

数据驻留告诉你数据存放在哪里。主权则告诉你哪个法律体系可以强制访问。这四点的答案必须都成立 - 否则该技术栈就不具备主权性。

驻留

数据物理存储在哪里?

不只是笼统的“在云端” - 而是具体在哪个数据中心、哪个国家、受哪种司法管辖。

次级处理者

您的数据路径中还有谁?

每一个接触数据的供应商:CDN、邮件中继、错误追踪、分析管道。

司法管辖区

哪些法律可以强制披露?

总部位于美国的提供商受 FISA 702 和 CLOUD Act 管辖 - 即使数据存放在法兰克福也不例外。

密钥托管

谁实际持有加密密钥?

如果云服务商同时持有数据和密钥，无论签订何种 DPA，数据对其而言都是可读的。

失败 AWS · Azure · GCP · EU 区域

在司法管辖权和密钥托管上失败。

欧盟数据、美国母公司、默认路径中的美国次级处理者、供应商管理的密钥。

通过 Binadit 托管技术栈

四项全部通过。

托管在欧盟、由欧盟总部基础设施提供。默认路径中零美国次级处理者。客户持有或欧盟 KMS 密钥。在您的第 28 条 DPA 中按名称列出。

为什么团队正在退出 Fly.io

我们已评估的 Fly.io 迁出案例来自受监管的工作负载（医疗 SaaS、金融科技），这些场景中多区域边缘模式是“有则更好”，但美国司法管辖下的处理方成为了阻碍。对这些工作负载来说，实话是：大多数并不真正需要 30 个地区，它们需要的是 2-3 个低延迟的欧盟地区。我们的两个欧盟地区就能满足该需求，再配合像 Bunny.net 这样的 CDN 处理静态资源，两者共同为欧盟用户提供低于 50 毫秒延迟且完全处于欧盟司法管辖范围内的服务。

Fly.io 服务及其仅欧盟等效方案

迁移不是"换一个盒子"。下面的映射是我们为离开以下平台的客户运行的 Fly.io 基于 Schrems II 的考量 - 完全适用欧盟司法管辖，数据链路中不涉及美国母公司。

Fly.io 服务	我们改用什么	工程说明
Fly Machines (microVMs)	Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。	对于大多数工作负载，配合 DNS GeoIP 实现多区域部署的常规 VM 即可满足需求。如需真正的按请求独立 microVM，在欧盟计算资源上自托管 Firecracker 才是主权化方案。
Fly Apps (PaaS layer)	Binadit 托管云平台。在 GitLab CI 中构建 Docker 镜像并部署到 Kubernetes，为每个分支提供审查环境。	Coolify 的多服务器功能可支持多区域部署模式。
Fly Postgres (clustered)	Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。	在欧盟计算资源上运行 Patroni 是一种开源方案，也是 Fly 自家 Postgres 服务背后所采用的模式。
Fly Redis (Upstash)	Binadit 托管云平台。Redis 或 Valkey，配合 Sentinel 实现故障转移。	注意：Upstash 本身总部位于美国，因此 Fly Redis 属于美国对美国的架构。
Fly Volumes	Binadit 托管云平台。Ceph RBD，或使用 Longhorn 实现 Kubernetes 原生存储卷。	基于 NVMe 的标准存储卷；容量相当。
Fly Proxy (Anycast)	Binadit 托管云平台。HAProxy 或 Nginx，配合 keepalived 实现故障转移。	健康检查、连接排空（connection draining）和会话保持（sticky sessions）均可延续。TLS 在此终止，证书自动续期。
Fly Postgres failover (multi-region)	Binadit 托管云平台。由 Patroni 管理跨节点的 PostgreSQL 故障转移，支持自动提升。	对于仅限欧盟的多区域部署（例如荷兰 + 德国双活并具备区域故障切换），Patroni 可以胜任。
Fly Secrets	Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。	对于任何非简单的密钥管理工作负载，Vault是生产级的解决方案。
flyctl / fly deploy DX	Binadit DevOps 与支持服务。kubectl、Terraform 和 GitLab CI，在有帮助的地方使用项目专属封装工具。	开发体验（DX）上的差距是真实存在的，但可以弥补。Coolify 的 `coolify deploy` 是最接近的替代方案。
Fly LiteFS (replicated SQLite)	Binadit 托管云平台。PostgreSQL 配合只读副本，或在真正适合 SQLite 模型的场景使用 Litestream。	对于读多写少的单写入者应用，复制型 SQLite 是一种简洁的方案。而在写入路径存在竞争的场景下，PostgreSQL 是更安全的落地选择。

Fly Machines (microVMs)

我们改用什么: Binadit 托管云平台。基于 Debian 或 Ubuntu 的 KVM 虚拟机，使用 Terraform 供给资源，通过 Ansible 配置。
工程说明: 对于大多数工作负载，配合 DNS GeoIP 实现多区域部署的常规 VM 即可满足需求。如需真正的按请求独立 microVM，在欧盟计算资源上自托管 Firecracker 才是主权化方案。

Fly Apps (PaaS layer)

我们改用什么: Binadit 托管云平台。在 GitLab CI 中构建 Docker 镜像并部署到 Kubernetes，为每个分支提供审查环境。
工程说明: Coolify 的多服务器功能可支持多区域部署模式。

Fly Postgres (clustered)

我们改用什么: Binadit 托管云平台。PostgreSQL 或 MySQL 配合 Patroni 实现故障转移，pgBackRest 实现时间点恢复。
工程说明: 在欧盟计算资源上运行 Patroni 是一种开源方案，也是 Fly 自家 Postgres 服务背后所采用的模式。

Fly Redis (Upstash)

我们改用什么: Binadit 托管云平台。Redis 或 Valkey，配合 Sentinel 实现故障转移。
工程说明: 注意：Upstash 本身总部位于美国，因此 Fly Redis 属于美国对美国的架构。

Fly Volumes

我们改用什么: Binadit 托管云平台。Ceph RBD，或使用 Longhorn 实现 Kubernetes 原生存储卷。
工程说明: 基于 NVMe 的标准存储卷；容量相当。

Fly Proxy (Anycast)

我们改用什么: Binadit 托管云平台。HAProxy 或 Nginx，配合 keepalived 实现故障转移。
工程说明: 健康检查、连接排空（connection draining）和会话保持（sticky sessions）均可延续。TLS 在此终止，证书自动续期。

Fly Postgres failover (multi-region)

我们改用什么: Binadit 托管云平台。由 Patroni 管理跨节点的 PostgreSQL 故障转移，支持自动提升。
工程说明: 对于仅限欧盟的多区域部署（例如荷兰 + 德国双活并具备区域故障切换），Patroni 可以胜任。

Fly Secrets

我们改用什么: Binadit 托管云平台。自托管的 HashiCorp Vault 或 Infisical，支持自动租约轮换。
工程说明: 对于任何非简单的密钥管理工作负载，Vault是生产级的解决方案。

flyctl / fly deploy DX

我们改用什么: Binadit DevOps 与支持服务。kubectl、Terraform 和 GitLab CI，在有帮助的地方使用项目专属封装工具。
工程说明: 开发体验（DX）上的差距是真实存在的，但可以弥补。Coolify 的 `coolify deploy` 是最接近的替代方案。

Fly LiteFS (replicated SQLite)

我们改用什么: Binadit 托管云平台。PostgreSQL 配合只读副本，或在真正适合 SQLite 模型的场景使用 Litestream。
工程说明: 对于读多写少的单写入者应用，复制型 SQLite 是一种简洁的方案。而在写入路径存在竞争的场景下，PostgreSQL 是更安全的落地选择。

我们如何迁移离开 Fly.io

典型的中端市场迁移分为三个阶段进行。以下数据假设工程团队规模为 6-10 人，应用程序技术栈复杂度中等。

第 1-3 天

Region策略决策

审计您实际使用的 Fly 区域，以及哪些区域承载真实流量。对大多数面向 EU 客户的应用而言，2-3 个 EU 区域即可覆盖；对全球化应用，需确定多区域方案（DNS GeoIP、Anycast、区域故障转移）。
第 4-10 天

数据库 + 存储迁移

Fly Postgres 复制到欧盟托管 PostgreSQL 或 Patroni 集群。卷进行镜像同步。密钥迁移至 Vault。
第 2-4 周

应用切换

应用已在 Binadit 上的 Kubernetes 重新部署。如需多区域支持，DNS 将迁移至 GeoIP 路由。验证窗口期结束后，Fly 账户将被注销。

从Fly迁出的5年TCO差异比其他美国云迁出项目更大，因为Fly的计费模式较为特殊（按秒计费的microVM）。对于稳态工作负载，欧盟基础设施的成本明显更低。而对于具有长时间空闲期的高波动性工作负载，若没有支持scale-to-zero的容器平台，欧盟主权基础设施很难在成本上与Fly的scale-to-zero能力相匹敌。

常见问题

查看所有常见问题

Fly 所宣传的“无监控”，这真的意味着主权保障吗？

Fly.io 一直坦承自己未列入美国超大规模云服务商的关键基础设施监控名单。但这是一个运营层面的声明，而非司法管辖层面的声明。作为一家美国特拉华州公司，无论 Fly 如何进行市场宣传，其都受 CLOUD Act 约束。其法律风险与任何其他受美国司法管辖的服务商相同。

我们如何替代“microVM 冷启动”功能?

对于大多数工作负载而言,microVM 冷启动更多是一个附加优势,而非硬性需求。如果你确实需要它,基于 EU compute 自建 Firecracker(与 Fly 所使用的技术相同)是可行路径。我们会为有特定 microVM 需求的客户部署这一方案。

用于边缘 SQLite 的 LiteFS 怎么样？

LiteFS 是开源的。可在欧盟计算资源上自行托管，并配置多区域复制。由于 LiteFS 底层使用标准 SQLite，迁移过程大多是机械性的。

Fly.io 迁移退出需要多长时间?

对于典型工作负载(几个应用、一个 Postgres 集群、若干存储卷):耗时2-4周。对于采用 Anycast 和 LiteFS 的多区域架构:4-8周。最大的进度风险在于复现多区域架构模式,而非技术工作本身。

是否存在真正类似 Fly 的欧盟选项？

在欧盟主权云领域,目前还没有完全对等的方案。最接近的组合是 Coolify 多服务器 + DNS GeoIP 路由 + 欧盟托管 Postgres。它不像 Fly 的集成体验那样精致,但它是主权的,并且在运维上更简单,代价是牺牲了一些开发者体验(DX)。

Fly 的 GPU 服务怎么样？

Fly 的 GPU 实例（A10、L40S）在推理工作负载上具有竞争力。对于当前代 GPU 计算，专用欧盟 GPU 硬件是主权替代方案。对于较旧的代次，欧盟专用 GPU 硬件在价格上具有竞争力。

规划您的退出 Fly.io.

30 分钟范围确定通话。我们将您的技术栈映射到仅欧盟替代方案,估算迁移工作量,并告诉您这是否是正确的选择。

预约通话对比其他服务商