railyard.yml: la configuración de tu app como un solo archivo en git

La configuración como código suele venderse como una promesa más grande que lo que mecánicamente hace el primer día. Vale la pena ser precisos aquí, porque exagerar esta función específica sería justo el tipo de cosa que este blog intenta no hacer: railyard.yml hoy son tres comandos directos, no un pipeline completo de plan/apply/drift —y saber exactamente dónde está esa línea es más útil que una descripción más vaga y grandilocuente.

Los tres comandos

railyard manifest:pull my-app --out railyard.yml
railyard manifest:apply my-app railyard.yml
railyard manifest:validate railyard.yml

• manifest:pull imprime la configuración actual de una app como un archivo railyard.yml — agrega --secrets y también incluye los valores de las variables, no solo los nombres. Así se consigue un punto de partida: descargar lo que ya está corriendo, en vez de escribir el archivo desde una página en blanco.
• manifest:apply aplica un archivo directamente a una app.
• manifest:validate revisa un archivo local —./railyard.yml si no nombras uno— contra el esquema sin involucrar ninguna app y sin aplicar nada. Las claves desconocidas reciben una sugerencia real (contaner_port → “¿quisiste decir container_port?”), no solo un error genérico de parseo. Termina con código 0 e imprime “is valid” si no hay nada mal, o código 1 y la lista de cada problema que encontró.

Para qué sirve realmente esa combinación

Correr validate en CI antes de un despliegue atrapa una clave con un error de tipeo o un valor malformado antes de que llegue a una app real —un seguro barato que cuesta un solo comando en un pipeline. pull y después apply es cómo se mueve la configuración entre entornos sin volver a hacer clic por todo el panel cada vez: descargar la configuración de staging, ajustar lo que de verdad es distinto, aplicarla en producción.

La API REST respalda exactamente lo mismo de forma directa —GET /api/applications/:id/manifest devuelve el mismo archivo (?secrets=true para los valores), para cualquier cosa que quiera automatizar esto más allá del CLI.

Lo que todavía no es

No hay un paso de plan que muestre un diff antes de aplicar —apply simplemente aplica. No hay detección de drift que te avise si producción se desvió en silencio del archivo en git. Si eso importa para cómo trabaja tu equipo hoy, trata railyard.yml como una foto de la configuración y un mecanismo de transporte, no como una garantía de que git y la realidad se mantienen sincronizados sin que tú lo revises.

Decir esto con todas sus letras es justamente el punto: una función de configuración como código solo es realmente útil una vez que sabes con precisión qué te resuelve y qué te sigue tocando a ti notar.

Referencia completa de comandos: CLI.