KeyEnv
KeyEnv
Sign inStart free
← All posts

Stop Making New Developers Beg for API Keys

Stop Making New Developers Beg for API Keys

Your newest developer just joined the team. They cloned the repo, ran npm install, and... nothing works. The app needs 14 environment variables nobody documented. Now they're doing what every new hire does: pinging teammates one by one on Slack, piecing together a .env file like a scavenger hunt.

This is a terrible first impression. And it's a security problem hiding in plain sight.

The Onboarding Tax

Most teams don't realize how much time they burn on env setup. Here's how it typically goes:

  1. New dev clones the repo
  2. App crashes—missing DATABASE_URL
  3. They ask in Slack. Someone shares a partial .env
  4. App crashes again—missing STRIPE_SECRET_KEY
  5. The person who has it is on PTO
  6. Someone eventually pastes it in a DM
  7. Repeat for every microservice

This process takes anywhere from a few hours to a few days. Multiply that by every new hire, every team rotation, every contractor. It adds up fast.

And the security implications are worse than the wasted time. Those Slack messages with API keys in them? They're searchable. Forever. By anyone in your workspace.

Why .env.example Doesn't Cut It

The usual fix is a .env.example file with placeholder values:

DATABASE_URL=postgres://user:password@localhost:5432/myapp
STRIPE_SECRET_KEY=sk_test_replace_me
REDIS_URL=redis://localhost:6379

Better than nothing, but it falls apart quickly:

  • It drifts. Someone adds SENTRY_DSN to production but forgets to update the example file. Now it's missing and nobody notices until the new hire hits a runtime error.
  • Placeholders aren't values. The new dev still needs to ask someone for the real staging credentials.
  • No access control. Junior devs get the same secrets as senior engineers. There's no way to restrict who sees production keys.

What Good Onboarding Looks Like

Imagine this instead:

git clone [email protected]:acme/api.git
cd api
keyenv pull
keyenv run -- npm start

That's it. The new developer runs two commands and has every environment variable they need—scoped to their role and environment. No Slack messages. No scavenger hunt. No stale .env.example to decode.

Here's what happened behind the scenes:

  1. keyenv pull downloaded the secrets the developer has access to, based on their role (member, admin, etc.) and the environment (development, staging, production).
  2. keyenv run injected those secrets into the process without writing them to disk. No .env file sitting in the project directory.

The developer never saw a raw API key in a chat message. The secrets never touched their filesystem. And if they leave the team tomorrow, revoking access is one click—not a panicked rotation of every key they might have copied.

Setting This Up Takes 5 Minutes

If your team doesn't have secrets management yet, here's how to get started:

1. Install the CLI

curl -fsSL https://keyenv.dev/install.sh | sh

2. Create a Project and Push Your Secrets

keyenv init
keyenv push

This encrypts your current .env and uploads it. Your secrets are encrypted with AES-256-GCM before they leave your machine—KeyEnv can't read them even if someone compromised the server.

3. Invite Your Team

Head to the KeyEnv dashboard and invite teammates. Assign roles to control who sees what:

  • Admin: Full access to all environments
  • Member: Access to development and staging
  • Viewer: Read-only access to specific environments

4. Update Your README

Replace your setup instructions with:

## Getting Started

1. Clone the repo
2. Run `keyenv pull`
3. Run `keyenv run -- npm start`

That's the entire onboarding doc for secrets. No more maintaining a .env.example. No more "ask Sarah for the keys."

The Ripple Effects

Once secrets are managed properly, other things get easier:

  • Rotating a compromised key means updating it once in KeyEnv. Every developer gets the new value on their next keyenv pull. No mass Slack message, no broken dev environments.
  • Environment parity becomes automatic. Dev, staging, and production each have their own secrets, and developers access the right set based on context.
  • Audit trails show exactly who accessed which secrets and when. Useful for compliance, essential during incidents.
  • Offboarding is instant. Remove someone from the project and their access is gone. No guessing which keys they might have saved locally.

You Probably Need This Sooner Than You Think

Teams tend to put off secrets management because .env files "work fine" until they don't. The trigger is usually one of these:

  • A secret gets committed to git
  • A contractor leaves and you realize they have production database credentials in their Slack history
  • A new hire spends their entire first day asking for environment variables
  • You fail a security audit

Any of these sound familiar? KeyEnv's free tier covers 3 projects and 100 secrets—enough to fix onboarding for your most critical repos today.

TL;DR: New developers shouldn't spend their first day collecting API keys over Slack. Run keyenv init && keyenv push once, then every new hire just needs keyenv pull to get started.