Alternative UE-uniquement à 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 remplacement, UE uniquement 10 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: Fly.io
Siège: Chicago, IL
Juridiction: United States
Régime juridique: CLOUD Act, FISA 702

Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.

La résidence des données indique où se trouvent les bits. La souveraineté indique quel système juridique peut en imposer l'accès. La réponse doit tenir sur les quatre points, sinon la stack n'est pas souveraine.

Résidence

Où les données sont-elles physiquement stockées ?

Pas "dans le cloud" : quel centre de données, dans quel pays, sous quelle juridiction.

Sous-traitants

Qui d'autre est dans votre chemin de données ?

Chaque fournisseur qui touche les données : le CDN, le relais e-mail, le tracker d'erreurs, le pipeline analytics.

Juridiction

Quelles lois peuvent contraindre à la divulgation ?

Un fournisseur dont le siège est aux États-Unis relève de la FISA 702 et du CLOUD Act, même si les données se trouvent à Francfort.

Garde des clés

Qui détient réellement les clés de chiffrement ?

Si le fournisseur cloud détient à la fois les données et les clés, il peut les lire, quel que soit le DPA.

Échoue AWS · Azure · GCP · Région UE

Échoue sur la juridiction et la garde des clés.

Bits en UE, maison mère américaine, sous-traitants américains dans le chemin par défaut, clés gérées par le fournisseur.

Réussit Stack géré par Binadit

Réussit sur les quatre.

Hébergé en UE sur une infrastructure au siège européen. Zéro sous-traitant américain dans le chemin par défaut. Clés détenues par le client ou par un KMS européen. Nommés dans votre DPA Article 28.

Pourquoi les équipes partent 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 services et leurs équivalents UE-uniquement

Une migration n'est pas "échanger une boîte contre une autre". La cartographie ci-dessous est ce que nous exécutons pour les clients qui quittent Fly.io au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

Fly.io service	Ce que nous utilisons à la place	Note d'ingénierie
Fly Machines (microVMs)	Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.	Pour la plupart des charges de travail, des VM classiques avec déploiement multi-région via DNS GeoIP couvrent le besoin. Pour une véritable microVM par requête, Firecracker auto-hébergé sur compute européen est la réponse souveraine.
Fly Apps (PaaS layer)	Binadit Managed Cloud Platform. Images Docker construites dans GitLab CI et déployées sur Kubernetes, avec environnements de review par branche.	La fonctionnalité multi-serveur de Coolify gère les schémas de déploiement multi-région.
Fly Postgres (clustered)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	Patroni sur du compute EU est le pattern open-source qui alimente l'offre Postgres propre de Fly.
Fly Redis (Upstash)	Binadit Managed Cloud Platform. Redis ou Valkey, avec Sentinel pour le failover.	Remarque : Upstash a lui-même son siège aux États-Unis, donc Fly Redis est du US-on-US.
Fly Volumes	Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn pour des volumes Kubernetes-native.	Volumes NVMe standard ; taille équivalente.
Fly Proxy (Anycast)	Binadit Managed Cloud Platform. HAProxy ou Nginx, avec keepalived pour le failover.	Les health checks, le connection draining et les sticky sessions sont tous conservés. Le TLS se termine ici avec des certificats renouvelés automatiquement.
Fly Postgres failover (multi-region)	Binadit Managed Cloud Platform. Failover PostgreSQL géré par Patroni entre les nodes, avec promotion automatique.	Pour un multi-région strictement européen (ex. NL + DE en actif-actif avec basculement régional), Patroni gère ce cas.
Fly Secrets	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.	Vault est la solution de niveau production pour tout workload de gestion de secrets non trivial.
flyctl / fly deploy DX	Binadit DevOps & Support. kubectl, Terraform et GitLab CI, avec des wrappers spécifiques au projet lorsqu'ils sont utiles.	L'écart en DX est réel mais comblable. La commande `coolify deploy` de Coolify en est l'équivalent le plus proche.
Fly LiteFS (replicated SQLite)	Binadit Managed Cloud Platform. PostgreSQL avec read replicas, ou Litestream lorsque le modèle SQLite convient réellement.	SQLite répliqué est élégant pour les applications à forte lecture avec un seul writer. Là où le chemin d'écriture est contesté, PostgreSQL est l'atterrissage le plus sûr.

Fly Machines (microVMs)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.
Note d'ingénierie: Pour la plupart des charges de travail, des VM classiques avec déploiement multi-région via DNS GeoIP couvrent le besoin. Pour une véritable microVM par requête, Firecracker auto-hébergé sur compute européen est la réponse souveraine.

Fly Apps (PaaS layer)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Images Docker construites dans GitLab CI et déployées sur Kubernetes, avec environnements de review par branche.
Note d'ingénierie: La fonctionnalité multi-serveur de Coolify gère les schémas de déploiement multi-région.

Fly Postgres (clustered)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.
Note d'ingénierie: Patroni sur du compute EU est le pattern open-source qui alimente l'offre Postgres propre de Fly.

Fly Redis (Upstash)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Redis ou Valkey, avec Sentinel pour le failover.
Note d'ingénierie: Remarque : Upstash a lui-même son siège aux États-Unis, donc Fly Redis est du US-on-US.

Fly Volumes

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Ceph RBD, ou Longhorn pour des volumes Kubernetes-native.
Note d'ingénierie: Volumes NVMe standard ; taille équivalente.

Fly Proxy (Anycast)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. HAProxy ou Nginx, avec keepalived pour le failover.
Note d'ingénierie: Les health checks, le connection draining et les sticky sessions sont tous conservés. Le TLS se termine ici avec des certificats renouvelés automatiquement.

Fly Postgres failover (multi-region)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Failover PostgreSQL géré par Patroni entre les nodes, avec promotion automatique.
Note d'ingénierie: Pour un multi-région strictement européen (ex. NL + DE en actif-actif avec basculement régional), Patroni gère ce cas.

Fly Secrets

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.
Note d'ingénierie: Vault est la solution de niveau production pour tout workload de gestion de secrets non trivial.

flyctl / fly deploy DX

Ce que nous utilisons à la place: Binadit DevOps & Support. kubectl, Terraform et GitLab CI, avec des wrappers spécifiques au projet lorsqu'ils sont utiles.
Note d'ingénierie: L'écart en DX est réel mais comblable. La commande `coolify deploy` de Coolify en est l'équivalent le plus proche.

Fly LiteFS (replicated SQLite)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL avec read replicas, ou Litestream lorsque le modèle SQLite convient réellement.
Note d'ingénierie: SQLite répliqué est élégant pour les applications à forte lecture avec un seul writer. Là où le chemin d'écriture est contesté, PostgreSQL est l'atterrissage le plus sûr.

Comment nous migrons depuis Fly.io

Une migration typique de mid-market se déroule en trois phases. Les chiffres ci-dessous supposent une équipe d'ingénierie de 6 à 10 personnes et une stack applicative modérément complexe.

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.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

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.

Planifiez votre sortie de Fly.io.

Appel de cadrage de 30 minutes. Nous cartographions votre stack par rapport aux alternatives UE-uniquement, estimons l'effort de migration et vous disons si c'est le bon choix.

Planifier un appel Comparer un autre fournisseur