Topic starter
30/07/2026 10:49 pm
TL;DR: The real failure is secret sprawl, with Infisical detailing how copied .env values lose access control, rotation, and audit trails once more than one person or deployment depends on them. Teams need governed secret storage, or plaintext files will keep hiding where credentials live.
Editorial analysis by NHI Mgmt Group, based on content published by Infisical: “Should You Still Use python-dotenv in 2026?”.
Key questions
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.
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.
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.
Glossary terms: Environment Variable, Env File, Secrets Sprawl, Secrets Management
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 11 hours ago by NHI Mgmt Group
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