Europa-only Alternative zu Fly.io.

Fly.io ("Fly") ist eine in den USA ansässige Edge-Compute-Plattform, die Firecracker-microVMs in über 30 Regionen betreibt, darunter Amsterdam, Frankfurt, Paris, Madrid und Stockholm. Fly Inc. ist eine Delaware-Corporation, die EU-Regionen befinden sich zwar in der EU, unterliegen jedoch US-Kontrolle, und der CLOUD Act findet Anwendung. Flys technischer Ansatz (microVMs am Edge, nahezu sofortiger Kaltstart, einfaches `fly deploy`) ist wirklich innovativ; ihn durch einen souveränen EU-Stack zu ersetzen bedeutet, dieses spezifische Multi-Region-Edge-Modell entweder gegen ein regionsfestes Deployment oder ein selbstverwaltetes Äquivalent auf EU-Infrastruktur einzutauschen.

Vereinigte Staaten Ersatz-Stack, ausschließlich EU 10 Dienste zugeordnet
Gespräch vereinbaren Erst Domain scannen
Anbieter
Fly.io
Hauptsitz
Chicago, IL
Rechtsmacht
Vereinigte Staaten
Rechtsregime
CLOUD Act, FISA 702

"EU-Region" ist keine Souveränität. Vier Fragen entscheiden.

Data-Residency sagt, wo die Bits liegen. Souveränität sagt, welches Rechtssystem Zugriff erzwingen kann. Die Antwort muss auf allen vier Punkten halten, sonst ist der Stack nicht souverän.

Residenz

Wo sind die Daten physisch gespeichert?

Nicht "in der Cloud": welches Rechenzentrum, in welchem Land, unter welcher Jurisdiktion.

Subprozessoren

Wer ist sonst noch in Ihrem Datenpfad?

Jeder Anbieter, der die Daten berührt: das CDN, das E-Mail-Relay, der Error-Tracker, die Analytics-Pipeline.

Rechtsmacht

Wessen Gesetze können die Offenlegung erzwingen?

Ein Anbieter mit US-Hauptsitz untersteht FISA 702 und dem CLOUD Act, auch wenn die Bits in Frankfurt liegen.

Schlüsselverwahrung

Wer hält tatsächlich die Verschlüsselungsschlüssel?

Wenn der Cloud-Anbieter sowohl die Daten als auch die Schlüssel hält, sind die Daten für ihn lesbar, unabhängig von jedem AVV.

Erfüllt nicht AWS · Azure · GCP · EU-Region

Scheitert an Rechtsmacht und Schlüsselverwahrung.

EU-Daten, US-Mutterkonzern, US-Subprozessoren im Standardpfad, vom Anbieter verwaltete Schlüssel.

Erfüllt Binadit Managed Stack

Besteht in allen vier Punkten.

EU-gehostet auf Infrastruktur mit EU-Hauptsitz. Null US-Subprozessoren im Standardpfad. Kunden- oder EU-KMS-Schlüssel. Namentlich in Ihrer Artikel-28-AVV aufgeführt.

Warum Teams aussteigen Fly.io

Die Fly.io-Migrationen, die wir bewertet haben, stammen aus regulierten Workloads (Healthcare-SaaS, Fintech), bei denen das Multi-Region-Edge-Muster nett, aber nicht essenziell war, während der US-jurisdiktionsgebundene Processor ein Blocker war. Die ehrliche Antwort für diese Workloads: Die meisten benötigen gar keine 30 Regionen, sondern 2-3 EU-Regionen mit niedriger Latenz. Diese Anforderung wird von zwei unserer EU-Regionen erfüllt, ergänzt durch ein CDN wie Bunny.net für statische Assets - das EU-Nutzern gemeinsam eine Latenz von unter 50ms und volle EU-Jurisdiktion bietet.

Fly.io Dienste und ihre EU-only Äquivalente

Eine Migration ist nicht "eine Box gegen eine andere tauschen". Die Zuordnung unten ist das, was wir für Kunden ausführen, die Folgendes verlassen: Fly.io auf Grundlage von Schrems II: vollständige EU-Jurisdiktion, kein US-Mutterkonzern im Datenpfad.

Fly Machines (microVMs)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. KVM-VMs auf Debian oder Ubuntu, provisioniert mit Terraform und konfiguriert mit Ansible.
Engineering-Hinweis
Für die meisten Workloads decken reguläre VMs mit Multi-Region-Deployment via DNS-GeoIP den Anwendungsfall ab. Für echte MicroVM-pro-Request-Szenarien ist selbst gehostetes Firecracker auf EU-Compute die souveräne Lösung.

Fly Apps (PaaS layer)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. Docker-Images, gebaut in GitLab CI und deployed auf Kubernetes, mit Review-Umgebungen pro Branch.
Engineering-Hinweis
Die Multi-Server-Funktion von Coolify deckt Multi-Region-Deployment-Muster ab.

Fly Postgres (clustered)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. PostgreSQL oder MySQL mit Patroni für Failover und pgBackRest für Point-in-Time Recovery.
Engineering-Hinweis
Patroni auf EU-Compute ist das Open-Source-Muster, das auch Flys eigenes Postgres-Angebot antreibt.

Fly Redis (Upstash)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. Redis oder Valkey, mit Sentinel für Failover.
Engineering-Hinweis
Hinweis: Upstash selbst hat seinen Hauptsitz in den USA, daher ist Fly Redis US-auf-US.

Fly Volumes

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. Ceph RBD oder Longhorn für Kubernetes-native Volumes.
Engineering-Hinweis
Standard-NVMe-basierte Volumes; größengleich.

Fly Proxy (Anycast)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. HAProxy oder Nginx, mit keepalived für Failover.
Engineering-Hinweis
Health Checks, Connection Draining und Sticky Sessions bleiben allesamt erhalten. TLS terminiert hier, wobei Zertifikate automatisch erneuert werden.

Fly Postgres failover (multi-region)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. Von Patroni verwaltetes PostgreSQL-Failover über Nodes hinweg, mit automatischer Promotion.
Engineering-Hinweis
Für reine EU-Multi-Region-Szenarien (z. B. NL + DE aktiv-aktiv mit regionalem Failover) übernimmt Patroni die Aufgabe.

Fly Secrets

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. HashiCorp Vault oder Infisical, self-hosted, mit automatischer Lease-Rotation.
Engineering-Hinweis
Vault ist die produktionsreife Antwort für jeden nicht-trivialen Secrets-Workload.

flyctl / fly deploy DX

Was wir stattdessen betreiben
Binadit DevOps & Support. kubectl, Terraform und GitLab CI, mit projektspezifischen Wrappern, wo sie hilfreich sind.
Engineering-Hinweis
Die DX-Lücke ist real, aber schließbar. Coolifys `coolify deploy` ist das nächstliegende Äquivalent.

Fly LiteFS (replicated SQLite)

Was wir stattdessen betreiben
Binadit Managed Cloud Platform. PostgreSQL mit Read-Replicas, oder Litestream, wo das SQLite-Modell wirklich passt.
Engineering-Hinweis
Repliziertes SQLite ist elegant für leselastige Single-Writer-Anwendungen. Bei umkämpftem Schreibpfad ist PostgreSQL die sicherere Wahl.

Wie wir migrieren von Fly.io

Eine typische Mittelstand-Migration läuft in drei Phasen. Die Zahlen unten gehen von einem 6-10-köpfigen Engineering-Team und einem mäßig komplexen Anwendungs-Stack aus.

  1. Tag 1-3

    Entscheidung zur Regionsstrategie

    Auditieren Sie, welche Fly-Regionen Sie tatsächlich nutzen und welche echten Traffic bedienen. Für die meisten EU-kundenorientierten Anwendungen reichen 2-3 EU-Regionen aus; bei globalen Anwendungen entscheiden Sie sich für ein Multi-Region-Pattern (DNS-GeoIP, Anycast, regionales Failover).

  2. Tag 4-10

    Datenbank- + Storage-Migration

    Fly Postgres repliziert zu verwaltetem EU-PostgreSQL oder Patroni-Cluster. Volumes gespiegelt. Secrets in Vault verschoben.

  3. Wochen 2-4

    App-Umstellung

    Apps wurden auf Kubernetes bei Binadit neu deployed. DNS wurde bei Bedarf für Multi-Region auf GeoIP-Routing umgestellt. Der Fly-Account wurde nach dem Verifizierungsfenster stillgelegt.

5-Jahres-TCO bei Fly-Exits variiert stärker als bei anderen US-Cloud-Exits, da Flys Preismodell ungewöhnlich ist (sekundengenaue MicroVM-Abrechnung). Bei Steady-State-Workloads ist EU-Infrastruktur deutlich günstiger. Bei sehr spitzenlastigen Workloads mit langen Leerlaufphasen ist Flys Scale-to-Zero im EU-souveränen Bereich ohne eine Scale-to-Zero-Container-Plattform kosteneffizient kaum zu erreichen.

Häufig gestellte Fragen

Alle häufig gestellten Fragen anzeigen

Flys „No-Surveillance“-Marketing - bedeutet das wirklich Souveränität?
Fly.io war transparent damit, nicht auf den Überwachungslisten kritischer Infrastruktur der US-Hyperscaler zu stehen. Das ist eine operative Aussage, keine jurisdiktionale. Als US-Delaware-Corporation unterliegt Fly dem CLOUD Act, unabhängig davon, wie sie sich selbst vermarkten. Das rechtliche Risiko ist dasselbe wie bei jedem anderen US-jurisdiktionsgebundenen Anbieter.
Wie ersetzen wir das Feature „microVM Cold Start“?
Für die meisten Workloads ist ein microVM-Kaltstart eher ein Nice-to-have als eine harte Anforderung. Falls Sie ihn wirklich benötigen, ist selbst gehostetes Firecracker auf EU-Compute (dieselbe Technologie, die Fly verwendet) der richtige Weg. Wir setzen dies für Kunden mit spezifischen microVM-Anforderungen ein.
Was ist mit LiteFS für SQLite am Edge?
LiteFS ist Open Source. Self-Hosting auf EU-Compute mit Multi-Region-Replikation. Die Migration ist größtenteils mechanisch, da LiteFS unter der Haube auf Standard-SQLite basiert.
Wie lange dauert ein Fly.io-Exit?
Für einen typischen Workload (ein paar Apps, ein Postgres-Cluster, einige Volumes): 2-4 Wochen Laufzeit. Für Multi-Region-Setups mit Anycast und LiteFS: 4-8 Wochen. Das größte Zeitplanrisiko liegt in der Replikation des Multi-Region-Musters, nicht in der technischen Arbeit selbst.
Gibt es wirklich Fly-ähnliche EU-Optionen?
Noch kein 1:1-Äquivalent im EU-souveränen Bereich. Die nächstliegende Kombination ist Coolify Multi-Server + DNS-GeoIP für das Routing + EU-managed Postgres. Es ist nicht so ausgereift wie das integrierte Erlebnis von Fly, aber es ist souverän und operativ einfacher, auf Kosten etwas geringerer DX.
Was ist mit dem GPU-Angebot von Fly?
Flys GPU-Instanzen (A10, L40S) konkurrieren bei Inference-Workloads. Dedizierte EU-GPU-Hardware ist die souveräne Alternative für GPU-Compute der aktuellen Generation. Bei älteren Generationen ist dedizierte EU-GPU-Hardware preislich konkurrenzfähig.

Plane deinen Exit von Fly.io.

30-minütiges Scoping-Gespräch. Wir bilden Ihren Stack auf EU-only Alternativen ab, schätzen den Migrationsaufwand und sagen Ihnen, ob es die richtige Entscheidung ist.

Gespräch vereinbaren Anderen Anbieter vergleichen