Alternativa solo 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 sostitutivo, solo UE 10 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: Fly.io
Sede: Chicago, IL
Giurisdizione: United States
Regime giuridico: CLOUD Act, FISA 702

"Regione UE" non è sovranità. Quattro domande decidono.

La residenza dei dati dice dove si trovano i bit. La sovranità dice quale sistema giuridico può imporne l'accesso. La risposta deve reggere su tutti e quattro i punti, altrimenti lo stack non è sovrano.

Residenza

Dove sono fisicamente archiviati i dati?

Non "nel cloud": quale datacenter, in quale paese, sotto quale giurisdizione.

Sub-responsabili

Chi altro è nel suo percorso dei dati?

Ogni fornitore che tocca i dati: il CDN, il relay e-mail, il tracker degli errori, la pipeline di analytics.

Giurisdizione

Quali leggi possono imporre la divulgazione?

Un fornitore con sede negli Stati Uniti ricade sotto FISA 702 e CLOUD Act, anche se i bit si trovano a Francoforte.

Custodia delle chiavi

Chi detiene effettivamente le chiavi di cifratura?

Se il provider cloud detiene sia i dati sia le chiavi, può leggerli, indipendentemente da qualsiasi DPA.

Non supera AWS · Azure · GCP · Regione UE

Fallisce su giurisdizione e custodia delle chiavi.

Bit nell'UE, casa madre statunitense, sub-responsabili americani nel percorso predefinito, chiavi gestite dal fornitore.

Supera Stack gestito da Binadit

Passa su tutte e quattro.

Ospitato in UE su infrastruttura con sede europea. Zero sub-responsabili statunitensi nel percorso predefinito. Chiavi del cliente o di KMS europeo. Elencati per nome nel suo DPA Articolo 28.

Perché i team se ne vanno 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 servizi e i loro equivalenti solo UE

Una migrazione non è "scambiare una scatola con un'altra". La mappatura sottostante è ciò che eseguiamo per i clienti che lasciano Fly.io in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

Fly.io servizio	Cosa usiamo al suo posto	Nota di ingegneria
Fly Machines (microVMs)	Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.	Per la maggior parte dei workload, VM regolari con deployment multi-regione tramite DNS GeoIP coprono il caso d'uso. Per un vero microVM-per-request, Firecracker self-hosted su compute UE è la risposta sovrana.
Fly Apps (PaaS layer)	Binadit Managed Cloud Platform. Immagini Docker costruite in GitLab CI e distribuite su Kubernetes, con ambienti di review per ogni branch.	La funzionalità multi-server di Coolify gestisce pattern di deployment multi-regione.
Fly Postgres (clustered)	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.	Patroni su compute EU è il pattern open-source che alimenta la stessa offerta Postgres di Fly.
Fly Redis (Upstash)	Binadit Managed Cloud Platform. Redis o Valkey, con Sentinel per il failover.	Nota: Upstash ha sede negli USA, quindi Fly Redis è US-on-US.
Fly Volumes	Binadit Managed Cloud Platform. Ceph RBD, o Longhorn per volumi Kubernetes-native.	Volumi basati su NVMe standard; dimensioni equivalenti.
Fly Proxy (Anycast)	Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived per il failover.	Health check, connection draining e sticky session vengono tutti mantenuti. Il TLS termina qui con certificati rinnovati automaticamente.
Fly Postgres failover (multi-region)	Binadit Managed Cloud Platform. Failover PostgreSQL gestito da Patroni tra i nodi, con promozione automatica.	Per multi-regione esclusivamente UE (ad es. NL + DE active-active con failover regionale), Patroni se ne occupa.
Fly Secrets	Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.	Vault è la risposta di livello produttivo per qualsiasi workload di gestione dei secret non banale.
flyctl / fly deploy DX	Binadit DevOps & Support. kubectl, Terraform e GitLab CI, con wrapper specifici per progetto dove utili.	Il gap di DX è reale ma colmabile. Il comando `coolify deploy` di Coolify è l'equivalente più vicino.
Fly LiteFS (replicated SQLite)	Binadit Managed Cloud Platform. PostgreSQL con read replica, o Litestream dove il modello SQLite è realmente adatto.	SQLite replicato è elegante per applicazioni read-heavy a singolo writer. Dove il write path è conteso, PostgreSQL è l'approdo più sicuro.

Fly Machines (microVMs)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.
Nota di ingegneria: Per la maggior parte dei workload, VM regolari con deployment multi-regione tramite DNS GeoIP coprono il caso d'uso. Per un vero microVM-per-request, Firecracker self-hosted su compute UE è la risposta sovrana.

Fly Apps (PaaS layer)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Immagini Docker costruite in GitLab CI e distribuite su Kubernetes, con ambienti di review per ogni branch.
Nota di ingegneria: La funzionalità multi-server di Coolify gestisce pattern di deployment multi-regione.

Fly Postgres (clustered)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.
Nota di ingegneria: Patroni su compute EU è il pattern open-source che alimenta la stessa offerta Postgres di Fly.

Fly Redis (Upstash)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Redis o Valkey, con Sentinel per il failover.
Nota di ingegneria: Nota: Upstash ha sede negli USA, quindi Fly Redis è US-on-US.

Fly Volumes

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Ceph RBD, o Longhorn per volumi Kubernetes-native.
Nota di ingegneria: Volumi basati su NVMe standard; dimensioni equivalenti.

Fly Proxy (Anycast)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived per il failover.
Nota di ingegneria: Health check, connection draining e sticky session vengono tutti mantenuti. Il TLS termina qui con certificati rinnovati automaticamente.

Fly Postgres failover (multi-region)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Failover PostgreSQL gestito da Patroni tra i nodi, con promozione automatica.
Nota di ingegneria: Per multi-regione esclusivamente UE (ad es. NL + DE active-active con failover regionale), Patroni se ne occupa.

Fly Secrets

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.
Nota di ingegneria: Vault è la risposta di livello produttivo per qualsiasi workload di gestione dei secret non banale.

flyctl / fly deploy DX

Cosa usiamo al suo posto: Binadit DevOps & Support. kubectl, Terraform e GitLab CI, con wrapper specifici per progetto dove utili.
Nota di ingegneria: Il gap di DX è reale ma colmabile. Il comando `coolify deploy` di Coolify è l'equivalente più vicino.

Fly LiteFS (replicated SQLite)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PostgreSQL con read replica, o Litestream dove il modello SQLite è realmente adatto.
Nota di ingegneria: SQLite replicato è elegante per applicazioni read-heavy a singolo writer. Dove il write path è conteso, PostgreSQL è l'approdo più sicuro.

Come migriamo da Fly.io

Una tipica migrazione di mid-market si svolge in tre fasi. I numeri qui sotto assumono un team di ingegneria di 6-10 persone e uno stack applicativo moderatamente complesso.

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.

Domande frequenti

Visualizza tutte le domande frequenti

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.

Pianifica la tua uscita da Fly.io.

Chiamata di scoping di 30 minuti. Mappiamo il tuo stack rispetto alle alternative solo UE, stimiamo lo sforzo di migrazione e ti diciamo se è la scelta giusta.

Prenota una chiamata Confronta un altro provider