.gitignore solves one narrow problem.
Adding .env to .gitignore tells Git not to add an untracked file by default. That is useful, but it does not encrypt the file or move it outside the workspace.
The value remains readable to local processes with file access. It can appear in backups, editor indexes, support bundles, command output or agent context. It can also be copied into a differently named file which is not ignored.
A developer can still force-add the ignored file. A secret committed before the ignore rule was added remains tracked until it is explicitly removed, and it may remain in history afterwards.
The file becomes a distribution system.
In a team, somebody must deliver the initial file to every developer. When a key changes, every copy must change. When somebody leaves, it can be difficult to know which credentials still exist on which machines.
- Chat messages and password-manager notes become setup instructions.
- Different developers silently run with different values.
- Old clones and forgotten worktrees keep old copies.
- Applications, scripts and local tools share the same readable file.
This can be acceptable for non-sensitive local defaults. It is a poor lifecycle for reusable credentials.
The runtime interface is not the storage strategy.
The problem is not the environment-variable interface. Many applications correctly read values such as DATABASE_URL and STRIPE_API_KEY from their runtime environment.
The avoidable part is treating a plaintext project file as the place where reusable credentials live. A runtime can receive environment variables from a password manager, a cloud secret store, a process manager, a local encrypted vault or another trusted launcher.
Kimen is one local option. It keeps names and vault references with the project, stores values in an encrypted vault and supplies them to a trusted child process. The concrete migration is covered in the Git migration guide.
Encrypted local storage does not solve team distribution.
Kimen Core protects the local copy and moves it outside the project. It does not currently provision a shared credential to every developer, rotate it across machines or revoke it centrally.
If a team already uses 1Password, Vault or a cloud secret manager for distribution and access control, keep using it. The remaining Kimen value is the project contract and the controlled projection into the application runtime.
When a .env file is still reasonable
A project-local env file can be perfectly reasonable when every value is public, disposable or a local default. Examples include a development port, a feature flag or the hostname of a local container.
The distinction is whether disclosure creates work or risk. If exposure means revoking a token, changing a password or investigating access, the value deserves protected storage.
What about .env.example?
An example file is useful because it documents the names the application expects. Keep it free of realistic secret values. Kimen's project map serves a related purpose while also connecting those names to local vault references.
The project contract can therefore remain precise without turning the repository into the place where private values live.
For a concrete migration, read how to move local development secrets out of Git and the project workspace.