Desplegar un agente IA en Fly.io: Machines, precios y dominio

Entre Railway (proceso con volumen, un clic) y el VPS con Docker (control total, tú parcheas) hay Fly.io: Machines que facturan por segundo, deploy con flyctl, y un proxy global. Para un agente que debe estar cerca de los usuarios o dormir cuando no hay tráfico, ese modelo es el que más se parece a “VPS sin el VPS”. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Si tu agente es un webhook corto, Workers o Functions salen más simples. Aquí el foco es un proceso en una Machine.

Cuándo sí y cuándo no

Sí, si el agente:

• Es un proceso Node/Python que quieres cerca de una región concreta.
• Puede apagarse cuando no hay requests (autostop) y volver a arrancar.
• Ya tienes Dockerfile — Fly Launch lo usa o detecta el framework.

No, si el agente:

• Es un cron de 10 líneas: un Worker scheduled sale más barato.
• Necesitas el dashboard más simple posible: Railway gana en UX.
• Quieres un precio plano de USD 5/mes sin mirar segundos: el VPS es más predecible.

Precio que sí importa (shared-cpu-1x)

RAM	Precio/hora	Precio/mes (siempre encendida)
256 MB	USD 0.0028	~USD 2.02
512 MB	USD 0.0046	~USD 3.32
1 GB	USD 0.0082	~USD 5.92
2 GB	USD 0.0154	~USD 11.11

Cifras de la tabla oficial de Fly.io (shared-cpu-1x, 1 CPU compartida). El cobro es por segundo. Si la Machine duerme 20 h al día, pagas las 4 h que corrió, no el mes. Un agente de webhook con autostop suele quedar por debajo de Railway Hobby; un agente que hace polling 24/7 se acerca al VPS y entonces el VPS gana por simplicidad de factura.

Paso 1 — launch y deploy

Instala flyctl, autentica, y desde el repo del agente:

fly launch
fly deploy

fly launch genera fly.toml y, si hay Dockerfile, lo usa. Si no, escanea el framework. fly deploy construye la imagen y arranca una o más Machines con esa config.

Estrategias de deploy (docs de fly deploy):

• rolling (default): espera a que cada Machine esté bien antes de la siguiente.
• immediate: baja todas a la vez.
• canary: una Machine nueva, verifica health, luego rolling.
• bluegreen: una Machine nueva al lado de cada una en la misma región; el tráfico migra cuando todas están listas.

Para un agente de un solo inquilino, rolling alcanza. canary vale cuando un deploy malo tumba webhooks de clientes.

Paso 2 — secretos y proceso

Los secretos van por fly secrets set OPENAI_API_KEY=..., no en fly.toml. El resto (rotación, no loguear) está en secretos y variables de entorno. El proceso debe escuchar en 0.0.0.0 y el puerto que declara fly.toml; si bindeas localhost, el proxy de Fly no te alcanza — el mismo síntoma que en Docker Compose.

Réplicas y volúmenes

fly scale count no comparte un sqlite. Un volumen se adjunta a una Machine (docs de Volumes overview, 3 sep 2026): mapeo 1:1, y al subir el count Fly crea volúmenes vacíos o reusa desadjuntos — no copia datos. Si el agente escribe estado local, deja count 1. El detalle está en concurrencia y réplicas.

Paso 3 — dominio y certificado

fly certs add agente.tudominio.com

Fly te muestra las opciones DNS. Lo recomendado: registros A y AAAA al anycast de la app. El certificado se emite cuando Fly puede validar el dominio por al menos uno de: AAAA hacia la app, CNAME _acme-challenge, o TXT _fly-ownership. Si falta la validación, el cert no sale — no es un bug de TLS, es DNS.

Errores comunes

Síntoma	Causa típica	Fix
502 al primer request	Machine dormida y healthcheck lento	Sube el grace del check o acepta el cold start; no uses Fly si el webhook del proveedor corta a 3 s
Certificado pendiente	DNS sin AAAA / _acme-challenge / TXT de ownership	fly certs add te dice qué falta; crea ese registro, no otro
Factura más alta que Railway	Autostop desactivado y Machine 24/7	Revisa Machines → autostop; si debe estar 24/7, compara con VPS
Deploy deja el agente viejo	Estrategia immediate a medias o healthcheck rojo	Mira logs de fly deploy; pasa a rolling o canary
Agente no recibe tráfico	Bind a 127.0.0.1	Escucha en 0.0.0.0 y el puerto de fly.toml

Relación con el resto del stack

• Decidir: Vercel vs Workers vs VPS.
• UX simple + volumen: Railway.
• Control total: Docker en VPS.
• Webhook corto en el borde: Workers / Functions.

Fly no reemplaza ninguna. Encaja cuando quieres región + autostop + Dockerfile, sin SSH.

Un patrón que sí se repite: el webhook entra por Workers (2xx rápido, cobro por CPU) y el trabajo largo corre en una Machine de Fly con autostop. Así no pagas una Machine 24/7 ni te comes el maxDuration de Functions. No clones el agente en los dos sitios: el Worker valida y reenvía; Fly ejecuta.

Checklist de producción

• fly.toml con el puerto real del agente
• Secretos por fly secrets set, no en git
• Autostop decidido (on = ahorro, off = latencia estable)
• DNS A/AAAA o challenge ACME antes de esperar el cert
• Estrategia rolling o canary, no immediate en prod
• fly logs abierto el primer día de tráfico

---

Siguiente paso: si el agente ejecuta código, combina Fly con sandboxing. Si todavía no tienes runtime, el curso gratuito deja un agente local para meterlo en el Dockerfile.