Dotenv

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

⚠ (not to be confused with direnv and its .envrc)

dotenv's .env files are intended to

separate out environment variables that your project should pick up

...sometimes just to make the thing more parametric

...and especially values that you probably want to keep out of your source management

People disagree a little about whether that is

• aimed to keep secrets out of source management or is barely about that at all, and/or
• whether you should specifically sync them between developers, or specifically not, and/or
• primarily for separating dev from production, or
• for any instance-specific environment variables

"Is it just like a config file?"

Absolutely.

"Is it fancy or special in any way?"

Not at all

it's just a file, that has no meaning unless a project explicitly chooses to read it

and you should generally assume things do not unless you know they do

a few things do, such as docker compose (but not docker build), and python's poetry

"Does it solve secret sprawl / help secrets stay secret?"

Assume "No."

if you put secrets there at all, you just centralized all the secrets in one easy-to-identify place; if at any time you do manage to share that in any way, hackerman thanks you for making their job much easier.

maybe it stays separated better, maybe it does not - that, as much as before, is up to everyone involved

"Is it a decent habit regardless?"

Sure.

it makes it much easier to not put secrets into code

it makes it much easier to not accidentally share it (you can argue it should have been called secrets-do-not-share but eh...)