Alternativa solo UE a 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 Pila de reemplazo, solo UE 10 servicios mapeados

Agendar una llamada Escanee primero su dominio

Proveedor: Fly.io
Sede: Chicago, IL
Jurisdicción: United States
Régimen legal: CLOUD Act, FISA 702

"Región UE" no es soberanía. Cuatro preguntas lo deciden.

La residencia de datos dice dónde están los bits. La soberanía dice qué sistema legal puede obligar al acceso. La respuesta debe sostenerse en los cuatro puntos, o la pila no es soberana.

Residencia

¿Dónde se almacenan físicamente los datos?

No "en la nube": qué centro de datos, en qué país, bajo qué jurisdicción.

Subprocesadores

¿Quién más está en su ruta de datos?

Cada proveedor que toca los datos: el CDN, el relay de correo, el rastreador de errores, el pipeline de analítica.

Jurisdicción

¿Qué leyes pueden obligar a la divulgación?

Un proveedor con sede en EE. UU. está sujeto a la FISA 702 y a la CLOUD Act, aunque los datos estén en Fráncfort.

Custodia de claves

¿Quién posee realmente las claves de cifrado?

Si el proveedor cloud posee tanto los datos como las claves, puede leerlos, con independencia de cualquier DPA.

No cumple AWS · Azure · GCP · Región de la UE

Falla en jurisdicción y custodia de claves.

Bits en la UE, matriz con sede en EE. UU., subprocesadores estadounidenses en la ruta por defecto, claves gestionadas por el proveedor.

Cumple Stack gestionado por Binadit

Pasa en los cuatro.

Alojado en la UE sobre infraestructura con sede europea. Cero subprocesadores estadounidenses en la ruta por defecto. Claves del cliente o de un KMS europeo. Nombrados en su DPA del Artículo 28.

Por qué los equipos están saliendo 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 servicios y sus equivalentes solo en la UE

Una migración no es "cambiar una caja por otra". El mapeo a continuación es lo que ejecutamos para los clientes que dejan Fly.io por motivos de Schrems II: jurisdicción europea completa, sin matriz estadounidense en la ruta de datos.

Fly.io servicio	Lo que usamos en su lugar	Nota de ingeniería
Fly Machines (microVMs)	Binadit Managed Cloud Platform. Máquinas virtuales KVM sobre Debian o Ubuntu, aprovisionadas con Terraform y configuradas con Ansible.	Para la mayoría de las cargas de trabajo, las VMs regulares con despliegue multi-región vía DNS GeoIP cubren el caso de uso. Para un verdadero microVM por solicitud, Firecracker autoalojado en cómputo de la UE es la respuesta soberana.
Fly Apps (PaaS layer)	Binadit Managed Cloud Platform. Imágenes Docker construidas en GitLab CI y desplegadas en Kubernetes, con entornos de revisión por branch.	La función multi-server de Coolify gestiona patrones de despliegue multi-región.
Fly Postgres (clustered)	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni para failover y pgBackRest para recuperación point-in-time.	Patroni en cómputo de la UE es el patrón open-source que impulsa la propia oferta de Postgres de Fly.
Fly Redis (Upstash)	Binadit Managed Cloud Platform. Redis o Valkey, con Sentinel para failover.	Nota: Upstash tiene su sede en EE. UU., por lo que Fly Redis es US-on-US.
Fly Volumes	Binadit Managed Cloud Platform. Ceph RBD, o Longhorn para volúmenes Kubernetes-native.	Volúmenes respaldados por NVMe estándar; de tamaño equivalente.
Fly Proxy (Anycast)	Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived para failover.	Los health checks, el connection draining y las sticky sessions se conservan todos. TLS termina aquí con certificados renovados automáticamente.
Fly Postgres failover (multi-region)	Binadit Managed Cloud Platform. Failover de PostgreSQL gestionado por Patroni entre nodos, con promoción automática.	Para multi-región exclusivamente en la UE (por ejemplo, NL + DE activo-activo con failover regional), Patroni lo gestiona.
Fly Secrets	Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, autoalojado, con rotación automática de leases.	Vault es la respuesta de calidad producción para cualquier carga de trabajo de secretos no trivial.
flyctl / fly deploy DX	Binadit DevOps & Support. kubectl, Terraform y GitLab CI, con wrappers específicos del proyecto donde resulten útiles.	La brecha de DX es real pero se puede cerrar. El `coolify deploy` de Coolify es el equivalente más cercano.
Fly LiteFS (replicated SQLite)	Binadit Managed Cloud Platform. PostgreSQL con read replicas, o Litestream donde el modelo SQLite realmente encaja.	SQLite replicado es elegante para aplicaciones con un solo escritor y muchas lecturas. Cuando la ruta de escritura está saturada, PostgreSQL es la opción más segura.

Fly Machines (microVMs)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Máquinas virtuales KVM sobre Debian o Ubuntu, aprovisionadas con Terraform y configuradas con Ansible.
Nota de ingeniería: Para la mayoría de las cargas de trabajo, las VMs regulares con despliegue multi-región vía DNS GeoIP cubren el caso de uso. Para un verdadero microVM por solicitud, Firecracker autoalojado en cómputo de la UE es la respuesta soberana.

Fly Apps (PaaS layer)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Imágenes Docker construidas en GitLab CI y desplegadas en Kubernetes, con entornos de revisión por branch.
Nota de ingeniería: La función multi-server de Coolify gestiona patrones de despliegue multi-región.

Fly Postgres (clustered)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni para failover y pgBackRest para recuperación point-in-time.
Nota de ingeniería: Patroni en cómputo de la UE es el patrón open-source que impulsa la propia oferta de Postgres de Fly.

Fly Redis (Upstash)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Redis o Valkey, con Sentinel para failover.
Nota de ingeniería: Nota: Upstash tiene su sede en EE. UU., por lo que Fly Redis es US-on-US.

Fly Volumes

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Ceph RBD, o Longhorn para volúmenes Kubernetes-native.
Nota de ingeniería: Volúmenes respaldados por NVMe estándar; de tamaño equivalente.

Fly Proxy (Anycast)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. HAProxy o Nginx, con keepalived para failover.
Nota de ingeniería: Los health checks, el connection draining y las sticky sessions se conservan todos. TLS termina aquí con certificados renovados automáticamente.

Fly Postgres failover (multi-region)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Failover de PostgreSQL gestionado por Patroni entre nodos, con promoción automática.
Nota de ingeniería: Para multi-región exclusivamente en la UE (por ejemplo, NL + DE activo-activo con failover regional), Patroni lo gestiona.

Fly Secrets

Lo que usamos en su lugar: Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, autoalojado, con rotación automática de leases.
Nota de ingeniería: Vault es la respuesta de calidad producción para cualquier carga de trabajo de secretos no trivial.

flyctl / fly deploy DX

Lo que usamos en su lugar: Binadit DevOps & Support. kubectl, Terraform y GitLab CI, con wrappers específicos del proyecto donde resulten útiles.
Nota de ingeniería: La brecha de DX es real pero se puede cerrar. El `coolify deploy` de Coolify es el equivalente más cercano.

Fly LiteFS (replicated SQLite)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. PostgreSQL con read replicas, o Litestream donde el modelo SQLite realmente encaja.
Nota de ingeniería: SQLite replicado es elegante para aplicaciones con un solo escritor y muchas lecturas. Cuando la ruta de escritura está saturada, PostgreSQL es la opción más segura.

Cómo migramos desde Fly.io

Una migración típica de mid-market se desarrolla en tres fases. Los números a continuación asumen un equipo de ingeniería de 6 a 10 personas y un stack de aplicación moderadamente complejo.

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.

Preguntas frecuentes

Ver todas las preguntas frecuentes

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.

Planifique su salida de Fly.io.

Llamada de alcance de 30 minutos. Mapeamos su stack frente a alternativas solo UE, estimamos el esfuerzo de migración y le decimos si es la decisión correcta.

Agendar una llamada Comparar otro proveedor