Comment by senko
Sure, that works as well, for example on some deploys I set the settings in systemd service file. However, it's more convenient to just have .env right there.
> On production keep things like API keys that need to be kept secret elsewhere - as a minimum outside the project directories and owned by a different user.
Curious what extra protection this gives you, considering the environment variables are, well, in the environment, and can be read by process. If someone does a remote code execution attack on the server, they can just read the environment.
The only thing I can imagine it does protect is if you mistakenly expose project root folder on the web server.
> Curious what extra protection this gives you, considering the environment variables are, well, in the environment, and can be read by process. If someone does a remote code execution attack on the server, they can just read the environment.
While your secrets are available at runtime, you get a lot of governance by placing them in something like a keyault. You get an audit trail, you can setup rotation policies. It's easier to reference different secrets for dev, test, prod etc. I'd argue that there is a lot of added security in the fact that your developers won't actually need any sort of access to a secret stored in a keyvault, especially because you don't need to give developers access to runtime logs or even the production envrionment at all. You're right that it's not a perfect way to protect a secret of course.