Desplegar un agente IA en Railway: guía práctica con costos reales

Entre Vercel, Cloudflare Workers y un VPS hay una tercera opción que casi siempre aparece en la conversación: Railway. Es el punto medio exacto — te quitas de encima daemon, firewall y certificados del VPS, pero conservas un proceso que corre lo que quieras, con memoria persistente y sin el modelo serverless de funciones efímeras. Para agentes con estado, webhooks largos o colas en proceso, ese punto medio resuelve. Esta guía cubre el deploy real y los costos reales para decidir. Las fuentes oficiales fueron consultadas el 3 de septiembre de 2026.

Cuándo Railway y cuándo no

Sí, si tu agente:

• Es un proceso Node/Python que mantienes vivo (long polling, colas en memoria, cron interno).
• Necesita memoria persistente sin paginar un VPS completo: los volúmenes van de 0.5 GB (Free/Trial) a 5 GB (Hobby) y 50 GB (Pro), con resize en vivo.
• Quiere deploy desde GitHub con build automático y cero configuración de CI.

No, si tu agente:

• Es puro request/response sin estado: Workers o Vercel Functions salen más baratos a escala.
• Necesita GPU o binarios exóticos: los límites de imagen y RAM del plan importan (1–8 GB según plan).
• Es crítico con SLA: es una plataforma pequeña comparada con AWS; evalúa el riesgo de proveedor.

Cómo funciona el build: Railpack o Dockerfile

Al crear un servicio desde un repo, Railway detecta el lenguaje y construye un contenedor con Railpack; si hay Dockerfile en la raíz, lo usa directamente. En ambos casos el resultado es un contenedor que arranca con tu Start Command (detectado o configurado).

La decisión práctica:

• Proyecto estándar Node/Next/Python: deja que Railpack haga su trabajo. Cero Dockerfile que mantener.
• Proyecto con binarios nativos, usuarios no-root o builds multi-etapa: usa el Dockerfile que ya tienes — el mismo de la guía de self-hosting sirve casi tal cual.

Paso a paso: del repo a HTTPS

1. Nuevo proyecto → Deploy from GitHub repo. Railway construye con Railpack y arranca el servicio.
2. Variables: en la pestaña Variables agrega las credenciales del agente (OPENAI_API_KEY, tokens de Telegram, cadena de BD). Railway inyecta variables por entorno (Production, Preview, Development) y soporta variables compartidas referenciadas entre servicios — misma mecánica que la guía de secretos, con el gestor de Railway como fuente de verdad.
3. Volumen (si hay estado): Service → Volumes → crear y montar en la ruta que tu agente usa para sqlite o memoria. Sin volumen, cada redeploy borra el estado.
4. Dominio: Settings → Networking → Custom Domain. Railway emite el certificado SSL automáticamente. En tu DNS proveedor crea dos registros: el CNAME que indica Railway y un registro TXT de verificación — si falta el TXT, el dominio responde 404 aunque el CNAME resuelva. Este detalle rompe más deploys de Railway que cualquier otro.
5. Verifica: curl -s https://tu-dominio/health → 200. Los logs del deployment muestran el arranque del proceso.

Costos reales (2026)

Plan	Precio/mes	Incluye	Nota para agentes
Free	$0	$1 de crédito de uso/mes, 0.5 GB volumen	Solo para demos; se duerme por inactividad
Hobby	$5	Uso por consumo + 5 GB volumen	El plan de entrada para un agente real
Pro	$20	Más recursos por servicio + 50 GB volumen	Agentes con tráfico serio o multi-tenant
Enterprise	Custom	—	No aplica a builders individuales

Encima del plan se paga el uso por consumo: RAM, vCPU y egreso por hora de ejecución. Un agente Node con poco tráfico vive cómodo dentro de los $5 del Hobby; un agente con polling intensivo puede pasarse — el panel muestra el gasto por servicio en tiempo real, y vale ponerle alerta de presupuesto el primer día.

La comparación rápida con las otras rutas: un VPS de $5–6/mes te da más recursos fijos pero toda la operación manual; Workers/Vercel te dan escala a costo cero en tráfico bajo pero limitan procesos de larga duración. Railway compra el punto medio pagando ~$5 + consumo. Para la decisión completa, la comparativa de plataformas tiene los límites lado a lado.

Errores comunes

Síntoma	Causa típica	Fix
Dominio 404 con CNAME correcto	Falta el registro TXT de verificación	Agrega ambos registros exactos del dashboard
Estado del agente se borra	Sin volumen montado	Crea volumen y monta la ruta de datos antes de poblar datos
Build falla con binarios nativos	Railpack no cubre tu caso	Agrega Dockerfile; Railway lo detecta y lo usa
El servicio se reinicia en loop	Start command mal detectado o crash en arranque por variable faltante	Revisa logs del deployment; define las variables antes de redeploy
Factura sorpresa	Polling/cron consumiendo horas de RAM	Alerta de presupuesto + revisar uso por servicio

Checklist de producción

• Variables por entorno separadas (Production ≠ Preview)
• Volumen montado si hay estado persistente
• CNAME y TXT en DNS
• Alerta de presupuesto activa
• Healthcheck endpoint respondiendo 200
• Plan de rollback: Railway conserva deployments previos y redeployar es un clic

---

Siguiente paso: si tu agente ejecuta herramientas con acceso al sistema, combina Railway con sandboxing y permisos; y para las credenciales, la guía de secretos en producción aplica igual — el gestor de variables de Railway es tu gestor de secretos. Si todavía no tienes runtime local, el curso gratuito deja un agente corriendo para portarlo a Railway.