How to share .env files with your team (without Slack)

Almost every small team starts the same way: someone sets up the project, then pastes the .env into a Slack DM so the next person can run it. It works — for about a week. Then the keys rotate, someone's copy goes stale, a new hire asks for "the latest env," and nobody's sure who still has a copy of the production database password from four months ago.

The question "how do I share .env files with my team" usually has a better answer than the file itself. Here are the real options, with honest trade-offs.

Why Slack and email are the wrong place

Pasting secrets into a chat or an email feels fast, but it creates problems that compound:

• It never goes away. The secret lives in the message history (and its backups, and search indexes) forever. Revoking access to the channel doesn't un-send it.
• You can't revoke one person. Once it's pasted, anyone who ever saw the thread has the keys. There's no "remove access for this contractor."
• It drifts. Each person's copy is a snapshot. Rotate a key and you're back to DMing everyone the new value — and someone always misses it.
• No audit trail. Six months later, "who has the prod keys?" has no answer.

The options, ranked

1. A shared password manager (1Password, Bitwarden)

A real step up from Slack: secrets live in a vault with per-person access you can revoke, and tools like 1Password's CLI can pull them into your shell. For many teams this is enough, and it's a fine answer.

The catch: it's built around humans copying values out. Someone still pastes them into a local .env to actually run the app, so you're back to a plaintext file on disk and the same drift problem when keys change. It also wasn't designed around per-environment dev/staging/prod separation.

2. A cloud secrets manager (AWS / GCP Secrets Manager, Vault)

The right call once you're at real scale or have compliance needs. Powerful, auditable, integrates with your infra. The trade-off is setup and operating cost: these are platforms you configure and maintain, which is overkill for a three-person team that just wants everyone running the same secrets.

3. A vault the CLI reads at runtime (no file passed around)

The middle ground that fits small teams: store secrets once in a shared vault, and have a CLI pull them straight into the process when you run your app — so there's no .env to send anyone in the first place. New teammates don't get a file; they authenticate and the secrets are there. Rotate a key once and everyone has the new value on their next run. This is the approach Klavex takes.

What "no file to share" looks like in practice

With a runtime-injection setup, onboarding a teammate is a clone and one command instead of a Slack paste:

pip install klavex
klavex init                 # pins this repo to the shared project + environment
klavex run -- npm start     # secrets pulled from the vault into this process

You commit a small .klavex pin (which points at the project and environment — no secrets in it) so teammates inherit the same binding automatically. The first person imports the existing .env once; after that, nobody passes a file around. Access is per-person and revocable, rotations are instant for everyone, and you get an audit trail of who pulled what.

What about CI and AI agents?

The same model handles the non-human cases without sharing your master secrets. For a CI job or a coding agent, you mint a read-only token scoped to specific environments — grant it Dev, and Production stays out of reach. You hand the pipeline a token, not your keys, and you can revoke that one token without touching anyone else's access.

One honest caveat

None of this is a sandbox. Whoever can run the app can read the secrets it uses at runtime — that's true of every option here, including a plain .env. The win isn't making secrets unreadable to your own team; it's removing the loose copies in chat history, making access revocable per person, and keeping everyone on the same values without manual re-sharing.