Stop Sharing .env Files Over Slack

Right now, somewhere in your company's Slack, there's a message that looks like this:

hey can you send me the staging DATABASE_URL?

And a few minutes later:

postgres://admin:p4ssw0rd@staging-db.us-east-1.rds.amazonaws.com:5432/myapp

It's sitting there in plaintext. Indexed. Searchable. Backed up to Slack's servers. Visible to every admin in your workspace — and anyone who compromises a single Slack account.

This is how most teams share secrets. And it's a disaster waiting to happen.

Why Slack is the worst place for secrets

It's permanent by default

Slack retains messages indefinitely on paid plans. That database password you shared two years ago? Still there. Still searchable. Even if you've rotated the credential, the message history tells an attacker exactly where to look.

It's searchable by anyone

Any workspace member can search for "DATABASE_URL" or "API_KEY" and find every secret ever shared in public channels. Even in DMs, Slack admins and compliance exports can surface them.

It survives offboarding

When someone leaves the company, their Slack messages don't leave with them. Every secret they ever received is still in the workspace. And if they took screenshots or copied messages to notes — you'd never know.

It's a high-value target

Slack credentials are prime targets for phishing. One compromised account gives an attacker access to every secret ever shared in that user's DMs and channels. In 2024 alone, multiple high-profile breaches started with stolen Slack tokens.

The .env file shuffle

Slack is just one symptom. The real problem is how teams manage secrets:

1. Someone sets up the project and creates a .env file
2. They commit it to Git (or not — it depends on the .gitignore)
3. New developers ask for the secrets on Slack, or get a .env file emailed to them
4. Everyone maintains their own local copy
5. When a secret changes, someone posts the update in a channel
6. Half the team misses it and spends hours debugging

This isn't a workflow. It's a game of telephone with your production credentials.

What to do instead

The fix isn't "be more careful with Slack." The fix is to stop putting secrets in Slack at all.

A secrets manager gives every developer access to the secrets they need — encrypted, audited, and versioned — without anyone copying and pasting credentials.

With secr, onboarding a new developer looks like this:

npm install -g @secr/cli
secr login
secr init        # select org, project, environment
secr run -- npm start

No Slack messages. No shared .env files. No "hey, can you send me the staging keys?" The secrets are pulled from the server, injected into the process, and never written to disk.

What changes for your team

But we're a small team...

Small teams are actually at higher risk. You're more likely to have shared credentials, fewer access controls, and no audit trail. When you're moving fast, shortcuts feel harmless — until they aren't.

secr's free tier covers up to 3 projects. That's enough for most early-stage teams. Setting it up takes less time than the Slack conversation you'd have to share the secrets anyway.

Getting started

npm install -g @secr/cli
secr login
secr init
secr set DATABASE_URL "postgres://..."
secr run -- npm start

Five commands. Your secrets are encrypted, synced, and out of Slack forever.

If you've got an existing .env file, import it in one step:

secr migrate .env

Every key from your .env is encrypted and stored. Delete the file. Tell your team to run secr pull instead of asking for secrets on Slack.

---

Your Slack search history is a liability. Move your secrets to secr — it's free for up to 3 projects.