You don’t need a HashiCorp Vault cluster to stop committing API keys to git. You need something better than a .env file passed around in Slack, and there are a few options between those two extremes that fit a small team.

Why .env files in Slack are the actual problem

Not because they’re insecure in some abstract sense — because they rot. Nobody remembers to rotate a key that lives as a pasted message from eight months ago. Nobody can tell who has access, because “who’s in this Slack channel” isn’t an access list. And the first time someone leaves the team, you’re grep-ing chat history to figure out what they might have seen.

The options, in order of effort

Which rung you land on depends mostly on team size and what you already run:

flowchart TD
    A{"Already pay for a password manager,\nteam under 10?"} -->|Yes| B["1Password / Bitwarden shared vault"]
    A -->|No| C{Want audit log + rotation\nwithout running infra?}
    C -->|Yes| D[Doppler or Infisical]
    C -->|No| E{Already deep in one cloud provider?}
    E -->|Yes| F[Cloud provider secrets manager]
    E -->|No| G{Dedicated person to run it,\ncompliance demands it?}
    G -->|Yes| H[Self-hosted Vault]
    G -->|No| D
  

1Password / Bitwarden with a shared vault. If you already pay for a password manager, this is close to free. Store secrets as items in a shared vault scoped to the people who need them, and pull them via CLI in CI:

op read "op://prod/database/DATABASE_URL"

Good enough for teams under ~10 people who don’t need programmatic rotation.

Doppler or Infisical. Purpose-built secrets managers with a generous free tier at small scale. Sync secrets to your deploy environment automatically, and you get an audit log — who accessed what, when — without configuring anything.

doppler run -- node server.js

This is the sweet spot for most small teams: real access control and rotation without operating any infrastructure yourself.

Cloud provider secrets manager (AWS Secrets Manager, GCP Secret Manager). Worth it once you’re already deep in one cloud and want secrets tied to IAM roles instead of a separate access model. Adds cost per secret and per API call, which matters less at your first hundred secrets and more if you’re storing high-churn, per-request values.

Self-hosted Vault. Skip this until you have a dedicated person to run it. Vault is correct, powerful, and more operational surface than a two-to-five person team should be maintaining — unseal keys, storage backend, policy configuration. This is the rung you reach for once you have compliance requirements a managed tool can’t satisfy, not before.

What actually matters, regardless of tool

Never commit a secret, even to a private repo. Private doesn’t mean permanent — repos get made public by accident, forked, or given a new collaborator who didn’t need history access. Use a pre-commit hook to catch this before it happens:

# .git/hooks/pre-commit or a tool like gitleaks
gitleaks protect --staged

Different secrets per environment. Staging and production should never share an API key or database credential. A leaked staging key should never be able to touch production data.

Rotate on offboarding, not on a calendar. The moment someone leaves who had secrets access, rotate everything they could have seen — that day, not at the next scheduled rotation.

One owner per secret category. Someone should be able to answer “who can see the Stripe key” in one lookup, not by reconstructing it from memory of who’s been added to what over time.

What to skip

Skip secret versioning history, automatic rotation schedules, and fine-grained per-secret policies until you’ve outgrown a managed tool’s defaults. Doppler or Infisical’s out-of-the-box access model covers a small team completely. Build custom policy logic only when a specific compliance requirement forces it.