How to send and share .env files securely

The handoff problem

A new developer joins the team. They need the .env file to run the project locally. Someone zips it up and drops it into a Slack DM. The developer downloads it, sets up their environment, and starts working.

Six months later, another developer joins. They search Slack for ".env" and find the original message. The file is still there, with every key still valid. The database password, the third-party API tokens, the signing secret. All sitting in a channel that anyone on the team can search.

Where .env files end up

A .env file sent over Slack or email doesn't stay in one place. The messaging platform indexes it for search. Compliance exports capture it. Device backups include it. Any third-party integration with read access to your workspace can pull it.

Unlike a single API key, a .env file often contains everything at once: database credentials, payment processor keys, OAuth secrets, internal service tokens. One file in the wrong export means rotating every secret in the project.

How to send a .env file with Secret.Broker

1 Go to the tool and click the attachment button. Select the .env file. Your browser compresses it into an archive, then encrypts the whole thing with XChaCha20-Poly1305 before anything is uploaded.

2 Set the view limit and expiry. For a single developer, set the limit to 1 and the expiry to a few hours. If they don't grab it in time, the file is deleted and you create a new link.

3 Send the link over whatever channel you normally use. The decryption key is in the URL fragment and never reaches the server.

4 The developer opens the link and downloads the decrypted .env file. The encrypted data is hard-deleted from the server. What's left in the chat is a dead link that returns nothing.

Onboarding new developers

The most common reason to send a .env file is onboarding. A developer needs the local development config to run the project. They need it once, and after that they have their own copy.

Set the view limit to 1 and a short expiry. The developer downloads the file, drops it into their project root, and the link stops working. If they lose the file later, you send a new link instead of pointing them at a six-month-old Slack message.

Deploying to staging

Staging environments need production-adjacent config: real API keys to third-party services, database credentials for the staging cluster, feature flags. Pasting these into a CI/CD tool's web UI is one option. Sending them to the person doing the deploy is another.

For deployment configs, set the view limit to match how many people or systems need the file. A one-hour expiry is usually enough for a deploy window.

Sharing with contractors

External contractors need enough access to do their work, and that access should end when the work does. Sending a .env file through a self-destructing link means the contractor gets the config they need, and the file isn't sitting in a shared channel after the contract ends.

For high-value credentials going to people outside your organisation, use paranoid mode. It splits the link and the decryption key into two separate values. Send the link over email and the key over a different channel. Anyone who intercepts only one of the two gets ciphertext they can't open.

What this doesn't replace

This is not a secrets manager. It doesn't store .env files long-term, rotate keys, or inject variables into your deployment pipeline. HashiCorp Vault and AWS Secrets Manager handle that.

This is not a substitute for .gitignore. If your .env file is committed to the repository, a self-destructing link doesn't fix the problem. Fix the repository first.

This handles one thing: getting a .env file from one person to another without leaving a copy in every system between them. For sharing individual API keys, you can paste them directly instead of attaching a file.

File size and format

Maximum file size is 20 MB, which covers any reasonable .env file. The same attachment workflow handles JSON config files, YAML secrets, SSH keys, PEM certificates, and anything else that shouldn't end up in a chat log or Git history.