Not to mention the horrible configuration anti-pattern where everything depends on environment variables.
Environment variable tweaks are for local-only specific fixes, not for reproducible/distributable configuration.
Environment variable tweaks are for local-only specific fixes, 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)?
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.
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.
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.