Actualizado: 2026-07-07

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. 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 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. 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, y factura por segundo si se apaga sola cuando no hay tráfico. 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, con la advertencia explícita de que no es una base de datos gestionada[3]: 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], así que el terreno intermedio ha sido inestable; hoy la alternativa más sólida sigue siendo acudir a 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 varias horas afectando a regiones completas: un certificado caducado rompió el sistema de orquestación durante más de seis horas en octubre de 2024, y 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. 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, sobre todo si el equipo ya opera clústeres propios, como comentamos al repasar el balance operativo de Kubernetes 1.35.

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 (o con una capa como la que describimos en cómo instalar Coolify en Docker) 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.

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

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