Fly.io: desplegar globalmente sin complicarte

Actualizado: 2026-05-03

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 muchas regiones activas a menudo se topa con aristas que obligan a leer documentación y a pensar la arquitectura con cuidado. Después de varios proyectos encima de la plataforma a lo largo de 2024 y 2025, este artículo 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 varias 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, y desde ahí puede servirse la respuesta directamente o enrutarse a otra región si allí vive el proceso que debe atenderlo.

La promesa es que desplegar en varias regiones es tan sencillo como ejecutar fly scale count 3 --region mad,gru,sin, y en la mayoría de casos la promesa se cumple.

Detrás de esa interfaz amable hay una arquitectura que no es trivial: Firecracker como aislador, WireGuard como capa de red interna, un proxy propio llamado fly-proxy que recibe el tráfico y lo reenvía, volúmenes persistentes anclados a región específica, y un plano de control que conoce la topología completa. No es mágico, pero está bien empaquetado.

La diferencia más clara frente a un proveedor clásico como AWS o GCP es que Fly.io está pensado desde el primer día para que tu aplicación viva en múltiples regiones a la vez sin que eso suponga un esfuerzo de ingeniería grande. Los proveedores grandes también permiten multirregión, pero normalmente exige 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. La capa gratuita original desapareció en 2024, pero las máquinas pequeñas siguen siendo baratas, facturadas por segundo, y escalan a cero cuando no hay tráfico. Para un proyecto de lado o una empresa en fase temprana, mantener una API global con tres regiones por quince o veinte dólares al mes es 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 ofreció durante años un producto gestionado, pero en 2024 se retiraron del negocio de base de datos gestionada y ahora recomiendan desplegar Postgres como aplicación normal o usar proveedores externos como Supabase o Neon. Esto tiene sentido para ellos pero traslada trabajo operativo 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 varias horas afectando a regiones completas. 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. Para la mayoría de proyectos que no son enormes, el cálculo favorece a Fly; para los que lo son, Kubernetes gana en flexibilidad y en no estar atado a un proveedor.

Un VPS clásico en Hetzner o OVH sigue siendo razonable para muchas aplicaciones. Si no necesitas multirregión, si tu aplicación está en un dominio geográfico acotado, si quieres control total sobre el sistema operativo, un VPS bien configurado con Docker Compose es perfectamente viable y mucho más barato. 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 muy buena para un perfil concreto de proyecto: aplicaciones pequeñas o medianas, con requisito de servir a usuarios globales, sin estado complicado o con estado externalizado a servicios gestionados, y con un equipo pequeño que 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.