En esta cápsula vas a poner las tres plataformas lado a lado con datos concretos. Has desplegado tu app AI en Render (cápsula 02), Railway (cápsula 03) y Fly.io (cápsula 04). Ahora toca comparar de forma estructurada: pricing real, límites de free tier, features, limitaciones para AI workloads, soporte de bases de datos, auto-scaling, tiempos de deploy, y developer experience. Las tablas de esta cápsula son las que consultas cuando necesitas elegir plataforma para un proyecto.
Por qué importa: Las comparativas genéricas online dicen "las tres son buenas." Eso no te sirve. Necesitas saber: ¿cuál tiene timeout más largo para AI? ¿Cuál soporta WebSockets para streaming? ¿Cuál es más barata para un MVP que corre 24/7? ¿Cuál escala a multi-region sin configuración compleja? Esta cápsula responde con números, no con opiniones.
⚠️ Limitante para inferencia larga. Streaming obligatorio para respuestas > 30s
Railway
5 minutos
✅ Suficiente para la mayoría de AI workloads
Fly.io
Configurable (default 60s)
✅ Ajustable según necesidad
Memory Limits
Plataforma
Free
Mínimo pago
Máximo
Render
512 MB
512 MB (Starter)
8 GB (Pro Plus)
Railway
Variable (~512 MB)
Configurable
32 GB (Pro)
Fly.io
256 MB
256 MB (shared)
16 GB+ (dedicated)
WebSocket y Streaming
Feature
Render
Railway
Fly.io
WebSocket
⚠️ Starter+ (no en Free)
✅ Soportado
✅ Soportado
Server-Sent Events (SSE)
✅ Soportado
✅ Soportado
✅ Soportado
Streaming tokens LLM
⚠️ SSE funciona, WS limitado
✅ Full support
✅ Full support
Cold Start
Plataforma
Con sleep habilitado
Sin sleep
Render Free
15,000-45,000ms
N/A (siempre sleep)
Render Starter
N/A (siempre running)
0ms
Railway (sleep)
2,000-8,000ms
0ms
Fly.io (auto-stop)
300-2,000ms
0ms
Fly.io (min=1)
N/A (siempre running)
0ms
Container Size y Build
Aspecto
Render
Railway
Fly.io
Max image size
Sin límite documentado
Sin límite documentado
10 GB
Build timeout
30 minutos
30 minutos
No documentado (largo)
Build cache
✅ Docker layer cache
✅ Nixpacks cache (agresivo)
✅ Docker layer cache
Build speed
Medio
Rápido (Nixpacks)
Medio
Comparativa: Developer Experience
Tiempo de Setup (primera vez)
Paso
Render
Railway
Fly.io
Crear cuenta
1 min (GitHub OAuth)
1 min (GitHub OAuth)
2 min (email + tarjeta)
Primer deploy
3-5 min (dashboard)
2-3 min (CLI)
5-7 min (CLI + config)
Custom domain
5 min
3 min
5 min
Total setup
~10 min
~6 min
~12 min
Workflow diario
Acción
Render
Railway
Fly.io
Deploy
git push (auto)
git push o railway up
flyctl deploy
Ver logs
Dashboard → Logs
railway logs o Dashboard
flyctl logs o Dashboard
Agregar variable
Dashboard → Env
railway variables set
flyctl secrets set
Agregar base de datos
Dashboard → New → PostgreSQL
railway add
flyctl postgres create
Escalar
Dashboard → Settings
Dashboard → Settings
flyctl scale count N
SSH al container
❌
❌
flyctl ssh console
Conectar a DB local
❌ (copiar URL manual)
railway connect postgres
flyctl postgres connect
CLI Power
Capacidad
Render
Railway
Fly.io
CLI oficial
❌ (solo API REST)
✅ Completo
✅ Completo
Deploy desde terminal
❌
✅ railway up
✅ flyctl deploy
Variables desde terminal
❌
✅ railway variables
✅ flyctl secrets
Logs desde terminal
❌
✅ railway logs
✅ flyctl logs
DB connect desde terminal
❌
✅ railway connect
✅ flyctl postgres connect
Comparativa: Cuándo Elegir Cada Una
Decision Quick-Reference
¿Quieres simplicidad absoluta + pricing predecible?
→ Render
¿Quieres la mejor developer experience + prototipos rápidos?
→ Railway
¿Necesitas multi-region o baja latencia global?
→ Fly.io
¿Tienes equipo y necesitas preview environments?
→ Railway
¿Presupuesto mínimo y no te importa cold start?
→ Fly.io (free tier más generoso en CPU)
¿App AI con streaming de tokens?
→ Railway o Fly.io (mejor soporte WebSocket)
¿Enterprise, compliance, SLA garantizado?
→ Ninguna de las tres — usa AWS
Escenarios concretos para AI
Escenario
Mejor opción
Por qué
MVP chatbot AI, 1 developer
Railway
Deploy más rápido, CLI excelente
API de inferencia, equipo de 3
Railway
Preview environments, add-ons
RAG app para empresa global
Fly.io
Multi-region, baja latencia
Demo para investors
Render
Predecible, fácil de explicar
Proyecto personal, $0/mes
Fly.io
Free tier más generoso (3 VMs)
App con streaming largo
Fly.io
Timeout configurable, WS nativo
Startup early-stage, presupuesto $50/mes
Railway
Buena relación DX/precio
App AI + PostgreSQL + Redis
Railway
Add-ons integrados, variables automáticas
Need to self-host LLM
Ninguna
Necesitas GPU → RunPod, Lambda Labs
Tabla Resumen: The Big Picture
Dimensión
Render
Railway
Fly.io
AWS (Lambda)
Filosofía
Simplicidad
Developer Experience
Edge Computing
Control total
Deploy time
3-5 min
2-3 min
5-7 min
30-60 min
Free tier
Limitado (sleep)
$5 crédito
3 VMs gratis
1M requests/mes
Pricing modelo
Plan fijo
Pay-per-use
Pay-per-use
Pay-per-use
Cost $$ (AI app)
~$21/mes
~$25-30/mes
~$10-15/mes
~$15-40/mes
Multi-region
❌
❌
✅
✅ (con config)
Request timeout
30s
5 min
Configurable
15 min
WebSocket
Starter+
✅
✅
⚠️ (API GW)
Cold start
15-45s (free)
2-8s
0.3-2s
1-10s
CLI
❌
✅✅
✅✅
✅ (aws cli)
Databases
PG, Redis
PG, Redis, MySQL, Mongo
PG, Redis
RDS, ElastiCache
Complejidad
Baja
Baja
Media
Alta
Vendor lock-in
Bajo
Bajo
Medio
Alto
GPU
❌
❌
❌
✅ (SageMaker)
Ejercicios Prácticos
Ejercicio 1: Matriz de evaluación personalizada
Crea una tabla de evaluación para TU caso de uso específico. Define 5 criterios con pesos y evalúa cada plataforma del 1 al 5.
Ver solución
# platform_evaluation.py
criteria = {
"Coste mensual": 25,
"Developer experience": 20,
"Tiempo de deploy": 15,
"Soporte AI (timeout, RAM)": 20,
"Escalabilidad futura": 20,
}
scores = {
"Render": {
"Coste mensual": (3, "$21/mes — predecible pero no el más barato"),
"Developer experience": (3, "Dashboard simple, no CLI"),
"Tiempo de deploy": (4, "Git push → auto deploy"),
"Soporte AI (timeout, RAM)": (2, "30s timeout es limitante"),
"Escalabilidad futura": (3, "Horizontal scaling, pero single region"),
},
"Railway": {
"Coste mensual": (3, "$25-30/mes — flexible pero menos predecible"),
"Developer experience": (5, "CLI excelente, preview envs, add-ons"),
"Tiempo de deploy": (5, "railway up — el más rápido"),
"Soporte AI (timeout, RAM)": (4, "5 min timeout, hasta 32 GB RAM"),
"Escalabilidad futura": (3, "Auto-scaling, pero single region"),
},
"Fly.io": {
"Coste mensual": (4, "$10-15/mes — el más barato"),
"Developer experience": (3, "CLI potente pero más setup inicial"),
"Tiempo de deploy": (3, "flyctl deploy — medio"),
"Soporte AI (timeout, RAM)": (4, "Timeout configurable, WS nativo"),
"Escalabilidad futura": (5, "Multi-region nativo, edge"),
},
}
print("=== Evaluación de Plataformas ===\n")
print(f"{'Criterio':<30}{'Peso':>4}{'Render':>8}{'Railway':>8}{'Fly.io':>8}")
print("-" * 70)
totals = {"Render": 0, "Railway": 0, "Fly.io": 0}
for criterion, weight in criteria.items():
print(f"{criterion:<30}{weight:>4}", end="")
for platform in ["Render", "Railway", "Fly.io"]:
score, _ = scores[platform][criterion]
weighted = weight * score
totals[platform] += weighted
print(f" {weighted:>6}", end="")
print()
print("-" * 70)
print(f"{'TOTAL':<30}{sum(criteria.values()):>4}", end="")
for platform in ["Render", "Railway", "Fly.io"]:
print(f" {totals[platform]:>6}", end="")
print()
max_possible = sum(criteria.values()) * 5print(f"\nMáximo posible: {max_possible}")
winner = max(totals, key=totals.get)
print(f"Ganador: {winner} ({totals[winner]}/{max_possible})")
Ejercicio 2: Benchmark de latencia comparativo
Ejecuta un benchmark que mida la latencia de health check y de inferencia en las tres plataformas simultáneamente.
## Output típico
--- Render ---
compute $7.00/mes
postgresql $7.00/mes
redis $7.00/mes
openai_api $180.00/mes
TOTAL mensual $201.00/mes
TOTAL 6 meses $1206.00
--- Railway ---
base $5.00/mes
compute $25.28/mes
openai_api $180.00/mes
TOTAL mensual $210.28/mes
TOTAL 6 meses $1261.68
--- Fly.io ---
compute_vm $1.94/mes
ram_extra $4.46/mes
postgresql $1.94/mes
volume $0.15/mes
openai_api $180.00/mes
TOTAL mensual $188.49/mes
TOTAL 6 meses $1130.94
Nota: El coste de OpenAI API domina en todos los casos.
La diferencia entre plataformas (~$20/mes) es marginal
comparada con $180/mes de API.
Ejercicio 4: Documentar limitaciones para tu caso específico
Para cada plataforma, documenta las 3 limitaciones más impactantes para TU app AI específica y los workarounds que usarías.
Ver solución
# Limitaciones para DocuSearch AI (RAG + GPT-4o-mini)## Render1.**Timeout 30s:** Mi endpoint /ask tarda ~2-3s normalmente, pero queries
complejas con mucho contexto RAG pueden tardar 10-15s. Si agrego
streaming, podría tocar los 30s fácilmente.
→ Workaround: Implementar SSE streaming obligatorio para /ask
2.**No CLI:** Para hotfixes rápidos, necesito ir al dashboard.
Deploy es por git push, lo cual está bien, pero gestionar variables
y ver logs requiere el browser.
→ Workaround: Usar Render API con curl/scripts
3.**PostgreSQL Free: 97 días.** Si uso el free tier para desarrollo,
pierdo datos cada ~3 meses.
→ Workaround: Starter ($7/mes) o exportar datos periódicamente
## Railway1.**Pricing impredecible:** Con 3K requests/día, el coste varía según
uso de CPU. Un spike de tráfico = factura inesperada.
→ Workaround: Configurar resource limits y alertas de billing
2.**Single region:** Mis usuarios están en Latinoamérica. Railway no me
deja elegir región cercana (São Paulo no disponible directamente).
→ Workaround: Aceptar latencia extra o usar Fly.io para esos usuarios
3.**Trial $5 dura poco:** Para testing, los $5 se agotan en ~5-7 días
con la app corriendo. Necesito Hobby ($5/mes) desde el día 1.
→ Workaround: Upgrade inmediato a Hobby
## Fly.io1.**Volumes region-locked:** Si escalo a multi-region, cada región necesita
su propio volume. No puedo compartir cache entre regiones.
→ Workaround: Usar Redis (Upstash) para cache compartido, volumes solo
para datos locales
2.**Más setup inicial:** flyctl launch + fly.toml + secrets + deploy es
más pasos que railway up.
→ Workaround: Scriptar el setup en un Makefile
3.**Shared CPU variable:** En shared, el rendimiento de CPU fluctúa.
Embedding generation puede ser lenta en horas pico.
→ Workaround: Pre-generar embeddings offline, usar dedicated CPU ($31/mes)
si el rendimiento es crítico
Troubleshooting
Problema 1: "¿Cuál es la más barata para mi caso?"
Solución: Depende del patrón de uso. Para una app 24/7 con 1 GB RAM:
Si quieres predecibilidad: Render ($21/mes con PG + Redis)
Si quieres mínimo absoluto: Fly.io (~$10/mes)
Si quieres balance DX/coste: Railway (~$25/mes)
En todos los casos, el coste de la API del LLM (OpenAI) domina la factura. La diferencia entre plataformas es marginal.
Problema 2: "Mi app necesita streaming y el timeout de Render no alcanza"
Solución: Usa SSE (Server-Sent Events) en Render — los timeouts de SSE son diferentes de HTTP requests normales. Alternativa: cambia a Railway (5 min timeout) o Fly.io (configurable).
Problema 3: "Necesito PostgreSQL con pgvector para embeddings"
Solución:
Render: pgvector disponible en plan Standard+ ($20/mes)
Railway: pgvector disponible con plugin PostgreSQL
Fly.io: Fly Postgres soporta pgvector (necesitas configurar la extensión)
Alternativa: Usar un servicio de vectores dedicado (Pinecone, Qdrant Cloud)
Problema 4: "¿Hay vendor lock-in?"
Solución: Mínimo en las tres. Tu app es un Docker container — funciona en cualquier plataforma que corra containers. Lo que te "ata" son:
Render: render.yaml (fácil de reemplazar)
Railway: railway.toml (mínimo)
Fly.io: fly.toml + volumes + multi-region config (más lock-in)
La migración entre plataformas es trivial: cambiar config file + redirigir DNS.
Resumen
Render = Simplicidad + pricing predecible. Ideal para demos y MVPs donde no quieres sorpresas. Limitado por timeout de 30s.
Railway = Mejor DX + prototipos rápidos. Ideal para developers que viven en la terminal. Pricing menos predecible.
Fly.io = Edge + multi-region + menor coste. Ideal para apps globales o presupuesto ajustado. Más setup inicial.
Para AI workloads: El timeout de Render (30s) es la limitación más impactante. Railway (5 min) y Fly.io (configurable) son más permisivos.
El coste de LLM APIs domina. La diferencia entre plataformas (~$10-20/mes) es irrelevante frente al coste de OpenAI ($100-500/mes).
Ninguna tiene GPU. Para inferencia local de modelos grandes, necesitas servicios especializados.
Vendor lock-in es bajo en las tres: tu app es un Docker container portable.
No hay "mejor" universal — hay mejor para TU caso, TUS constraints, TU stage.