Short answer: run npx -y evergist create .env --views 1 --expires 1h and send the link it prints. Your teammate runs npx -y evergist read "<link>" > .env.local and the note is deleted. This fits a handoff to one or two people. Once many people need the file, or the values are production credentials, move to a secrets manager.
How do I share a .env file with a new teammate?
One command on your side, one on theirs. Both need Node.js 20 or newer and nothing installed.
You, in the project directory:
npx -y evergist create .env --views 1 --expires 1h
https://evergist.com/g/<id>#<key>
expires: 2026-09-30T13:00:00.000Z
views: 1
delete token: <token>
The CLI reads the file, encrypts it on your machine with AES-256-GCM, and uploads ciphertext. The key is the part of the link after #, and it never reaches our server. Send the whole link.
Your teammate, in their checkout:
npx -y evergist read "https://evergist.com/g/<id>#<key>" > .env.local
read prints the file to stdout. The notice that this was the last view goes to stderr, so the redirected file holds exactly what you sent. After that read the note no longer exists on the server, and the link in your chat history opens nothing.
Three details that save a second round:
- Quote the link. The shell then passes it through untouched, key included.
- Mind the redirect.
> .env.localreplaces an existing file, and it truncates that file even if the read fails. If they already have one, write to a new name and compare. - Check before reading.
npx -y evergist status "<link>"shows expiry and views left without using the view. If it says the note isn't found, it expired, was deleted, or someone or something read it first. The note can't say which, so ask the sender for a fresh one and rotate the values if nobody can account for the read.
Should I send the whole file?
Send what the person needs. A .env usually mixes harmless settings with a few keys that matter, and a new teammate rarely needs your personal tokens or anything live.
Filter on the way in:
grep -v -E '^(STRIPE_LIVE_|AWS_)' .env | npx -y evergist create --views 1 --expires 1h
With no file argument, create reads stdin. Better still, keep a .env.example in the repo with every variable name and no values, and send only the values that can't be public.
The size limit is 512 KiB of UTF-8 text per note, far more than any .env needs. It is text only. If your setup also needs a binary file such as a keystore, base64 it into a separate note.
What if the link ends up in the wrong hands?
Whoever opens the link first gets the file. One view and a one-hour expiry shrink that window, and a password closes most of what's left.
npx -y evergist create .env --views 1 --expires 1h --generate-password
The CLI prints a generated password next to the link. Send the link in chat and the password some other way, such as a call or a text message. The password is mixed into the encryption key, so the link alone decrypts nothing, and ten wrong guesses delete the note. The recipient adds --password "<password>" to read, or sets EVERGIST_PASSWORD to keep it out of their shell history.
If your teammate reports a dead link before they read it, treat the values as exposed and rotate them. If you sent the wrong file, delete the note. A password-protected note needs its password to delete by link:
npx -y evergist delete "https://evergist.com/g/<id>#<key>" --password "<password>"
What should I not do with a .env file?
| Method | What goes wrong |
|---|---|
| Commit it to the repo | It stays in history for everyone who clones. GitHub's guide to removing sensitive data says the first step is to revoke or rotate the secret, and that rewriting history needs coordination with everyone who has a clone |
| Paste it into Slack or another chat | Every value sits in the message history, readable by anyone who gets into that channel or that account later |
| Email it | A copy stays in your sent folder and in their inbox, and in whatever either mailbox syncs to |
| Put it in a ticket, doc, or wiki | Wider audience than you planned, and edit history keeps the old values |
| Zip it with a password | The archive still sits in the chat or mailbox, and the password usually travels right behind it |
Sending the link over Slack or email is fine. The link is only useful until the first read or the expiry, whichever comes first. The file itself never enters the chat. How to share a password securely has the longer version of this list.
When should a team stop sharing .env files?
When the handoff stops being a one-off. A one-time link moves a file between two machines. It does not track who has which value, and it can't update anyone when a value changes.
Switch to a secrets manager, or to your hosting platform's environment sync if it has one, when any of these is true:
- More than a few people need the values, or people join and leave often. Every copy of a
.envis a copy you can't revoke. - You rotate keys. With files, every rotation means sending the file to everyone again.
- The values are production credentials. Production secrets belong in a system with access control and an audit trail, injected at deploy time.
- CI or servers need the same values. Put them in the CI platform's secret storage, not in a file someone uploads.
- A contractor's access has to end on a date. You can end access to a vault. You can only rotate a file's contents.
Evergist is not a vault. It stores nothing past 30 days, has no accounts, and can't tell you who read a note. It's the right tool for day one with a new teammate, a contractor who needs three keys for a week, or moving your own .env to a second laptop.
If the values are already in a shared password manager, share them there instead.
Can I send a .env file to an AI coding agent this way?
Yes, with the same two commands. Create the note yourself and have the agent run npx -y evergist read "<link>" > .env.local, so the values land in a file and not in the chat. The limit is plain. An agent that reads the file or prints it sees the values. Give Claude Code an API key safely walks through that case, and the agent guide covers the MCP server.
Questions
Is it safe to send a .env file over Slack or email?
No. The file's contents stay in the message history and the mailbox long after the teammate has copied them. Send a one-view link through Slack or email instead, and the message left behind points at a note that no longer exists.
How do I send a .env file securely to a contractor?
Filter it down to the keys the contractor needs, create a one-view note with --generate-password, send the link and the password through different channels, and rotate those keys when the contract ends. The contractor needs Node.js to use read, or a browser to open the link and copy the text. How to share sensitive information securely with a client or contractor covers scoping and the handover.
Can Evergist read my .env file?
No. The CLI encrypts before upload, and the server stores ciphertext plus an expiry time, a view counter, and token hashes. The key exists only in the link. The stored record is public, with four ways to verify it yourself.
What happens if my teammate doesn't open the link in time?
The note is deleted at its expiry time and the link stops working. Run the create command again. For a teammate in another time zone, use --expires 1d and keep --views 1.