railyard.yml: a configuração da sua aplicação como um arquivo só no git

Config-as-code geralmente é vendido como uma promessa maior do que o que mecanicamente faz no primeiro dia. Vale ser preciso aqui, porque supervalorizar essa funcionalidade específica seria exatamente o tipo de coisa que este blog tenta não fazer: o railyard.yml hoje é três comandos diretos, não um pipeline completo de plan/apply/drift — e saber exatamente onde essa linha está é mais útil do que uma descrição mais vaga e grandiosa.

Os três comandos

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

• manifest:pull imprime a configuração atual de uma aplicação como um arquivo railyard.yml — adicione --secrets e ele inclui os valores das variáveis, não só os nomes. É assim que você consegue um ponto de partida: baixar o que já está rodando, em vez de escrever o arquivo do zero.
• manifest:apply aplica um arquivo direto numa aplicação.
• manifest:validate checa um arquivo local — ./railyard.yml se você não nomear um — contra o schema sem nenhuma aplicação envolvida e nada aplicado. Uma chave desconhecida recebe uma sugestão real (contaner_port → “você quis dizer container_port?”), não só um erro de parse genérico. Ele sai com código 0 e imprime “is valid” quando não há nada errado, ou sai com código 1 e lista cada problema encontrado.

Pra que essa combinação realmente serve

Rodar validate no CI antes de um deploy pega uma chave digitada errado ou um valor malformado antes dele chegar numa aplicação de verdade — um seguro barato que custa um comando no pipeline. pull e depois apply é como a configuração se move entre ambientes sem clicar de novo em cada um pelo painel: baixar a configuração do staging, ajustar o que realmente é diferente, aplicar em produção.

A API REST dá suporte à mesma coisa direto — GET /api/applications/:id/manifest retorna o mesmo arquivo (?secrets=true pros valores), pra qualquer coisa que queira automatizar isso além do CLI.

O que ainda não é

Não existe uma etapa de plan que mostra um diff antes de aplicar — o apply simplesmente aplica. Não existe detecção de drift que te avisa que a produção discretamente se afastou do arquivo no git. Se isso importa pro jeito que a sua equipe trabalha hoje, trate o railyard.yml como um snapshot de configuração e um mecanismo de transporte, não uma garantia de que o git e a realidade continuam sincronizados sem você checar.

Dizer isso claramente aqui é o ponto: uma funcionalidade de config-as-code só é realmente útil quando você sabe precisamente o que ela checa por você e o que ainda sobra pra você notar.

Referência completa de comandos: CLI.