YAML

Almost every program needs information about how it should work: which server is used, which password applies, how many retries are allowed. Such information is rarely written into the actual program code. Instead, it is placed in a separate text file, and YAML is one of the most widespread formats for exactly these files. The structure is deliberately simple: on the left is a name, then a colon, then the value, for example “port: 8080”. If something belongs to something else, it is indented further to the right. This means you can read a YAML file without ever having learned the language.

Why configuration must be readable

Configuration files are not written just once. They are adjusted for months by changing people, often under time pressure. If nobody understands what is in the file, errors arise that only become apparent once the system is running. YAML therefore relies on as few characters as possible that carry no meaning.

The most important comparison is JSON, an older format with the same purpose. JSON requires curly brackets, quotation marks, and commas in exactly the right places. This is convenient for machines but tedious for humans. YAML omits almost all of that and therefore looks more like a neatly formatted note. Both formats can represent the same information, and YAML can even read JSON.

Another reason is collaboration via version control. Development teams store their files in systems that log every change line by line. A format with one piece of information per line shows very precisely in such a log what someone has changed. With YAML, you can see at a glance: here the memory limit was raised from 2 to 4 gigabytes.

Indentation instead of brackets

At its core, YAML knows only three building blocks. There are individual values such as numbers, text, or true and false. There are mappings, in which each name is assigned a value. And there are lists, in which each entry begins with a hyphen. From these three parts, arbitrarily nested structures can be built.

Nesting arises solely from spaces at the start of a line. If under “database:” there is a line “host: localhost” indented by two spaces, then this host belongs to the database. This works like an outline in a school essay, where sub-points are placed further to the right than main points. A program reads in the file and reconstructs exactly this structure in memory.

But this is also exactly where the most well-known weakness lies. A single wrong space shifts a piece of information to a completely different place, and tabs are forbidden for indentation. Also notorious is the so-called Norway problem: older YAML versions interpreted the unquoted word “NO”, the country code for Norway, as the truth value “no”. Anyone who wants to be safe puts such values in quotation marks.

YAML in cloud, AI projects, and automation

YAML is most visible around Kubernetes, the standard software for running programs in data centers. There, YAML files describe how many copies of an application should run and how much computing power it gets. The automated test workflows on platforms like GitHub are also defined in YAML. Anyone who works professionally with servers writes such files practically every day.

In AI projects, YAML usually serves as the record of an experiment. Learning rate, number of runs, dataset used, and model size are all listed together in a short file. Anyone who wants to reproduce a result later needs exactly this file. Without it, after three months nobody remembers anymore with which settings a model was trained.

In the news, YAML mostly comes up in connection with security incidents. Access credentials that accidentally end up in a public YAML file are a common cause of data leaks. Likewise, incorrectly indented lines can bring entire services to a halt. The format itself is harmless, but its role as a central switch for large systems is not.