Alternatywa tylko UE dla 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.
"Region UE" to nie suwerenność. Decydują cztery pytania.
Rezydencja danych mówi, gdzie znajdują się bity. Suwerenność mówi, który system prawny może wymusić dostęp. Odpowiedź musi być spójna we wszystkich czterech — w przeciwnym razie stack nie jest suwerenny.
Gdzie dane są fizycznie przechowywane?
Nie "w chmurze" — które centrum danych, w którym kraju, pod którą jurysdykcją.
Kto jeszcze znajduje się w Państwa ścieżce danych?
Każdy dostawca dotykający danych: CDN, przekaźnik e-mail, tracker błędów, pipeline analityczny.
Czyje prawa mogą wymusić ujawnienie?
Dostawca z siedzibą w USA podlega FISA 702 i ustawie CLOUD Act — nawet gdy dane znajdują się we Frankfurcie.
Kto faktycznie ma klucze szyfrujące?
Jeśli dostawca chmury ma zarówno dane, jak i klucze, może je odczytać — niezależnie od DPA.
Nie spełnia kryterium jurysdykcji i depozytu kluczy.
Bity w UE, spółka matka w USA, podprzetwarzający z USA w domyślnej ścieżce, klucze zarządzane przez dostawcę.
Spełnia wszystkie cztery kryteria.
Hostowane w UE na infrastrukturze z siedzibą europejską. Zero podprzetwarzających z USA w domyślnej ścieżce. Klucze klienta lub europejskiego KMS. Wymienieni z nazwy w Państwa DPA z Artykułu 28.
Dlaczego zespoły wychodzą 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 Hetzner Falkenstein + Hetzner Helsinki, or OVH Roubaix + Frankfurt, with a CDN like Bunny.net for static assets — which collectively serves EU users with sub-50ms latency and full EU jurisdiction.
Fly.io usługi i ich odpowiedniki tylko z UE
Migracja to nie "zamiana jednej skrzynki na drugą". Poniższe mapowanie jest tym, co uruchamiamy dla klientów opuszczających Fly.io z powodów Schrems II — pełna jurysdykcja UE, brak amerykańskiej spółki matki w ścieżce danych.
| Fly.io usługa | Alternatywa tylko UE | Notatka inżynierska |
|---|---|---|
| Fly Machines (microVMs) | Hetzner Cloud, OVH Public Cloud, Scaleway, self-hosted Firecracker on EU bare metal | For most workloads, regular VMs with multi-region deployment via DNS GeoIP cover the use case. For true microVM-per-request, self-hosted Firecracker on EU compute is the sovereign answer. |
| Fly Apps (PaaS layer) | Coolify on Hetzner with multi-server clustering, Scaleway Serverless Containers, Dokku | Coolify's multi-server feature handles multi-region deployment patterns. |
| Fly Postgres (clustered) | OVH Managed PostgreSQL with replicas, Aiven multi-region EU, self-managed Patroni cluster | Patroni on EU compute is the open-source pattern that powers Fly's own Postgres offering. |
| Fly Redis (Upstash) | OVH Managed Redis, Aiven Redis, Dragonfly self-hosted | Note: Upstash itself is US-headquartered, so Fly Redis is US-on-US. |
| Fly Volumes | Hetzner Volumes, OVH Block Storage, Scaleway Block Storage | Standard NVMe-backed volumes; size-equivalent. |
| Fly Proxy (Anycast) | Bunny.net + EU origin, Cloudflare → Bunny migration first, self-managed Anycast on EU IXP peering | Bunny.net offers Anycast routing across EU; for true global Anycast on EU jurisdiction, self-managed via BGP at an IXP is the path. |
| Fly Postgres failover (multi-region) | Patroni multi-region on EU compute, OVH Multi-AZ Postgres | For EU-only multi-region (e.g. NL + DE active-active with regional failover), Patroni handles it. |
| Fly Secrets | Hashicorp Vault on EU infra, Coolify environment variables, Doppler self-hosted | Vault is the production-grade answer for any non-trivial secrets workload. |
| flyctl / fly deploy DX | Coolify CLI, GitLab CI deploy steps, custom Docker push to Scaleway | The DX gap is real but closeable. Coolify's `coolify deploy` is the closest equivalent. |
| Fly LiteFS (replicated SQLite) | Self-hosted LiteFS on EU compute, rqlite, dqlite | LiteFS is open-source; self-host on Hetzner with multi-region replication. |
Jak migrujemy z Fly.io
Typowa migracja segmentu mid-market przebiega w trzech fazach. Poniższe liczby zakładają zespół inżynierski 6-10 osób i umiarkowanie złożony stack aplikacyjny.
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).
Database + storage migration
Fly Postgres replicated to EU managed PostgreSQL or Patroni cluster. Volumes mirrored. Secrets moved to Vault.
App cutover
Apps redeployed on Coolify or Scaleway. 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, Hetzner 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 serverless options like Scaleway Serverless Containers.
Często zadawane pytania
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. Scaleway H100 instances are the EU sovereign alternative for current-generation GPU compute. For older generations, Hetzner has competitive pricing.
Zaplanuj wyjście z Fly.io.
30-minutowa rozmowa zakresowa. Mapujemy Państwa stack względem alternatyw tylko z UE, szacujemy nakład pracy migracji i mówimy, czy to właściwa decyzja.