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, me parece que ha llegado el momento de poner por escrito qué hace bien, qué sigue siendo frágil y cuándo compensa elegirla frente a alternativas más convencionales.
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. Lo interesante es que el coste conceptual de esto queda en gran medida oculto tras una interfaz de línea de comandos simple y un fichero fly.toml declarativo. 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, por supuesto, pero normalmente exige montar redes privadas virtuales, balanceadores globales, réplicas de base de datos manuales y una buena dosis de Terraform. Fly.io lo vende ya hecho.
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. Pones tres o cinco réplicas en tres o cinco regiones, apuntas tu dominio al anycast, y cada usuario habla con la instancia más cercana sin que tengas que pensar en ello.
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. Fly.io baja drásticamente el coste de conseguirlo.
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 en muchas configuraciones. 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, algo muy difícil de replicar a ese precio en los tres grandes.
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 la de AWS con CloudWatch o la de GCP con Cloud Logging. Si tu aplicación tiene latencia misteriosa en Tokio pero va fina en Fráncfort, el tiempo que se tarda en aislar la causa puede ser frustrante. 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. Esto no es distinto de cualquier proveedor, pero la percepción pública de Fly es más frágil que la de AWS tras años de exposición pública a fallos.
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; cada uno ocupa un nicho distinto.
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. Kubernetes, aunque más flexible y portable, exige equipo dedicado, inversión en herramientas y semanas de trabajo para llegar a lo que Fly ofrece de serie. 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 y un dominio apuntado 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. Y proyectos que viven en una única región sin latencia crítica son servidos más barato por un VPS normal.
La pregunta que me hago 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. 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.
