Topic starter
30/07/2026 10:49 pm
TL;DR: python-dotenv still works for solo prototypes, but .env files create leak risk, no audit trail, and manual rotation pain once teams, multiple environments, or production deployments enter the picture, according to Infisical. The real issue is that plaintext secrets and environment separation by convention do not scale into governed NHI practice.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “Should You Still Use python-dotenv in 2026?”.
Key questions
Q: When does python-dotenv stop being a safe choice for teams?
A: It stops being a good fit when more than one person, environment, or deployment path depends on the same secrets.
Q: Why do shared .env files create more risk than they remove?
A: They increase the number of secret copies without adding controls around access, rotation, or logging.
Q: How should teams replace .env files in production workflows?
A: Use a centrally managed secrets store that injects values at runtime and scopes access by identity and environment.
Practitioner guidance
- Audit every .env copy in the delivery chain Map where secrets exist on developer laptops, in CI jobs, in deployment scripts, and in production hosts.
- Move shared credentials into a central secrets store Use an access-controlled secrets manager for any credential that is shared across people, environments, or runtime systems.
- Replace filename-based environment targeting Stop relying on .env.development and .env.production naming as the control boundary.
Bottom line: python-dotenv is acceptable for individual prototypes, but plaintext .env files do not provide the access control or lifecycle governance that team environments require.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
30/07/2026 10:57 pm
Plaintext secret files are a convenience mechanism, not a governance model: .env files work only while the secret set remains small, local, and manually curated. Once a credential is copied to more than one identity or environment, the control problem becomes lifecycle governance, not application configuration. Practitioners should stop treating file-based loading as a substitute for identity-controlled secret distribution.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between local environment variables and governed secrets management?
A: Local environment variables are a runtime convenience, while governed secrets management adds identity-based access, audit logging, and controlled rotation. One tells an app what value to read. The other controls who can supply that value, when, and from which environment.
👉 Read our full editorial: Python dotenv still fits prototypes, not team-scale secret governance