Secrets Management for Small Teams

I once joined a project where every developer had a 2000-line .env file they passed around via Slack. Database passwords, API keys, production credentials. All of it sitting in DMs, completely unencrypted, never rotated. When I asked about their secrets management strategy, the lead developer said "don't lose the file."

This is more common than anyone admits. Teams know they should manage secrets properly, but the "proper" solutions seem like overkill for a 5-person team. So they do nothing, and the problem compounds.

Here's the good news: you can have secure secrets management without deploying a dedicated secrets infrastructure. Let me show you how.

Why This Matters More Than You Think

A leaked API key isn't just embarrassing - it's expensive. AWS credentials can rack up five-figure bills in hours if someone decides to mine crypto on your account. Database credentials mean data breaches and regulatory problems. Stripe keys mean stolen money.

And secrets leak constantly. GitGuardian reports finding over 10 million secrets exposed in public GitHub repos every year. That's just the public ones.

The Minimum Viable Setup

Before we get fancy, let's establish the basics that every team should have in place:

1. Never Commit Secrets to Git

Add a pre-commit hook that scans for secrets. Use something like git-secrets or gitleaks. These tools catch most accidental commits before they happen.

Also add patterns to your .gitignore:

• .env (and .env.*)
• *.pem
• *.key
• secrets.json

2. Separate Secrets by Environment

Development secrets should be different from production secrets. This seems obvious but I've seen countless teams using production database credentials locally "because it's easier." When a developer's laptop gets stolen, that's a production data breach.

3. Use Your Platform's Secrets Management

If you're on Vercel, Railway, Render, or similar platforms, they have built-in secrets management. Use it. Environment variables set through these dashboards are encrypted at rest and injected at runtime. It's not perfect, but it's infinitely better than .env files in Slack.

The Password Manager Bridge

Here's a technique I recommend for small teams: use your password manager as a secrets store.

1Password, Bitwarden, and others support shared vaults and CLI access. You can store your secrets there and pull them into your development environment with a script.

For example, with 1Password CLI:

export DATABASE_URL=$(op read "op://Engineering/Database/production/url")

This gives you:

• Encryption at rest
• Access controls (who can see which secrets)
• Audit logs (who accessed what)
• Easy rotation (update once, everyone gets the new value)

It's not as sophisticated as a dedicated secrets manager, but it's a massive upgrade from text files.

When to Graduate to Real Secrets Management

The password manager approach works until it doesn't. Signs you've outgrown it:

• You need machine-to-machine authentication (services talking to services)
• You need automatic secret rotation
• You have compliance requirements that demand specific controls
• You're managing more than ~50 secrets
• Multiple teams need different access levels

At this point, look at managed services like AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault. They integrate with your cloud provider's IAM, handle rotation, and provide the audit trails compliance teams want.

The Rotation Question

How often should you rotate secrets? The honest answer: more often than you currently do, but probably less often than security blogs suggest.

My practical recommendations:

Rotate immediately: When an employee leaves. When you suspect a leak. When a secret has been exposed in logs or error messages.

Rotate quarterly: High-value secrets like database credentials, payment processor keys, and admin tokens.

Rotate annually: Lower-risk API keys, development credentials, internal service tokens.

The most important thing is having a rotation process at all. Document how to rotate each secret and practice doing it. The last thing you want is to discover during an incident that nobody knows how to change the database password.

Environment Variable Hygiene

Beyond storage, think about how secrets flow through your system:

Don't Log Secrets

Audit your logging. Search for variable names that might contain secrets. A common mistake is logging full request bodies or environment dumps that include sensitive values.

Don't Pass Secrets in URLs

URLs end up in browser history, server logs, and referrer headers. API keys should go in headers, not query parameters.

Minimize Secret Scope

Does your web frontend really need your database password? Probably not. Structure your application so secrets are only available where they're needed. A leak in your static asset pipeline shouldn't expose your database.

The Developer Experience Problem

Here's the uncomfortable truth: most secrets end up in insecure places because secure options are annoying to use. If getting the latest database password requires a 12-step process, developers will copy it to a sticky note.

Whatever system you choose, optimize for developer experience:

• One command to set up a new development environment
• Automatic secret injection (no manual copying)
• Clear error messages when secrets are missing
• Documentation that explains not just how but why

Security that people work around isn't security at all.

Incident Response Prep

Assume a secret will leak eventually. Prepare for it now:

• Document every secret you have and what systems use it
• Write rotation procedures for critical secrets
• Know how to revoke access for each third-party API
• Set up alerts for unusual API usage patterns

When a leak happens, you want to be following a checklist, not figuring things out under pressure.

Starting This Week

You don't need to overhaul everything at once. Here's a progression:

This week: Add git-secrets or gitleaks to your repo. Stop the bleeding.

This month: Move production secrets to your platform's environment variables. Get them out of files.

This quarter: Evaluate a secrets management solution. Set up rotation for your most critical credentials.

Perfect is the enemy of good here. A team with basic secret hygiene is in better shape than a team that's been "planning to set up Vault" for two years while continuing to share .env files.