.env and Secrets Management for Small Teams

Every codebase eventually accumulates a .env file full of API keys, database URLs, and tokens. For a small team, that’s usually fine, right up until the file gets committed by accident, shared over Slack, or left identical across staging and production with no way to know which secrets are actually still in use. None of this requires an enterprise secrets platform to fix. It requires a few habits, applied consistently.

What Actually Belongs in .env

Local development values that are low-risk if exposed: feature flags, non-sensitive config, and secrets for services scoped to a sandbox/test environment. Anything that touches real customer data, real payments, or production infrastructure should not be sitting in a plaintext file that gets copied between laptops.

The Baseline Every Team Should Have

1. .env is in .gitignore from the first commit. Not after the first leak. Check this on day one of any new repo.
2. .env.example is committed instead, listing every variable name with a placeholder value, so a new team member knows exactly what to set up without ever seeing a real secret.
3. Production secrets live in your hosting platform’s environment variable settings, not in a file anywhere, checked in or not. Every major host (Vercel, Render, Fly, AWS, etc.) has this built in.
4. Different secrets per environment. Staging and production should never share the same database credentials, payment provider keys, or third-party API tokens. If staging leaks, production stays safe, and vice versa.

When to Move to a Dedicated Secrets Manager

A small team doesn’t need Vault or a full enterprise secrets platform on day one, but a few signals mean it’s time:

• More than a handful of people need access to production secrets
• Secrets need to rotate on a schedule, not manually when someone remembers
• You need an audit trail of who accessed what, and when
• Secrets are shared across more than one service or repository

Lightweight options (1Password’s CLI/vaults, Doppler, or your cloud provider’s native secrets manager) cover most small teams without the operational overhead of running your own Vault cluster.

Rotation Habits Worth Building Early

• Rotate any secret immediately if someone leaves the team, not on the next scheduled rotation
• Rotate immediately if a secret was ever pasted somewhere it shouldn’t have been (a Slack message, a public gist, a support ticket)
• Set a calendar reminder for routine rotation of long-lived API keys even without a specific incident, every 6-12 months is a reasonable default

Common Mistakes

• Treating .env in .gitignore as sufficient. It stops new commits, it does nothing about a secret that was already committed in an earlier commit still sitting in git history. If that’s happened, the key needs to be rotated, not just removed from the current file.
• One shared .env file passed around for “convenience.” This is how a departing team member ends up with permanent access to production credentials nobody remembers to revoke.
• No record of which secret is used where. When a key needs to rotate, someone has to know every service that references it, or rotation breaks something in production with no clear cause.

Getting this right doesn’t require a security team. It requires deciding, in writing, what belongs where, and enforcing it consistently from the first commit.