Fly.io es una de esas plataformas que dividen opiniones con facilidad. Quien la descubre porque un colega desplegó una API en quince minutos y funciona igual en Madrid y en Sídney suele quedar encantado. Quien intenta montar encima una aplicación compleja, con bases de datos grandes, almacenamiento persistente y más de una región activa, acaba topándose con aristas. Esas aristas obligan a leer documentación y a pensar la arquitectura con cuidado.

Este artículo recoge dos años de proyectos encima de la plataforma, entre 2024 y 2025. Pone por escrito qué hace bien, qué sigue siendo frágil y cuándo compensa elegirla frente a alternativas más convencionales.

Puntos clave

  • Fly.io levanta tu aplicación dentro de una microVM Firecracker en una de sus regiones, le asigna una IP anycast y la pone detrás de su red global; desplegar en tres regiones es fly scale count 3 --region mad,gru,sin.

  • El caso de uso ideal son aplicaciones sin estado o con estado ligero que quieren servir latencia baja a usuarios repartidos por el mundo.

  • En 2024 Fly se retiró del negocio de base de datos gestionada; ahora recomienda Postgres como aplicación normal o proveedores externos como Supabase o Neon.

  • La plataforma ha tenido incidencias públicas de cierta entidad en 2023 y 2024; la transparencia del equipo con postmortems detallados es un punto positivo.

  • Un VPS clásico en Hetzner sigue siendo más barato para aplicaciones que no necesitan multirregión real.

Qué ofrece y en qué se diferencia

Fly.io levanta tu aplicación dentro de una microVM Firecracker en una de sus regiones, le asigna una IP anycast y la pone detrás de su red global. Eso significa que cuando un usuario resuelve el dominio, el tráfico llega a la región más cercana físicamente. Desde ahí puede servirse la respuesta directamente o enrutarse a otra región, si allí corre el proceso que debe atenderlo.

La promesa es que desplegar en tres regiones se reduce a ejecutar fly scale count 3 --region mad,gru,sin, y en la práctica la promesa se cumple.

Detrás de esa interfaz amable hay una arquitectura que no es trivial. La forman Firecracker como aislador, WireGuard como capa de red interna y un proxy propio llamado fly-proxy que recibe el tráfico y lo reenvía. A eso se suman volúmenes persistentes anclados a región específica y un plano de control que conoce la topología completa.

La documentación oficial de arquitectura de Fly.io[1] lo describe así: "cada servidor de nuestra infraestructura ejecuta un proxy en Rust llamado fly-proxy, responsable de aceptar conexiones de clientes, emparejarlas con la aplicación correspondiente, aplicar handlers (por ejemplo, terminación TLS) y transportar el tráfico entre servidores". No es mágico, pero está bien empaquetado.

La diferencia más clara frente a un proveedor clásico como AWS o GCP está en el diseño. Fly.io está pensado desde el primer día para que tu aplicación corra en múltiples regiones a la vez sin un esfuerzo de ingeniería grande. Los proveedores grandes también permiten multirregión, pero ahí multirregión significa montar redes privadas virtuales, balanceadores globales, réplicas de base de datos manuales y una buena dosis de Terraform.

Dónde funciona bien

El caso de uso ideal de Fly.io son aplicaciones sin estado o con estado ligero que quieren servir latencia baja a usuarios repartidos por el mundo. APIs de productos SaaS, sitios web renderizados en servidor, pasarelas de pago con usuarios globales, backends de aplicaciones móviles: todo eso se beneficia enormemente del modelo de Fly.

Otro caso que funciona bien es el de aplicaciones internas donde quieres que un equipo distribuido geográficamente tenga acceso rápido. Una herramienta interna de oficina con empleados en Madrid, Buenos Aires y Singapur va a responder mejor si hay una instancia en cada continente que si todo corre en Virginia.

El modelo de precios es competitivo para cargas pequeñas y medianas. Los planes con asignación gratuita se retiraron en octubre de 2024 y desde entonces todo se factura por consumo real.

Según el detalle de precios de Fly.io[2], una máquina compartida mínima sigue costando poco más de dos dólares al mes siempre encendida. Si se apaga sola cuando no hay tráfico, factura por segundo. Para un proyecto de lado o una empresa en fase temprana, mantener una API global con tres regiones por una cifra que ronda los quince o veinte dólares al mes sigue siendo realista.

Dónde se complica

El primer reto aparece con el estado. Fly Volumes son volúmenes persistentes anclados a una región concreta, no replicados automáticamente. Si tu aplicación multirregión necesita persistencia local, cada región tiene su volumen independiente, y la coordinación queda en tu lado.

Para PostgreSQL, Fly retiró en 2024 su producto de clústeres gestionados y pasó a recomendar Postgres como aplicación normal. La advertencia es explícita: no es una base de datos gestionada[3], y si se queda sin memoria o disco, el trabajo de recuperarla es tuyo. Después probaron un acuerdo con Supabase para gestionar Postgres sobre Fly, que Supabase dejó de mantener en abril de 2025[4].

El terreno intermedio ha sido inestable, y hoy la alternativa más sólida sigue siendo un proveedor externo como Neon. Esto tiene sentido para Fly pero traslada trabajo operativo, y cierta incertidumbre de continuidad, a quien despliega.

El segundo reto es la observabilidad y el diagnóstico cuando algo va mal. Fly expone logs y métricas básicas, pero la experiencia de depurar un fallo raro en una de quince regiones no es tan sólida como AWS con CloudWatch. Hay integraciones con Grafana, Datadog y similares que mejoran la experiencia, pero requieren configurarlas.

El tercer reto es que la plataforma ha tenido incidencias públicas de cierta entidad en 2023 y 2024, algunas con caídas de horas enteras que afectaron a regiones completas. Un certificado caducado rompió el sistema de orquestación durante más de seis horas en octubre de 2024. Un fallo de concurrencia en fly-proxy tumbó el enrutamiento de peticiones en septiembre del mismo año.

El historial público de incidentes de Fly.io[5] documenta estos y otros episodios con fecha y duración. El equipo ha sido transparente con postmortems detallados, pero si tu aplicación es crítica tienes que asumir que ese riesgo existe y tener un plan de contingencia.

Comparación con alternativas cercanas

Railway y Render son los competidores más directos en el segmento de plataformas modernas. Railway es excelente en experiencia de desarrollador y bases de datos gestionadas pero vive esencialmente en una región central. Render ofrece un abanico similar pero también enfocado principalmente a regiones únicas o duales.

Ninguno de los dos compite realmente con Fly.io en el eje de despliegue global. Esta misma comparativa la desarrollamos en Railway y Render: plataformas de despliegue sin sorpresas.

Frente a Kubernetes más operadores, la diferencia es abismal: Fly esconde casi toda la complejidad y tú escribes un fichero de cincuenta líneas. Mientras el proyecto no sea enorme, el cálculo favorece a Fly. Para los que sí lo son, Kubernetes gana en flexibilidad y en no estar atado a un proveedor, sobre todo si el equipo ya opera clústeres propios. Lo comentamos al repasar el balance operativo de Kubernetes 1.35.

Un VPS clásico en Hetzner o OVH sigue siendo razonable para una aplicación que no necesita multirregión. Si no necesitas multirregión, si tu aplicación sirve a un ámbito geográfico acotado y si quieres control total del sistema operativo, un VPS bien configurado con Docker Compose es viable y mucho más barato. Puedes añadirle una capa como la que describimos en cómo instalar Coolify en Docker. Fly.io brilla cuando el requisito de globalidad es real, no cuando se ha puesto por moda.

Ejemplo mínimo de despliegue

app = "mi-api"
primary_region = "mad"

[build]
  image = "ghcr.io/org/mi-api:1.4.0"

[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_start_machines = true
  auto_stop_machines = true
  min_machines_running = 0

  [[services.ports]]
    port = 443
    handlers = ["tls", "http"]

Ese fichero, más un fly deploy, pone la aplicación en Madrid. Añadir Brasil y Singapur es fly scale count 3 --region mad,gru,sin. Desde el punto de vista de experiencia de desarrollo es difícil competir con esa sencillez.

Mi lectura

Fly.io es una herramienta buena para un perfil concreto de proyecto: aplicaciones pequeñas o medianas que sirven a usuarios globales, sin estado complicado o con estado externalizado a servicios gestionados. El equipo detrás es pequeño y no quiere dedicar tiempo a operar infraestructura. Para ese perfil, Fly es probablemente la mejor opción disponible en 2025, sobre todo si se combina con una base de datos gestionada externa como Neon o PlanetScale.

Fuera de ese perfil, la cosa se complica. Aplicaciones con mucho estado local, requisitos regulatorios estrictos sobre residencia de datos en países concretos, cargas de datos pesadas o necesidades de orquestación compleja encajan mejor con proveedores clásicos o con Kubernetes gestionado.

La pregunta que conviene hacer antes de llevar un proyecto a Fly.io es si la globalidad es un requisito real medido en minutos de mejora para el usuario, o es una aspiración estética. Cuando es real, Fly.io ahorra semanas de trabajo y meses de complejidad operativa. Cuando no lo es, introduce un proveedor nuevo con su propio modelo mental sin aportar valor suficiente.

Conclusión

Esa distinción, hecha con honestidad, es la que separa los despliegues felices en Fly de los que acaban arrepintiéndose seis meses después.

Este artículo también está disponible en inglés: léelo en inglés aquí.

Fuentes:

  1. Fly.io: The Fly.io Architecture (Firecracker, fly-proxy, WireGuard, anycast)[1]
  2. Fly.io: Postgres on Fly.io, "This Is Not Managed Postgres"[3]
  3. Supabase: Deprecation of Fly.io Postgres Managed by Supabase on April 11, 2025[4]
  4. Fly.io Status: historial público de incidentes[5]
  5. Fly.io: precios y facturación por consumo[2]

Preguntas frecuentes

¿Cómo despliego mi aplicación en varias regiones de Fly.io?

Con un fly.toml mínimo más fly deploy la aplicación queda en la región primaria (por ejemplo primary_region = "mad"); añadir Brasil y Singapur es ejecutar fly scale count 3 --region mad,gru,sin. Fly levanta cada instancia en una microVM Firecracker y le asigna una IP anycast. El tráfico llega a la región más cercana al usuario, y desde ahí se sirve directamente o se enruta a otra región.

¿Ofrece Fly.io una base de datos PostgreSQL gestionada?

No. En 2024 Fly retiró su producto de clústeres gestionados y pasó a recomendar Postgres como aplicación normal, con la advertencia explícita de que si se queda sin memoria o disco la recuperación es tuya. El acuerdo posterior con Supabase para gestionar Postgres sobre Fly dejó de mantenerse en abril de 2025, así que hoy la alternativa más sólida es un proveedor externo como Neon o PlanetScale.

¿Cuánto cuesta mantener una API global en Fly.io?

Desde octubre de 2024 no hay planes con asignación gratuita y todo se factura por consumo real. Una máquina compartida mínima cuesta poco más de dos dólares al mes siempre encendida, y se factura por segundo si se apaga sola sin tráfico (auto_stop_machines = true, min_machines_running = 0). Una API con tres regiones ronda los quince o veinte dólares al mes; un VPS en Hetzner sigue siendo más barato si no necesitas multirregión real.

Fuentes

  1. documentación oficial de arquitectura de Fly.io
  2. detalle de precios de Fly.io
  3. no es una base de datos gestionada
  4. dejó de mantener en abril de 2025
  5. historial público de incidentes de Fly.io