Every developer has done it. A new teammate joins, needs the environment variables, and someone pastes the entire .env file into a Slack DM.

That message now lives in Slack's searchable history, backed up to Slack's servers, accessible to any workspace admin, and retrievable long after the credentials should have been rotated.

The problem with .env file sharing

Environment files are uniquely dangerous because they concentrate every secret your app needs in one place: database URLs, API keys, signing secrets, third-party tokens. A single .env leak can compromise every external service your application connects to.

Common ways teams share .env files — and why they fail:

Slack/Discord DMs — Searchable, backed up, persist after employee offboarding
Email — Stored in plaintext on mail servers, often forwarded unintentionally
Git commits — Even in private repos, secrets in history are nearly impossible to fully remove
Shared drives — No expiration, no access control, no audit trail
1Password/Bitwarden notes — Requires both parties to have accounts in the same vault

A better approach: encrypted self-destructing links

Instead of sending the file contents directly, encrypt them first and share a link that self-destructs after viewing.

From the browser

Go to vaulted.fyi
Paste your .env file contents
Set a view limit (1 view for a single recipient) and expiration
Send the generated link to your teammate

The contents are encrypted with AES-256-GCM in your browser before anything is sent. The decryption key lives only in the URL fragment — the server never sees your plaintext.

From the terminal

If you prefer the command line, the Vaulted CLI does the same thing:

# Pipe directly from the file
cat .env.production | npx vaulted-cli --views 1

# Or pass the file path
npx vaulted-cli --file .env.local --views 1 --expires 1h

# Add a passphrase for extra security
cat .env | npx vaulted-cli -v 1 -e 24h -p "ask-me-on-call"

The CLI uses the same encryption as the web app — same algorithm, same zero-knowledge architecture, same self-destructing links. The output is a single URL you can paste into Slack or wherever, and it expires after the recipient views it.

What about secrets managers?

Tools like Doppler, Infisical, and AWS Secrets Manager are great for production environments where secrets are consumed by applications. But they solve a different problem — they manage secrets that services read programmatically.

The .env sharing problem is about the human-to-human handoff: onboarding a new developer, sharing a staging config with a contractor, or distributing updated credentials after a rotation. That handoff needs to be quick, secure, and require zero setup from the recipient.

Best practices for .env file hygiene

Never commit .env files to Git — Add .env* to .gitignore from day one
Rotate credentials after sharing — Treat every share as a potential exposure
Use view-limited links — One view per recipient, short expiration
Add a passphrase for production configs — Share the passphrase through a separate channel
Document which vars are needed — Keep a .env.example with empty values in your repo

Stop pasting environment variables into Slack. Share them securely with Vaulted — from your browser or your terminal.