[funklute]

> not for reproducible/distributable configuration

At my work, we use environment variables all the time for configurations, e.g. for telling a kubernetes pod where to find the database. In your opinion, what is the better option(s)?

[Galanwe]

The problem with environment variables as configuration is that it's unstructured, hardly documented, and overall hard to reproduce and inspect.

Nothing is worse than trying to understand an issue with a program that heavily relies on environment variables for configuration, as environment variables are designed to be short-lived, memory only.

A good old configuration file is the best. You can version it, distribute it, it's explicit, possibly structured, easily documented.

That doesn't mean that there is no room for environment variables, but these should be for local-only hacks and tweaks.

[funklute]

> Nothing is worse than trying to understand an issue with a program that heavily relies on environment variables for configuration

I totally agree with this.

> A good old configuration file is the best.

But the issue with this is that you often don't know what your configuration is ahead of time. Sometimes it is only generated just before execution of your code.

[BerislavLopac]

Secret managers. All cloud providers have them built in, and on other platforms you can easily whip up a self-hosted one. See https://blog.diogomonica.com//2017/03/27/why-you-shouldnt-us...

[xvector]

I recommend against with using secrets managers as opposed to config files for storing configuration. Ideally, your configuration is versioned and code-reviewed. Config files are optimal. Even secrets used by your deployment should be stored in configuration - encrypted, of course. The benefit of versioned configuration files, secrets included, cannot be overstated.

You can encrypt sensitive configuration fields with tools like `mozilla/sops` [1], which will reach out to your KMS or secrets manager of choice to encrypt/decrypt sensitive fields on the fly.

This way, you are minimizing the splitting of state across secrets managers and your code. Your configuration is stored at code, code reviewed, and versioned, which has devops and security benefits of its own.

[1]: https://github.com/mozilla/sops

[xvector]

Config files, and command line arguments as a very distant second