I've recommended moving keys into environment variables all year as the standard fix for exposed secrets, and that advice still stands. Worth being precise about a further step up from there: a dedicated secret manager, and what it actually solves that a collection of .env files, however carefully handled, still doesn't.
What .env files handle well
For a single small app, with a small team, environment variables are a genuinely solid solution: keys stay out of code, out of the browser, and configured per environment. This is the right default for most small projects, and I've never suggested otherwise.
Where .env files start showing their limits
- Rotating a key across multiple environments and deployments, when it's spread across several separate .env files, means manually updating each one and hoping none get missed, with no central place to confirm every copy actually changed.
- There's typically no audit trail. If a key needs rotating because it was exposed, there's often no record of who could access which .env file, or when it was last viewed or changed.
- Access control is coarse. Anyone with access to a server or a deployment platform's environment settings generally sees all the secrets configured there, with no finer-grained way to say this team member should see the email key but not the payment key.
- As a team and its number of services grow, keeping every .env file's contents consistent and correctly scoped becomes a genuinely harder coordination problem, one that doesn't scale gracefully with more people and more moving pieces.
What a dedicated secret manager actually adds
Tools built specifically for this, whether a cloud provider's built-in secret manager or a dedicated third-party product, generally add centralized rotation, so updating a key happens in one place and propagates correctly, real access logging, so you know who accessed or changed what and when, finer-grained permissions, so team members and services only see the specific secrets they actually need, and often automatic rotation on a schedule rather than relying on someone remembering to do it manually.
When the upgrade is actually worth it
For a solo builder or a very small team on one or two projects, well-managed .env files, handled with the discipline I've written about all year, are a completely reasonable, proportionate choice. As a team grows, as the number of services and environments multiplies, or as the sensitivity of what a key protects increases, a dedicated secret manager starts solving real coordination and audit problems that .env files structurally can't, regardless of how carefully they're handled.
This isn't a case of one option being insecure and the other secure. It's a case of one solving a smaller-scale problem well and the other solving a larger-scale coordination problem that eventually shows up as a team and its infrastructure grow. Neither is wrong at the stage it's actually suited for.