Alternativa apenas UE a 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 Stack de substituição, apenas UE 10 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Fly.io
Sede: Chicago, IL
Jurisdição: United States
Regime jurídico: CLOUD Act, FISA 702

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair 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 serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Fly.io com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Fly.io serviço	O que usamos no lugar	Nota de engenharia
Fly Machines (microVMs)	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	Para a maioria das cargas de trabalho, VMs regulares com deployment multi-região via DNS GeoIP cobrem o caso de uso. Para microVM-por-request verdadeiro, Firecracker self-hosted em compute da UE é a resposta soberana.
Fly Apps (PaaS layer)	Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.	A funcionalidade multi-server do Coolify lida com padrões de deployment multi-região.
Fly Postgres (clustered)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	O Patroni em compute europeu é o padrão open-source que alimenta a própria oferta de Postgres da Fly.
Fly Redis (Upstash)	Binadit Managed Cloud Platform. Redis ou Valkey, com Sentinel para failover.	Nota: a própria Upstash tem sede nos EUA, pelo que o Fly Redis é US-on-US.
Fly Volumes	Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.	Volumes baseados em NVMe padrão; equivalentes em tamanho.
Fly Proxy (Anycast)	Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.	Health checks, connection draining e sticky sessions são todos preservados. O TLS termina aqui com certificados renovados automaticamente.
Fly Postgres failover (multi-region)	Binadit Managed Cloud Platform. Failover de PostgreSQL gerido pelo Patroni entre nós, com promoção automática.	Para multi-região exclusivamente na UE (por exemplo, NL + DE active-active com failover regional), o Patroni trata disso.
Fly Secrets	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.	O Vault é a resposta de nível de produção para qualquer carga de trabalho de secrets não trivial.
flyctl / fly deploy DX	Binadit DevOps & Support. kubectl, Terraform e GitLab CI, com wrappers específicos do projeto onde fizerem sentido.	A diferença de DX é real mas ultrapassável. O `coolify deploy` do Coolify é o equivalente mais próximo.
Fly LiteFS (replicated SQLite)	Binadit Managed Cloud Platform. PostgreSQL com read replicas, ou Litestream onde o modelo SQLite realmente se adequa.	O SQLite replicado é elegante para aplicações com muitas leituras e um único escritor. Onde o caminho de escrita é disputado, o PostgreSQL é o destino mais seguro.

Fly Machines (microVMs)

O que usamos no lugar: Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia: Para a maioria das cargas de trabalho, VMs regulares com deployment multi-região via DNS GeoIP cobrem o caso de uso. Para microVM-por-request verdadeiro, Firecracker self-hosted em compute da UE é a resposta soberana.

Fly Apps (PaaS layer)

O que usamos no lugar: Binadit Managed Cloud Platform. Imagens Docker construídas no GitLab CI e implantadas no Kubernetes, com review environments por branch.
Nota de engenharia: A funcionalidade multi-server do Coolify lida com padrões de deployment multi-região.

Fly Postgres (clustered)

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia: O Patroni em compute europeu é o padrão open-source que alimenta a própria oferta de Postgres da Fly.

Fly Redis (Upstash)

O que usamos no lugar: Binadit Managed Cloud Platform. Redis ou Valkey, com Sentinel para failover.
Nota de engenharia: Nota: a própria Upstash tem sede nos EUA, pelo que o Fly Redis é US-on-US.

Fly Volumes

O que usamos no lugar: Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn para volumes Kubernetes-native.
Nota de engenharia: Volumes baseados em NVMe padrão; equivalentes em tamanho.

Fly Proxy (Anycast)

O que usamos no lugar: Binadit Managed Cloud Platform. HAProxy ou Nginx, com keepalived para failover.
Nota de engenharia: Health checks, connection draining e sticky sessions são todos preservados. O TLS termina aqui com certificados renovados automaticamente.

Fly Postgres failover (multi-region)

O que usamos no lugar: Binadit Managed Cloud Platform. Failover de PostgreSQL gerido pelo Patroni entre nós, com promoção automática.
Nota de engenharia: Para multi-região exclusivamente na UE (por exemplo, NL + DE active-active com failover regional), o Patroni trata disso.

Fly Secrets

O que usamos no lugar: Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.
Nota de engenharia: O Vault é a resposta de nível de produção para qualquer carga de trabalho de secrets não trivial.

flyctl / fly deploy DX

O que usamos no lugar: Binadit DevOps & Support. kubectl, Terraform e GitLab CI, com wrappers específicos do projeto onde fizerem sentido.
Nota de engenharia: A diferença de DX é real mas ultrapassável. O `coolify deploy` do Coolify é o equivalente mais próximo.

Fly LiteFS (replicated SQLite)

O que usamos no lugar: Binadit Managed Cloud Platform. PostgreSQL com read replicas, ou Litestream onde o modelo SQLite realmente se adequa.
Nota de engenharia: O SQLite replicado é elegante para aplicações com muitas leituras e um único escritor. Onde o caminho de escrita é disputado, o PostgreSQL é o destino mais seguro.

Como migramos de Fly.io

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

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.

Perguntas frequentes

Ver todas as perguntas frequentes

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.

Planeie a sua saída de Fly.io.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor