Give developers the least real secrets possible. Prefer fake or sandbox credentials, then short lived credentials fetched on demand with their own identity, and only then a local env file that is never committed. Shared production keys in a chat message or a zip file are the option to avoid.
The problem
Local development needs credentials for databases, queues and third party APIs. Every copy on a laptop is a copy that can be stolen, committed or pasted into a chat. The twelve factor guidance recommends keeping config in the environment, separate from code, and its litmus test is whether you could open source the codebase at any time without exposing credentials. That sets the bar for what must stay out of the repository.
Options compared
| Option | How it works | Leak risk | Effort |
|---|---|---|---|
| Fake services and test data | Local containers, mocks, sandbox accounts | Lowest | Medium, one time |
| Fetch on demand | Developer signs in, a script pulls short lived credentials | Low | Medium |
| Local env file, not committed | Developer copies a template and fills values | Medium | Low |
| Shared file or chat message | Someone sends the real keys | High | Low, until the leak |
Steps for a safer default
- Commit a template, not values. A file with variable names and fake values shows what is needed. See what to commit in an env example file.
- Ignore the real file. Add it to the ignore list, and remember that ignoring does not fix a file already committed. See gitignore does not hide committed secrets.
- Use separate credentials per developer where you can. Attribution and revocation both get simpler.
- Use sandbox or test tiers from third parties so a leaked key cannot touch real data.
- Block secrets at commit and push. A hook gives quick feedback, and a server check is the real gate. See can developers skip a pre-commit hook.
- Keep coding assistants away from env files. See read deny rules for Claude Code.
What to do on offboarding
Anything on a laptop should be assumed to leave with it. For shared credentials that a departing developer held, rotate them. For per person credentials, revoke. Our offboarding checklist covers the details.
Never production data locally
If a developer needs a production credential on a laptop to do their job, treat that as a gap in tooling. Provide a staging copy, a read only role with time limits, or a controlled access path with logging.
Quick check
Is a local env file acceptable?
For low risk, test tier credentials, yes. Keep it out of version control, and keep real production secrets out of it.
What if a developer commits the env file by mistake?
Treat the contents as exposed: revoke and rotate, then consider cleaning history. Add a blocking check so it cannot recur.
Safeguard's free scan can check a repository for credentials committed by accident, and its policy gates can block risky pull requests.
Sources
Last reviewed: 19 October 2026.
