> use python-dotenv to pull settings from environment / .env
I disagree strongly with this one. All you are doing is moving those settings to a different file. You might as well use a local settings file that reads the common settings.
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.
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.
> Curious what extra protection this gives you, considering the environment variables are, well, in the environment, and can be read by process.
Look at it this way. What does putting things in a .env file get you over putting them in a local settings file? Both are readable by any process running as a user that can read those files, both are within the project directory and might be accidentally committed.
It also makes it easier to have a setup where secrets cannot be read by other software - e.g. this: https://www.theregister.com/2026/01/28/claude_code_ai_secret...
That's something that python-dotenv enables. It can pull from environment, which you can wire up from k8s secrets or whatever is the case for your hosting.
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.