Alternativa apenas UE a Fly.io.

A Fly.io ("Fly") é uma plataforma de edge compute sediada nos EUA que executa microVMs Firecracker em mais de 30 regiões, incluindo Amsterdã, Frankfurt, Paris, Madrid e Estocolmo. A Fly Inc. é uma corporação de Delaware, as regiões da UE estão localizadas na UE mas são controladas pelos EUA, e o CLOUD Act aplica-se. A abordagem técnica da Fly (microVMs no edge, cold start quase instantâneo, `fly deploy` simples) é genuinamente inovadora; substituí-la por uma stack soberana da UE significa trocar esse modelo específico de edge multi-região por um deployment fixo a uma região ou um equivalente self-managed em infraestrutura da UE.

Estados Unidos 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: Estados Unidos
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

As saídas da Fly.io que já analisámos vêm de workloads regulados (healthcare SaaS, fintech) onde o padrão de edge multi-região era desejável mas o processador com jurisdição nos EUA era um bloqueador. A resposta honesta para estes workloads: a maioria não precisa realmente de 30 regiões, precisa de 2-3 regiões na UE com baixa latência. Esse requisito é satisfeito por duas das nossas regiões na UE, com um CDN como o Bunny.net para assets estáticos - que juntos servem utilizadores na UE com latência inferior a 50ms e jurisdição totalmente europeia.

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.

Dias 1-3

Decisão de estratégia de região

Audite quais regiões da Fly realmente utiliza e quais servem tráfego real. Para a maioria das aplicações voltadas a clientes na UE, 2-3 regiões UE são suficientes; para aplicações globais, decida o padrão multi-região (DNS GeoIP, Anycast, failover regional).
Dias 4-10

Migração de base de dados + storage

Fly Postgres replicado para PostgreSQL gerido na UE ou cluster Patroni. Volumes espelhados. Secrets migrados para o Vault.
Semanas 2-4

Cutover da app

Apps redeployed no Kubernetes no Binadit. DNS migrado para roteamento GeoIP se multi-region for necessário. Conta Fly desativada após janela de verificação.

O TCO a 5 anos em saídas da Fly varia mais do que outras saídas de clouds dos EUA, porque o modelo de pricing da Fly é atípico (billing de microVM por segundo). Para workloads em regime estável, a infraestrutura da UE é dramaticamente mais barata. Para workloads muito irregulares com longos períodos de inatividade, o scale-to-zero da Fly é difícil de igualar em custo-eficiência no espaço soberano da UE sem uma plataforma de containers com scale-to-zero.

Perguntas frequentes

Ver todas as perguntas frequentes

O marketing "sem vigilância" da Fly - significa realmente soberania?

A Fly.io tem sido transparente ao afirmar que não está nas listas de vigilância de infraestrutura crítica dos hyperscalers dos EUA. Essa é uma afirmação operacional, não jurisdicional. Como corporação de Delaware nos EUA, a Fly está sujeita ao CLOUD Act independentemente de como se posiciona no mercado. A exposição legal é a mesma de qualquer outro fornecedor com jurisdição nos EUA.

Como substituímos a funcionalidade de "microVM cold start"?

Para a maioria das cargas de trabalho, o cold start de microVM é um extra desejável em vez de um requisito rígido. Se realmente precisar disso, o caminho é o Firecracker self-hosted em compute na UE (a mesma tecnologia que a Fly utiliza). Implementamos isto para clientes com necessidades específicas de microVM.

E quanto ao LiteFS para SQLite na edge?

O LiteFS é open-source. Faça self-hosting em compute na UE com replicação multi-região. A migração é maioritariamente mecânica, pois o LiteFS utiliza SQLite padrão por baixo.

Quanto tempo demora uma saída do Fly.io?

Para uma carga de trabalho típica (algumas apps, um cluster Postgres, alguns volumes): 2-4 semanas decorridas. Para configurações multi-região com Anycast e LiteFS: 4-8 semanas. O maior risco para o cronograma é replicar o padrão multi-região, não o trabalho técnico em si.

Existem opções na UE genuinamente semelhantes à Fly?

Ainda não existe uma correspondência 1:1 no espaço soberano da UE. A combinação mais próxima é Coolify multi-server + DNS GeoIP para routing + Postgres gerido na UE. Não é tão polido como a experiência integrada da Fly, mas é soberano e operacionalmente mais simples, ao custo de alguma DX.

E quanto à oferta de GPU da Fly?

As instâncias GPU da Fly (A10, L40S) competem em workloads de inferência. Hardware GPU dedicado na UE é a alternativa soberana para computação GPU de geração atual. Para gerações mais antigas, o hardware GPU dedicado na UE tem preços competitivos.

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