Configuration as Code: Version Control for Your Settings

Why it exists

Manually configuring systems is slow, error-prone, and leads to "configuration drift," where each environment (dev, staging, production) becomes a unique, undocumented snowflake. This makes reproducing systems or tracking down environment-specific bugs nearly impossible. Configuration as Code was created to solve this by making configuration automated, repeatable, and auditable.

The mental model

Treat your system's configuration not as a series of clicks in a UI or commands typed into a shell, but as a set of machine-readable definition files. These files become the single source of truth for how your software and infrastructure should be configured. Just like application code, this configuration code lives in a version control system like Git, giving you a full history of every change.

How it works

Instead of logging into a server to change a setting, you modify a definition file (e.g., a YAML or JSON file). You then commit this change to your repository. An automated process, often part of a CI/CD pipeline, detects the change and applies it to the target systems. This process can be imperative (running a script that executes steps to reach the new state) or, more commonly, declarative (defining the desired end state and letting a tool figure out how to get there).

When to use it

CaC is essential for managing settings across multiple servers or environments. It's perfect for handling application settings, feature flags, database connection strings, or middleware configurations. Any time you need to ensure consistency and repeatability between your development, testing, and production environments, CaC is the right approach. It is a core practice in modern DevOps and SRE.

When not to use it

For a single, simple application with a static configuration that rarely changes, the overhead of setting up a CaC workflow might not be justified. More importantly, CaC is not a secrets management solution. Storing sensitive data like passwords or API keys directly in configuration files is a major security risk, even in private repositories. These should be managed with a dedicated secrets vault.

One canonical example

A web application needs a different database connection string for development and production. Instead of manually setting an environment variable on the production server, you define it in configuration files. A dev.yaml might have database_url: "user:pass@localhost/dev_db" while a prod.yaml has database_url: "${PROD_DB_URL}". The production value is a reference to a secret managed by a vault. When deploying to production, the CI/CD system pulls the secret from the vault and injects it, applying the configuration defined in prod.yaml.