Alternative UE-uniquement à Fly.io.

Fly.io (« Fly ») est une plateforme d'edge compute dont le siège est aux États-Unis, qui exécute des microVMs Firecracker dans plus de 30 régions, dont Amsterdam, Francfort, Paris, Madrid et Stockholm. Fly Inc. est une société du Delaware ; les régions EU sont situées dans l'UE mais restent sous contrôle américain, et le CLOUD Act s'applique. L'approche technique de Fly (microVMs en edge, cold start quasi instantané, simplicité du `fly deploy`) est réellement innovante ; la remplacer par une stack souveraine EU signifie échanger ce modèle multi-région edge spécifique contre soit un déploiement fixé à une région, soit un équivalent auto-géré sur une infrastructure EU.

États-Unis 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: États-Unis
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

Les migrations hors de Fly.io que nous avons scopées proviennent de charges de travail réglementées (SaaS santé, fintech) pour lesquelles le modèle multi-région edge était un atout appréciable, mais où le processeur sous juridiction américaine posait problème. La réponse honnête pour ces charges de travail : la plupart n'ont pas réellement besoin de 30 régions, mais de 2 à 3 régions EU à faible latence. Cette exigence est satisfaite par deux de nos régions EU, associées à un CDN comme Bunny.net pour les assets statiques - ce qui permet de servir collectivement les utilisateurs EU avec une latence inférieure à 50 ms et une juridiction EU complète.

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.

Jours 1-3

Décision de stratégie régionale

Auditez les régions Fly que vous utilisez réellement et celles qui servent du trafic réel. Pour la plupart des applications destinées aux clients européens, 2-3 régions UE suffisent ; pour les applications globales, définissez le pattern multi-région (DNS GeoIP, Anycast, failover régional).
Jours 4-10

Base de données + migration du stockage

Fly Postgres répliqué vers un cluster PostgreSQL managé UE ou Patroni. Volumes mis en miroir. Secrets migrés vers Vault.
Semaines 2-4

Bascule de l'application

Applications redéployées sur Kubernetes chez Binadit. DNS migré vers un routage GeoIP si le multi-région est nécessaire. Compte Fly décommissionné après la fenêtre de vérification.

Le TCO sur 5 ans des sorties Fly varie davantage que pour les autres sorties de cloud américain, car le modèle tarifaire de Fly est atypique (facturation microVM à la seconde). Pour les workloads à charge constante, l'infrastructure européenne est nettement moins chère. Pour les workloads très irréguliers avec de longues périodes d'inactivité, le scale-to-zero de Fly est difficile à égaler de manière rentable dans l'espace souverain européen sans une plateforme de conteneurs à scale-to-zero.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Le marketing "no surveillance" de Fly - signifie-t-il réellement la souveraineté ?

Fly.io a été transparent sur le fait de ne pas figurer sur les listes de surveillance des infrastructures critiques des hyperscalers américains. C'est une affirmation opérationnelle, pas juridictionnelle. En tant que société du Delaware, Fly reste soumise au CLOUD Act, quelle que soit la manière dont elle se positionne. L'exposition juridique est la même que celle de tout autre fournisseur sous juridiction américaine.

Comment remplacer la fonctionnalité de "cold start microVM" ?

Pour la plupart des charges de travail, le cold start microVM est un plus plutôt qu'une exigence stricte. Si vous en avez réellement besoin, Firecracker auto-hébergé sur du compute EU (la même technologie qu'utilise Fly) est la voie à suivre. Nous déployons cela pour les clients ayant des besoins spécifiques en microVM.

Qu'en est-il de LiteFS pour SQLite en edge ?

LiteFS est open-source. Auto-hébergement sur du compute UE avec réplication multi-région. La migration est en grande partie mécanique car LiteFS utilise du SQLite standard en interne.

Combien de temps dure une sortie de Fly.io ?

Pour une charge de travail typique (quelques apps, un cluster Postgres, des volumes) : 2 à 4 semaines. Pour des configurations multi-régions avec Anycast et LiteFS : 4 à 8 semaines. Le principal risque calendaire concerne la réplication du schéma multi-régions, et non le travail technique en lui-même.

Existe-t-il de véritables options européennes similaires à Fly ?

Pas encore d'équivalent 1:1 dans l'espace souverain UE. La combinaison la plus proche est Coolify multi-serveur + DNS GeoIP pour le routage + Postgres managé UE. Ce n'est pas aussi abouti que l'expérience intégrée de Fly, mais c'est souverain et opérationnellement plus simple, au prix d'une certaine expérience développeur.

Qu'en est-il de l'offre GPU de Fly ?

Les instances GPU de Fly (A10, L40S) sont compétitives sur les charges de travail d'inférence. Le matériel GPU dédié EU est l'alternative souveraine pour le compute GPU de génération actuelle. Pour les générations plus anciennes, le matériel GPU dédié EU est proposé à un tarif compétitif.

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