An <code>.env</code> file is configuration. It is not automatically secret management.
Production secrets should be stored outside the repository, restricted by environment and rotated when exposure is suspected.
Your NestJS application should:
<ul>
<li>Validate configuration during startup</li>
<li>Fail fast when required values are missing</li>
<li>Remove secrets from logs</li>
<li>Use managed secret storage where possible</li>
<li>Keep credentials out of source and Docker images</li>
</ul>
The most dangerous secret is often the one printed in an error log.
How do you manage production secrets?
#NestJS #Security #DevOps

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

A concise reminder that .env files are configuration, not secret management. Production secrets should be stored outside the repository, restricted by environment, and rotated when exposure is suspected. NestJS applications should validate configuration at startup, fail fast on missing values, scrub secrets from logs, use managed secret storage, and keep credentials out of source code and Docker images.

Day 14/30 — Secrets Stay Out of Code

Most of the times the security concerns are neglected by developers. I saw so many secrets in many systems in the logs.

The funny part is that we put every secret in the <code>.env</code> file and then commit it to the repository as well.
The dangerous part is that even if you delete the file in a later commit, the secrets still remain in the Git history.