Local Convenience Has Limits
A .env file is easy to create, diff, copy, and send. That is why it works well for local setup.
It is also why shared secrets drift. One developer has last month's staging token, another copied the production webhook
key into a deployment note, and CI has a third value that nobody remembers rotating.
The operational questions arrive later: who had the leaked value, where else was it pasted, which services still use it, and whether contractor laptops or old branches still contain a working copy.
Workspace-Scoped Secrets
Workspace boundaries make shared secret ownership easier to reason about. Instead of treating every copied file as its own access boundary, teams can manage staging access, contractor access, and production-only credentials inside a smaller operational model.
Runbooks Without Copied Values
Deployment runbooks need context: which credential unlocks the migration, where the API key is used, and what to rotate after a leak. Vault pages can include a structured secret reference while the value remains behind the secret's reveal and copy controls.
Rotation After a Leak
With copied env files, rotation often means sending a new value and hoping every old copy disappears. Vault treats rotation as replacement rather than overwriting the existing secret. That makes it easier to understand which credential replaced the old value, which references became outdated, and who interacted with the compromised secret during the relevant timeline.
Which Environment Each Tool Fits Best
Environment files fit local development, process startup configuration, and simple projects where the file is not a shared source of authority. Vault fits teams that need shared secret ownership, workspace access review, runbook references, manual rotations, incident follow-up, and audit investigations across multiple people and systems.