How to share environment variables safely with your team

The worst channel wins: if one person shares .env over Slack, you now have indefinite retention, search indexing, and unknown forwards — regardless of your “official” policy. Safe sharing is boring infrastructure, not clever encryption in chat.


1. What you are actually trying to achieve

  • New hires get dev access without seeing prod.
  • Rotation does not require hunting twelve stale copies.
  • Audit knows who had access (when compliance cares).

2. Do not do this

ChannelProblem
Slack / Teams / DiscordRetention, screenshots, mobile sync
EmailForwarding, legal hold, wrong recipient
GitHub gist “private”Easy to mis-click public; account compromise
Wiki pasteCached, indexed, copied into tickets

If it already happened, treat as leak: .env leaked.


3. Preferred patterns (ranked)

A. No sharing — per-developer credentials (best)

Many vendors support per-user API keys or OAuth for dev sandboxes. Everyone gets sk_test_..._alice. Revoke one person without rotating the whole team.

B. Company-approved secret platform

  • Enterprise password manager with shared vaults (role-based).
  • Doppler / Vault / cloud secret manager with SSO and audit.

Trade-offs vs pure local: local-first vs cloud.

C. Self-hosted OpenBao / Vault

For teams that want no SaaS but still need central RBAC — operational cost is real; see open source secret managers compared.

D. Encrypted file with known key distribution (SOPS, age)

Works for infra teams; easy to foot-gun. Not a substitute for culture.


4. What should be in the repo instead of secrets

Commit README.md sections:

  • Which variables exist (DATABASE_URL, STRIPE_SECRET_KEY, …).
  • Where to obtain values (internal portal URL, “request access in #infra”).
  • Which are required for npm run dev vs optional.

Commit .env.example with fake values only — keep secrets out of Git.


5. Onboarding checklist (template)

  1. Add to GitHub org / GitLab group with least privilege.
  2. Provision vendor dev keys (automated if possible).
  3. Point them at approved secret store — not a forwarded email thread.
  4. Run gitleaks on their first laptop clone as a teaching moment.

6. macOS developers and local-first

Individual devs still need fast access on laptops. PassStore keeps personal dev material encrypted at rest with workspace grouping — complementary to team platforms, not a replacement for org-wide audit if you need SOC2 evidence on every read.


Related