CUE vs YAML: Typed Config vs Plain YAML
YAML is a plain data format that is universal but has no types or validation; CUE is a language that produces and validates data with constraints. YAML is simpler; CUE catches errors YAML cannot.
This is not a like-for-like fight: YAML is a serialization format, CUE is a configuration language that can emit YAML. Teams reach for CUE when raw YAML grows error-prone at scale. Here is the honest comparison of when each is the right tool.
| CUE | YAML | |
|---|---|---|
| What it is | Config language + validator | Data serialization format |
| Types/constraints | First-class, enforced | None (strings, numbers, lists, maps) |
| Reuse/DRY | Imports, definitions, unification | Anchors/aliases (limited) |
| Validation | Built-in | External (schemas, linters) |
| Ubiquity | Growing | Everywhere |
| Best fit | Large, error-prone config | Small, simple config |
When plain YAML is enough
For a handful of files, YAML is the right call: everyone reads it, every tool consumes it, and there is nothing to learn. Its gaps (no types, easy to misindent, anchors are clumsy) only bite at scale. Do not add a config language to a small project just because you can.
When CUE pays off
Once you have many near-identical YAML files, environment-specific overrides, and recurring copy-paste mistakes, CUE earns its keep: it enforces schemas, deduplicates via definitions, and fails fast on invalid values. You still emit YAML for tools that need it, but you author and validate in CUE.
In CI
Even if you keep YAML, add a validation step (schema check or linter). If you adopt CUE, run cue vet/cue export in CI so bad config is rejected before deploy. The goal is the same: no invalid configuration reaches production.
The verdict
Keep plain YAML for small, simple config where its ubiquity wins; adopt CUE when config volume and correctness demands outgrow hand-edited YAML. CUE can still output YAML, so it augments rather than fully replaces it.