How to share .env files with your team

Every team solves this eventually, usually badly, usually the week someone new joins. Here are the five ways it is actually done, from worst to best, with honest trade-offs.

1. Slack, email, or DMs (most common, worst)

Paste the file, move on with your day. The cost arrives later: chat messages never expire, they live in every export and backup, there is no revoke when someone leaves, and no record of who used what. A production credential in chat is a permanent copy you no longer control. If you take one thing from this page: stop doing this.

2. A shared password manager note

Better: encrypted at rest, some access control. But .env files are not passwords: they change often, they differ per environment, and pasting a 40-line file into a note field guarantees stale copies. Password managers also cannot answer "who pulled prod config last Tuesday".

3. Encrypted files in the repo (SOPS, dotenv-vault, git-crypt)

A genuinely good pattern for infra-as-code shops: secrets ride along with git history, encrypted with a shared key. The weakness is the shared key itself: distributing it needs a second channel, and revoking one person means rotating and redistributing for everyone. Fine for stable senior teams; painful with churn. Comparison here.

4. A secrets platform (Vault, Doppler, Infisical)

The right answer at scale: dynamic secrets, integrations, SSO. The cost is setup and ongoing ownership, and in most hosted platforms the provider can technically read your secrets, since they decrypt server-side to power features. For a 4-person team this is a lot of machine for the job. When it is worth it.

5. Purpose-built encrypted .env sharing

The narrow tool: keep the .env format, encrypt on the developer's machine, give each person their own key, revoke in one command, log every access. This is what Keyline does. Setup is one command per person and the server never sees plaintext, so a breach of the vendor is not a breach of you.

More guides

• How to share .env files with your team
• Next.js environment variables, done right for teams
• .env in CI without leaking it
• Docker and .env: keeping secrets out of images

The checklist, whatever you pick

• Client-side encryption: can the vendor read your secrets? Ask, then verify.
• Per-person access: leavers must be revocable without re-keying the whole team.
• Per-environment scoping: new contributors get dev, not prod.
• An audit trail of reads, not just writes: leaks start with a read.
• No workflow change: if the tool fights your app's config format, nobody will use it.