Config System

Every larger program has values that can change: the address of a database, a password, a timeout, the number of parallel worker processes. One could write these values directly into the program’s source code. But then the program would have to be rebuilt every time a single value changes. A config system solves this differently: the values live outside the program, usually in their own files. On startup, the program reads these files and configures itself accordingly. The term comes from “configuration,” meaning setting or setup.

Why settings don’t belong in the code

Software almost never runs in just one place. Developers test it on their own machine. Afterwards it runs on a test server, and only at the end does it reach real users. These three environments need different values. On the laptop, the program should use a small test database, while in production it should use the large one. The program code itself, however, is identical everywhere. It is precisely this separation that a config system makes possible.

A second reason is security. Passwords and access keys must not be placed in the program code, since that code is often shared publicly. There have already been numerous cases where companies accidentally published keys for cloud services. Strangers were then able to run up costs at the company’s expense. If such values are fed in via configuration, they remain outside the shared code.

In the AI world, there is a third reason: traceability. When training a model, one sets dozens of numbers, such as the learning rate or the batch size. If these values are stored in a configuration file, one can still know exactly, months later, how a result came about. Without this file, an experiment is practically impossible to reproduce.

From the file to the running program

The settings are usually stored in simple text files with a fixed structure. Common formats are called YAML, JSON, or TOML. They consist of pairs of name and value, such as “port: 8080”. Some also allow nested groups, so that all database settings stay together. For humans these files remain readable, while for the program they can be unambiguously evaluated.

Typically there are several layers that overlay one another. At the bottom lie default values set by the developer. Above that sits a file for the respective environment. At the very top are so-called environment variables, i.e., values that the operating system passes in at startup. Each higher layer overrides the one below it. This works like a school’s rulebook: there are general rules, then rules for the individual class, and in case of doubt, the teacher on site decides.

A good config system also checks the values at startup. It immediately reports if a required entry is missing or a number is nonsensical. The technical term for this is validation. Without this check, the program only crashes hours later, at a completely different point. A common mistake, by the way, is confusing a config system with a feature-flag service. The latter switches functions on and off while the system is running, whereas configuration is usually only read at startup.

Configs in apps, servers, and AI projects

Anyone who has ever set up a game server knows the principle. Files like “server.properties” in Minecraft are nothing other than configuration. Even the settings menu of a phone app stores its values in such a file. The only difference is that there’s an interface in front of it instead of a text editor.

In professional software development, config systems are standard. Major providers like AWS or Azure offer their own services that centrally manage settings and secrets. They usually turn up in the news when something goes wrong. Several major outages at cloud providers were traced back to a faulty configuration, not a programming error. A single wrong line in a file can bring down services worldwide.

In AI projects, you encounter this term especially often. Frameworks for training models work almost exclusively with configuration files. Anyone who downloads an open language model usually finds a file there called “config.json”. It states how many layers the model has and how large its building blocks are. Without this file, the raw numerical values of the model would be unusable.