Home Posts Links Notes Now

Configuration languages



Using a programming language to generate configuration might seem overkill but it offers many advantages.

On the scale of a single configuration file it can help reducing boilerplate and repetition as well as ensuring that all the sections of the file are well formed and consistent with each other.

Deployments with multiple environments and spanning across multiple locations often have very similar configuration that can easily be generated from a shared template.

It’s nice to define an high level model of a deployment and have all the corresponding pieces of configuration (k8s manifests, DNS configuration, monitoring dashboards, alerts, ...) generated for it.

For all these use-cases, using a real programming language can be really beneficial to allow us to express everything we need to. At the same time, using a general purpose programming language might be too much. We don’t want any side effects when we generate configuration.


Pkl is the language I’m most familiar with and I’m very happy with it. It offers many useful features with a familiar and easy to use syntax. Lots of effort has been put into IDE integration. The language is lazy, pure and can validate the generated configuration matches a very rich set of constraints. The output can be a common configuration format (json, yaml, xml) or even a custom user-defined format.

Nix is used to configure NixOS and has a reputation of being obscure. The language is lazy, pure, functional and dynamically typed.

Dhall not Turing complete.

Nickel aims to be an easier to use replacement of Nix. Strongly influenced by functional programming.


CUE Not Turing complete. Has a different language design than the other entries.


KDL. Seen in the wild as the languages zellij uses for its configuration. It’s a document language that the other entries could target more than a language used to generate configuration.



Thanks for reading. Feel free to reach out for any comment or question.