Alternativa solo UE a Fly.io.

Fly.io ("Fly") è una piattaforma di edge compute con sede negli USA che esegue microVM Firecracker in oltre 30 regioni, incluse Amsterdam, Francoforte, Parigi, Madrid e Stoccolma. Fly Inc. è una corporation del Delaware; le regioni EU sono localizzate nell'EU ma controllate dagli USA, e il CLOUD Act si applica. L'approccio tecnico di Fly (microVM all'edge, cold start quasi istantaneo, semplice `fly deploy`) è genuinamente innovativo; sostituirlo con uno stack sovrano EU significa scambiare quel modello multi-regione edge specifico con un deployment a regione fissa o un equivalente self-managed su infrastruttura EU.

Stati Uniti Stack sostitutivo, solo UE 10 servizi mappati
Prenota una chiamata Scansiona prima il tuo dominio
Fornitore
Fly.io
Sede
Chicago, IL
Giurisdizione
Stati Uniti
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

Le migrazioni da Fly.io che abbiamo analizzato provengono da workload regolamentati (SaaS sanitario, fintech) dove il pattern edge multi-regione era un plus ma il processore sotto giurisdizione USA rappresentava un blocco. La risposta onesta per questi workload: la maggior parte non ha realmente bisogno di 30 regioni, ma di 2-3 regioni EU a bassa latenza. Questo requisito è soddisfatto da due delle nostre regioni EU, con un CDN come Bunny.net per gli asset statici - che complessivamente serve gli utenti EU con latenza sotto i 50ms e piena giurisdizione EU.

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 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.

  1. Giorni 1-3

    Decisione sulla strategia di regione

    Verifica quali regioni Fly utilizzi realmente e quali servono traffico effettivo. Per la maggior parte delle app rivolte a clienti EU, 2-3 regioni EU sono sufficienti; per app globali, definisci il pattern multi-regione (DNS GeoIP, Anycast, failover regionale).

  2. Giorni 4-10

    Database + migrazione storage

    Fly Postgres replicato su PostgreSQL gestito EU o cluster Patroni. Volumi mirrorati. Secret spostati su Vault.

  3. Settimane 2-4

    Cutover dell'app

    App ridistribuite su Kubernetes su Binadit. DNS migrato a routing GeoIP se serve il multi-region. Account Fly disattivato dopo la finestra di verifica.

Il TCO a 5 anni sulle uscite da Fly varia più rispetto ad altre uscite da cloud statunitensi perché il modello di pricing di Fly è insolito (fatturazione microVM al secondo). Per workload a regime costante, l'infrastruttura UE è nettamente più economica. Per workload molto irregolari con lunghi periodi di inattività, lo scale-to-zero di Fly è difficile da eguagliare in termini di costi nello spazio sovrano UE senza una piattaforma container con scale-to-zero.

Domande frequenti

Visualizza tutte le domande frequenti

Il marketing "no surveillance" di Fly - significa davvero sovranità?
Fly.io è stata trasparente riguardo al fatto di non essere nelle liste di sorveglianza sulle infrastrutture critiche degli hyperscaler USA. Questa è un'affermazione operativa, non giurisdizionale. Essendo una corporation del Delaware, Fly è soggetta al CLOUD Act indipendentemente da come si presenta sul mercato. L'esposizione legale è la stessa di qualsiasi altro provider sotto giurisdizione USA.
Come sostituiamo la funzionalità di "cold start delle microVM"?
Per la maggior parte dei workload, il cold start delle microVM è un elemento gradito più che un requisito rigido. Se ne hai davvero bisogno, la strada è Firecracker self-hosted su compute EU (la stessa tecnologia usata da Fly). Lo distribuiamo per i clienti con esigenze specifiche di microVM.
E per quanto riguarda LiteFS per SQLite all'edge?
LiteFS è open-source. Self-hosting su compute UE con replica multi-regione. La migrazione è per lo più meccanica perché LiteFS utilizza SQLite standard sotto il cofano.
Quanto tempo richiede un'uscita da Fly.io?
Per un workload tipico (alcune app, un cluster Postgres, alcuni volumi): 2-4 settimane di tempo trascorso. Per configurazioni multi-regione con Anycast e LiteFS: 4-8 settimane. Il rischio maggiore per il programma è replicare il pattern multi-regione, non il lavoro tecnico in sé.
Esistono opzioni UE genuinamente simili a Fly?
Non ancora una corrispondenza 1:1 nello spazio sovrano EU. La combinazione più vicina è Coolify multi-server + DNS GeoIP per il routing + Postgres gestito EU. Non è raffinata quanto l'esperienza integrata di Fly, ma è sovrana e operativamente più semplice, a costo di una DX inferiore.
E per quanto riguarda l'offerta GPU di Fly?
Le istanze GPU di Fly (A10, L40S) competono nei workload di inference. L'hardware GPU dedicato EU è l'alternativa sovrana per il compute GPU di generazione attuale. Per le generazioni precedenti, l'hardware GPU dedicato EU ha un prezzo competitivo.

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