European-only alternative to 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 EU-only replacement stack 10 services mapped

Schedule a call Scan your domain first

Provider: Fly.io
Headquarters: Chicago, IL
Jurisdiction: United States
Legal regime: CLOUD Act, FISA 702

"EU region" is not sovereignty. Four questions decide it.

Data residency tells you where the bits sit. Sovereignty tells you which legal system can compel access. The answer must hold on all four - or the stack is not sovereign.

Residency

Where is the data physically stored?

Not "in the cloud" - which datacenter, in which country, under which jurisdiction.

Subprocessors

Who else is in your data path?

Every vendor that touches the data: the CDN, the email relay, the error tracker, the analytics pipe.

Jurisdiction

Whose laws can compel disclosure?

A US-headquartered provider falls under FISA 702 and the CLOUD Act - even when the bits sit in Frankfurt.

Key custody

Who actually holds the encryption keys?

If the cloud provider holds both the data and the keys, the data is readable by them - regardless of any DPA.

Fails AWS · Azure · GCP · EU region

Fails on jurisdiction and key custody.

EU bits, US-headquartered parent, US subprocessors in the default path, provider-managed keys.

Passes Binadit managed stack

Passes on all four.

EU-hosted on EU-headquartered infrastructure. Zero US subprocessors in the default path. Customer-held or EU-KMS keys. Listed by name in your Article 28 DPA.

Why teams are exiting 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 and their EU-only equivalents

A migration is not "swap one box for another". The mapping below is what we run for clients leaving Fly.io on Schrems II grounds - full EU jurisdiction, no US parent in the data path.

Fly.io service	What we run instead	Engineering note
Fly Machines (microVMs)	Binadit Managed Cloud Platform. KVM virtual machines on Debian or Ubuntu, provisioned with Terraform and configured with Ansible.	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)	Binadit Managed Cloud Platform. Docker images built in GitLab CI and deployed to Kubernetes, with review environments per branch.	Coolify's multi-server feature handles multi-region deployment patterns.
Fly Postgres (clustered)	Binadit Managed Cloud Platform. PostgreSQL or MySQL with Patroni for failover and pgBackRest for point-in-time recovery.	Patroni on EU compute is the open-source pattern that powers Fly's own Postgres offering.
Fly Redis (Upstash)	Binadit Managed Cloud Platform. Redis or Valkey, with Sentinel for failover.	Note: Upstash itself is US-headquartered, so Fly Redis is US-on-US.
Fly Volumes	Binadit Managed Cloud Platform. Ceph RBD, or Longhorn for Kubernetes-native volumes.	Standard NVMe-backed volumes; size-equivalent.
Fly Proxy (Anycast)	Binadit Managed Cloud Platform. HAProxy or Nginx, with keepalived for failover.	Health checks, connection draining and sticky sessions all carry over. TLS terminates here with certificates renewed automatically.
Fly Postgres failover (multi-region)	Binadit Managed Cloud Platform. Patroni-managed PostgreSQL failover across nodes, with automatic promotion.	For EU-only multi-region (e.g. NL + DE active-active with regional failover), Patroni handles it.
Fly Secrets	Binadit Managed Cloud Platform. HashiCorp Vault or Infisical, self-hosted, with automatic lease rotation.	Vault is the production-grade answer for any non-trivial secrets workload.
flyctl / fly deploy DX	Binadit DevOps & Support. kubectl, Terraform and GitLab CI, with project-specific wrappers where they help.	The DX gap is real but closeable. Coolify's `coolify deploy` is the closest equivalent.
Fly LiteFS (replicated SQLite)	Binadit Managed Cloud Platform. PostgreSQL with read replicas, or Litestream where the SQLite model genuinely fits.	Replicated SQLite is elegant for read-heavy single-writer applications. Where the write path is contended, PostgreSQL is the safer landing.

Fly Machines (microVMs)

What we run instead: Binadit Managed Cloud Platform. KVM virtual machines on Debian or Ubuntu, provisioned with Terraform and configured with Ansible.
Engineering note: 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)

What we run instead: Binadit Managed Cloud Platform. Docker images built in GitLab CI and deployed to Kubernetes, with review environments per branch.
Engineering note: Coolify's multi-server feature handles multi-region deployment patterns.

Fly Postgres (clustered)

What we run instead: Binadit Managed Cloud Platform. PostgreSQL or MySQL with Patroni for failover and pgBackRest for point-in-time recovery.
Engineering note: Patroni on EU compute is the open-source pattern that powers Fly's own Postgres offering.

Fly Redis (Upstash)

What we run instead: Binadit Managed Cloud Platform. Redis or Valkey, with Sentinel for failover.
Engineering note: Note: Upstash itself is US-headquartered, so Fly Redis is US-on-US.

Fly Volumes

What we run instead: Binadit Managed Cloud Platform. Ceph RBD, or Longhorn for Kubernetes-native volumes.
Engineering note: Standard NVMe-backed volumes; size-equivalent.

Fly Proxy (Anycast)

What we run instead: Binadit Managed Cloud Platform. HAProxy or Nginx, with keepalived for failover.
Engineering note: Health checks, connection draining and sticky sessions all carry over. TLS terminates here with certificates renewed automatically.

Fly Postgres failover (multi-region)

What we run instead: Binadit Managed Cloud Platform. Patroni-managed PostgreSQL failover across nodes, with automatic promotion.
Engineering note: For EU-only multi-region (e.g. NL + DE active-active with regional failover), Patroni handles it.

Fly Secrets

What we run instead: Binadit Managed Cloud Platform. HashiCorp Vault or Infisical, self-hosted, with automatic lease rotation.
Engineering note: Vault is the production-grade answer for any non-trivial secrets workload.

flyctl / fly deploy DX

What we run instead: Binadit DevOps & Support. kubectl, Terraform and GitLab CI, with project-specific wrappers where they help.
Engineering note: The DX gap is real but closeable. Coolify's `coolify deploy` is the closest equivalent.

Fly LiteFS (replicated SQLite)

What we run instead: Binadit Managed Cloud Platform. PostgreSQL with read replicas, or Litestream where the SQLite model genuinely fits.
Engineering note: Replicated SQLite is elegant for read-heavy single-writer applications. Where the write path is contended, PostgreSQL is the safer landing.

How we migrate off Fly.io

A typical mid-market migration runs in three phases. The numbers below assume a 6-10 person engineering team and a moderately complex application stack.

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.

Frequently asked questions

View all frequently asked questions

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.

Plan your exit from Fly.io.

30-minute scoping call. We map your stack against EU-only alternatives, estimate the migration effort, and tell you whether it is the right call.

Schedule a call Compare another provider