仅欧洲替代方案 Fly.io.

Fly.io ("Fly") is a US-headquartered edge compute platform that runs Firecracker microVMs in 30+ regions including Amsterdam, Frankfurt, Paris, Madrid and Stockholm. Fly Inc. is a Delaware corporation, the EU regions are EU-located but US-controlled, and the CLOUD Act applies. Fly's technical approach (microVMs at the edge, near-instant cold start, simple `fly deploy`) is genuinely innovative; replacing it with a sovereign EU stack means trading that specific multi-region edge model for either a region-fixed deployment or a self-managed equivalent on EU infrastructure.

United States 仅限 EU 的替代技术栈 10 已梳理的服务

预约通话先扫描您的域

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

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

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

驻留

数据物理存储在哪里?

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

次级处理者

您的数据路径中还有谁?

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

司法管辖区

哪些法律可以强制披露?

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

密钥托管

谁实际持有加密密钥?

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

失败 AWS · Azure · GCP · EU 区域

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

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

通过 Binadit 托管技术栈

四项全部通过。

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

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

Fly.io exits we have scoped come from regulated workloads (healthcare SaaS, fintech) where the multi-region edge pattern was nice-to-have but the US-jurisdictional processor was a blocker. The honest answer for these workloads: most don't actually need 30 regions, they need 2-3 EU regions with low latency. That requirement is met by two of our EU regions, with a CDN like Bunny.net for static assets - which collectively serves EU users with sub-50ms latency and full EU jurisdiction.

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 人，应用程序技术栈复杂度中等。

Days 1-3

Region strategy decision

Audit which Fly regions you actually use and which ones serve real traffic. For most EU-customer-facing apps, 2-3 EU regions cover it; for global apps, decide on the multi-region pattern (DNS GeoIP, Anycast, regional failover).
Days 4-10

Database + storage migration

Fly Postgres replicated to EU managed PostgreSQL or Patroni cluster. Volumes mirrored. Secrets moved to Vault.
Weeks 2-4

App cutover

Apps redeployed on Kubernetes on Binadit. DNS migrated to GeoIP routing if multi-region needed. Fly account decommissioned after verification window.

5-year TCO on Fly exits varies more than other US-cloud exits because Fly's pricing model is unusual (per-second microVM billing). For steady-state workloads, EU infrastructure is dramatically cheaper. For very spiky workloads with long idle periods, Fly's scale-to-zero is hard to match cost-effectively in the EU sovereign space without a scale-to-zero container platform.

常见问题

查看所有常见问题

Fly's "no surveillance" marketing - does it actually mean sovereignty?

Fly.io has been transparent about not being on the US hyperscaler critical-infrastructure surveillance lists. That's an operational claim, not a jurisdictional one. As a US Delaware corporation, Fly is subject to the CLOUD Act regardless of how they market themselves. The legal exposure is the same as any other US-jurisdictional provider.

How do we replace the "microVM cold start" feature?

For most workloads, microVM cold start is a nice-to-have rather than a hard requirement. If you genuinely need it, self-hosted Firecracker on EU compute (the same technology Fly uses) is the path. We deploy this for clients with specific microVM needs.

What about LiteFS for SQLite at the edge?

LiteFS is open-source. Self-host on EU compute with multi-region replication. The migration is mostly mechanical because LiteFS uses standard SQLite under the hood.

How long does a Fly.io exit take?

For a typical workload (a few apps, a Postgres cluster, some volumes): 2-4 weeks elapsed. For multi-region setups with Anycast and LiteFS: 4-8 weeks. The biggest schedule risk is replicating the multi-region pattern, not the technical work itself.

Are there any genuinely Fly-like EU options?

Not yet a 1:1 match in the EU sovereign space. The closest combination is Coolify multi-server + DNS GeoIP for routing + EU managed Postgres. It's not as polished as Fly's integrated experience, but it's sovereign and operationally simpler at the cost of some DX.

What about Fly's GPU offering?

Fly's GPU instances (A10, L40S) compete in inference workloads. Dedicated EU GPU hardware is the sovereign alternative for current-generation GPU compute. For older generations, EU dedicated GPU hardware is competitively priced.

规划您的退出 Fly.io.

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

预约通话对比其他服务商