Duodécimo módulo del Curso de Deploy de Agentes. En el Módulo 11 montaste el camino de máximo control: Terraform, WIF, Cloud Run, todo declarado y auditado — el mundo de una empresa grande. Es potente y es mucho trabajo. Hoy va el otro extremo: el camino simple, el que Felipe usa en sus propias apps. Desplegar en Railway directo desde el repo, sin escribir una sola línea de Terraform, y tener el agente en línea en minutos. Y algo más importante que Railway: el criterio para elegir plataforma, porque no hay una respuesta correcta — hay un trade-off entre esfuerzo de operación y control.

La tesis del módulo

Elegir plataforma no es elegir “la mejor”: es elegir dónde parar en el espectro entre simplicidad y control. Un PaaS te da velocidad a cambio de ceder decisiones; IaC en la nube te da control a cambio de operar más. La respuesta correcta depende del equipo, la escala y el compliance — no de la moda.

Railway: el camino de menos fricción

Railway es un PaaS (Platform as a Service, plataforma como servicio): un proveedor que se encarga de casi toda la infraestructura por ti. Tú traes el código; él construye, corre, expone y escala. No hay servidores que administrar, ni Dockerfile obligatorio, ni Terraform. El flujo típico es de tres pasos:

Conectas el repo. Railway detecta que es una app (Python, Node, lo que sea), infiere cómo construirla y la despliega. Cada push a tu rama vuelve a desplegar solo.
Pones las variables de entorno. En su panel agregas OPENAI_API_KEY y compañía. Railway las inyecta al contenedor — el mismo principio de Secret Manager del módulo anterior, pero sin que tú montes nada.
Agregas lo que falte. ¿Necesitas una base de datos? Un click y Railway te levanta un PostgreSQL gestionado (él se encarga de backups y disponibilidad) y te inyecta la URL de conexión como variable. ¿Un dominio? Te da uno *.up.railway.app o enchufas el tuyo con HTTPS automático.

Eso es el deploy completo. Compáralo con el Módulo 11: aquí no hay provider, ni state, ni WIF, ni pipeline YAML. La contraparte es que cediste el control: no eliges la región exacta, ni afinas el escalado al detalle, ni auditas la infra en PR. Para la gran mayoría de los proyectos personales y muchos productos tempranos, ese trato es excelente. Si quieres el paso a paso concreto de preparar un repo para Railway, está en el tutorial de preparación del workshop.

Ojo: que Railway sea simple no lo hace de juguete. Corre productos reales en producción. Lo que cambia no es la seriedad, sino quién opera: en un PaaS, el proveedor opera por ti; en GCP con IaC, operas tú. Ese es el eje, no la calidad.

El espectro de plataformas

Toda decisión de deploy cabe en una línea que va de más simple (el proveedor decide casi todo) a más control (tú decides casi todo). A más control, más poder — y más operación que sostener.

  más simple ◄──────────────────────► más control
   menos ops                          más ops

 ┌───────┐    ┌───────────┐    ┌──────────┐    ┌──────┐
 │ PaaS  │──► │ Serverless│──► │Kubernetes│──► │  VM  │
 │Railway│    │ Cloud Run │    │   GKE    │    │      │
 └───────┘    └───────────┘    └──────────┘    └──────┘
  el proveedor                          tú lo
  decide casi todo                   decides todo

PaaS (Railway): das el repo, listo. El proveedor decide build, red, escalado. Menos ops posible.
Serverless (Cloud Run): das la imagen; el proveedor la corre y escala a cero, pero tú controlas región, secretos, IAM y todo se declara en IaC. El punto medio del Módulo 11.
Kubernetes (GKE): das contenedores y describes cómo orquestarlos — réplicas, redes, autoescalado fino. Muchísimo control, muchísima complejidad operativa.
VM (máquina virtual): das un servidor pelado; instalas y administras todo tú, desde el sistema operativo hacia arriba. Control total, ops total.

La tabla honesta

Plataforma	Modelo	Ops que cargas	Control	Costo	Cuándo gana
Railway	PaaS	Casi nada	Bajo	Simple, sube con el uso	MVP, apps personales, equipos chicos, velocidad
Cloud Run	Serverless	Poca (IaC)	Medio-alto	Barato, escala a cero	Producción con control, tráfico intermitente
GKE	Kubernetes	Mucha	Muy alto	Pagas el cluster corriendo	Escala grande, microservicios, necesidades finas
VM	Servidor	Toda	Total	Pagas prendida, tú optimizas	Requisitos especiales, software que exige el host

Léela como Felipe la usaría: para sus apps, Railway gana — es una persona, quiere velocidad, no necesita auditar cada recurso en un PR. En una empresa grande, Cloud Run o GKE ganan — hay equipos, compliance, escala y auditorías que exigen que la infra esté declarada, revisada y controlada. La misma persona elige distinto según el contexto. Eso no es incoherencia: es criterio.

Cómo decidir, en tres preguntas

¿Cuánta gente va a operar esto? Solo tú o dos personas → PaaS. Un equipo con turnos y auditorías → IaC en la nube.
¿Qué exige el negocio? ¿Hay compliance (normas que obligan a controlar y auditar dónde y cómo corren los datos)? Si sí, el control de GCP/IaC deja de ser opcional. Un proyecto personal no tiene esa carga.
¿Cómo es el tráfico y la escala? Intermitente y modesto → serverless o PaaS, que escalan a cero y no te cobran ocioso. Alto, constante, con microservicios → Kubernetes empieza a justificar su complejidad.

Y el costo, que merece su propia advertencia:

Ojo con el costo, que engaña. Un PaaS es baratísimo al principio y su factura crece con el uso de forma poco visible. Un cluster de GKE cuesta desde el minuto cero, aunque no tenga tráfico, porque el cluster corre. Cloud Run, al escalar a cero, es el más amable con la cartera cuando el tráfico es intermitente. La cuenta fina — costo por millón de tokens, punto de equilibrio, cuándo conviene qué — está en GPU Módulo 12: producción, costos y decisiones.

Errores comunes

Empezar en Kubernetes “porque es lo profesional”. GKE para un MVP de una persona es cargar un camión para llevar una caja. La complejidad operativa te frena en vez de ayudarte. Empieza simple; sube cuando el dolor lo justifique.
Quedarse en el PaaS cuando el negocio ya pide control. El espejo del anterior: cuando llegan compliance, auditorías y equipos, insistir en el PaaS por comodidad se vuelve deuda. Ahí toca el mundo IaC del Módulo 11.
Comparar plataformas solo por precio de lista. El costo real incluye las horas de operación: una VM barata que exige que tú parchees, monitorees y escales a mano puede salir más cara que un serverless “más caro” que no operas.
Creer que elegir plataforma es para siempre. No lo es. Muchos productos nacen en Railway y migran a Cloud Run cuando escalan. Empezar simple no te encadena; te deja avanzar hoy.
Ignorar el escalado a cero en tráfico intermitente. Si tu agente atiende picos y valles, una plataforma que no escala a cero te cobra el ocio. Es plata quemada mientras nadie usa el servicio.

La frase para llevarse

“No existe la mejor plataforma; existe la correcta para tu equipo, tu escala y tu compliance. Railway para ir rápido solo; GCP con IaC para operar en serio con otros.”

Qué viene

Módulo 13: observabilidad y seguridad en producción. Ya sabes desplegar por los dos caminos; ahora toca ver qué pasa dentro del agente una vez que corre para usuarios reales — logs, trazas, métricas y alertas — y cerrar la superficie de ataque: secretos, permisos mínimos y validación. Desplegar era la mitad; operar con adultos responsables es la otra.

Deploy de Agentes — Módulo 12: Railway y la comparación de plataformas