railyard.yml: your app's config as one file in git

Config-as-code usually gets sold as a bigger promise than what it mechanically does on day one. Worth being precise here, because overselling this specific feature would be exactly the kind of thing this blog tries not to do: railyard.yml today is three straightforward commands, not a full plan/apply/drift pipeline — and knowing exactly where that line sits is more useful than a vaguer, grander description.

The three commands

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

• manifest:pull prints an app’s current configuration as a railyard.yml file — add --secrets and it includes variable values, not just names. This is how you get a starting point: pull what’s already running, rather than writing the file from a blank page.
• manifest:apply applies a file to an app directly.
• manifest:validate checks a local file — ./railyard.yml if you don’t name one — against the schema with no app involved at all and nothing applied. Unknown keys get a real suggestion (contaner_port → “did you mean container_port?”), not just a generic parse error. It exits 0 and prints “is valid” with nothing wrong, or exits 1 and lists every problem it found.

What that combination is actually good for

Running validate in CI before a deploy catches a typo’d key or a malformed value before it ever reaches a real app — cheap insurance that costs one command in a pipeline. pull then apply is how configuration moves between environments without re-clicking through a dashboard for each one: pull staging’s config, adjust what’s actually different, apply it to production.

The REST API backs the same thing directly — GET /api/applications/:id/manifest returns the same file (?secrets=true for values), for anything that wants to script around it beyond the CLI.

What it isn’t, yet

There’s no plan step that shows a diff before applying — apply just applies. There’s no drift detection that tells you production has quietly diverged from the file in git. If those matter for how your team works today, treat railyard.yml as a config snapshot and transport mechanism, not a guarantee that git and reality stay in sync without you checking.

Saying that plainly here is the point: a config-as-code feature is only actually useful once you know precisely what it checks for you and what it still leaves to you to notice.

Full command reference: CLI.