Team Workflow

How to Share Environment Variables with Your Team

A new developer joins your team. They need database credentials, API keys, and service tokens to run the app locally. What happens next usually involves a Slack DM, a screenshot, and a shared document that nobody remembers to update. There is a better way.

The Slack DM Problem

Picture the conversation. A senior developer pastes 15 lines of environment variables into a direct message. The new hire copies them into a .env file. Everything works. But now those secrets exist in:

—The Slack message history, searchable by anyone in the workspace.
—The new developer's local machine, in an unencrypted plaintext file.
—Slack's data retention and backup systems — possibly for years.
—Any device where Slack is installed, including personal phones.

When the developer leaves the company, those secrets are still in the chat history. There is no way to revoke access to a Slack message. There is no audit trail of who copied what. And if someone pastes the wrong values — production instead of development — you find out when something breaks.

What Not to Do

Every team invents a secret-sharing workaround. Most of them introduce more problems than they solve:

Shared .env in Dropbox or Google Drive

Anyone with the link can read the file. No versioning, no access control, and no way to know who downloaded it or when. The file goes stale within days.

Email

Secrets live in mail servers, backups, forwarded threads, and auto-complete caches. Email is the least revocable medium after a Post-it note.

Wiki or Confluence page

Every page view is a potential screenshot. Secrets in wikis get indexed by search, cached by browsers, and forgotten when credentials rotate.

1Password shared vault

Better than the alternatives above, but not designed for environment variables. Developers still have to manually copy values into local files. There is no integration with your dev workflow, no per-environment separation, and no audit trail tied to secret usage.

Committed .env.example with real values

Intended as a template, but someone inevitably pastes real credentials into the example file. Once committed, the values are in Git history forever.

The Right Way: Centralized Secrets Management

The core principle is simple: secrets live in one place, access is controlled per person and per environment, and every read and write is logged. Developers pull secrets on demand instead of copying files around. When someone leaves, you revoke their access and the secrets are no longer available to them — no credential rotation required unless you choose to.

Setup in 2 Minutes

Here is the step-by-step process to go from Slack DMs to centralized secrets:

1. Install and authenticate

Terminal

npm i -g @secr/cli
secr login

2. Initialize your project

Terminal

cd your-project
secr init

This creates a .secr.json config file and sets up three default environments: development, staging, and production.

3. Import your existing secrets

Terminal

# Import from an existing .env file
secr migrate .env

# Or set secrets individually
secr set DATABASE_URL="postgresql://localhost:5432/myapp"
secr set STRIPE_SECRET_KEY="sk_test_..."
secr set OPENAI_API_KEY="sk-proj-..."

4. Invite your team

Invite team members from the dashboard or via the API. Each person gets their own account with role-based permissions.

5. Run your app

Terminal

# Secrets are injected at runtime — no .env file needed
secr run -- npm dev

Role-Based Access

Not every team member needs access to every secret. secr provides four roles with increasing levels of access:

Role	Can do	Typical use
Viewer	Read secrets in development	Junior developers, contractors, interns
Developer	Read and write secrets in dev and staging	Most full-time developers
Admin	Full access to all environments, manage members	Tech leads, senior engineers
Owner	Everything, plus billing and project deletion	Project creator, CTO

A contractor working on the frontend should never need production database credentials. With role-based access, they get development secrets and nothing more — without anyone having to carefully edit a .env file before sharing it.

Onboarding a New Developer

With secr, onboarding is a three-command process. No file transfers. No screenshots. No waiting for someone to find the latest version of the .env file.

New developer's terminal

# 1. Install the CLI and log in
npm i -g @secr/cli
secr login

# 2. Clone the project (they already have access via their account)
git clone git@github.com:your-org/your-app.git
cd your-app

# 3. Run the app — secrets are pulled automatically
secr run -- npm dev

That is the entire onboarding process for secrets. The new developer gets exactly the secrets their role allows — dev environment for viewers, dev and staging for developers. No one has to curate a file or remember which keys changed last week.

What about the README? Your onboarding docs go from "ask Sarah for the .env file" to "run secr run -- npm dev." One line in the README replaces a multi-step secret-sharing ritual.

Offboarding

When a team member leaves, the process is equally simple and far more secure than hoping they deleted their local .env file:

1. Revoke their access

Remove them from the organization through the dashboard. All sessions are invalidated immediately. They can no longer pull secrets.

2. Rotate sensitive credentials (optional)

If the departing member had access to production secrets, rotate the critical ones. secr's audit log tells you exactly which secrets they accessed and when.

Terminal

# Rotate a specific secret
secr set STRIPE_SECRET_KEY="sk_live_new_key" -e production

# Check who accessed a secret
# (Use the dashboard audit log to see access history)

3. Review the audit log

The audit log shows every action the team member took — which secrets they read, which they modified, and when. This is useful for compliance and for understanding the blast radius if credentials need to be rotated.

Sharing One-Off Secrets Securely

Sometimes you need to share a single secret value with someone outside your project — a contractor, a partner, or a support engineer. Instead of pasting it in Slack, create a secure share link with automatic expiration:

Terminal

# Create a self-destructing share link (viewed once, expires in 24 hours)
secr share "sk_live_abc123" --expires 24h --label "Stripe key for vendor"

# Output:
# https://secr.dev/shared/abc123...
# Expires: 24 hours | Max views: 1

The link is encrypted end-to-end, self-destructs after the specified number of views, and is logged in your audit trail. Far better than a Slack message that lives forever.

Stop sharing secrets over Slack

Set up your team in two minutes. Every developer pulls the same secrets, with the right access level, and a full audit trail.

npm i -g @secr/cli

secr login

secr init

secr migrate .env

secr run -- npm dev

Create Free Account Setup Guide