Environment Variables and Secrets Management for Small Dev Teams

Every web app relies on secrets: database passwords, payment gateway keys, email service tokens, cloud credentials. In small teams and agencies, these often end up in places they should not: committed to Git, pasted in group chats, stored in shared spreadsheets or hard-coded in source files.

Leaked secrets are a common cause of breaches and surprise cloud bills. This guide explains practical secrets management that small teams can adopt without enterprise tools.

Keep Secrets Out of Code

Never hard-code secrets in source code or commit them to version control. Even private repositories get shared with freelancers, cloned to laptops and occasionally made public by mistake. Once a secret is in Git history, deleting the line does not remove it from history.

• Load secrets from environment variables at runtime
• Use a .env file for local development, listed in .gitignore
• Commit a .env.example with placeholder values, so others know what is needed
• Enable secret scanning on your code hosting platform if available

If a secret is committed, treat it as compromised: rotate it immediately, then clean history if needed.

Automated bots continuously scan public repositories for leaked keys, especially cloud and payment credentials. Exposed keys can be abused within a short time of being published, so prevention matters far more than cleanup.

Environment Variables in Practice

Environment variables separate configuration from code. The same code can run in development, staging and production with different settings. Most frameworks, including Laravel, Django and Node.js, read environment variables or .env files natively.

1. Use different keys for development, staging and production.
2. Use test or sandbox keys for payment gateways outside production.
3. Set production variables through your host's dashboard or deployment tool, not by uploading .env files manually.
4. Document every variable's purpose in the example file.

Consistent environments reduce surprises; see environment parity.

Validate required variables at startup. If a critical setting is missing, the app should fail clearly with a helpful message rather than running in a half-configured state.

Secret Managers and Team Sharing

As projects grow, a secret manager helps. Cloud providers offer managed secret stores, and many deployment platforms have built-in encrypted environment settings. For sharing credentials between team members, use a business password manager with shared vaults rather than chat messages or spreadsheets.

Rule: if a secret appears in a WhatsApp group or email thread, assume it will eventually be seen by someone it should not be.

Give each person access only to the secrets they need. Developers rarely need production database passwords on their laptops.

Where possible, avoid long-lived secrets altogether. Some cloud platforms let applications use short-lived credentials or identity-based access, which reduces the damage if something leaks.

Rotation and Offboarding

Rotate secrets periodically and always when someone with access leaves the team or a freelancer finishes a project. Keep a simple list of which secrets exist, where they are used and who has access, so rotation is not a scramble.

Prefer credentials that can be scoped and revoked individually. For example, create separate API keys per integration and per environment, with only the permissions needed. If one leaks, you revoke it without breaking everything else.

For agencies, ensure clients own the accounts for critical services and grant developers access, rather than developers owning the client's keys. This makes handovers clean and protects both sides.

Store backups of configuration securely too. Backups that include .env files or database dumps contain secrets and personal data, so they need the same protection as the live system.

Handle Secrets Carefully in Logs and Errors

Secrets often leak through logs, error pages and debugging output. Disable detailed error pages in production, redact sensitive values in logs and avoid printing configuration during troubleshooting. Our guide on logging and observability on a budget covers safe logging practices.

Front-end code is public. Any key included in a browser bundle can be read by anyone, so only publishable keys designed for client use belong there. Sensitive operations should go through your server. For API protection in general, see API security basics.

Include a secrets check in code reviews: reviewers should look for hard-coded keys, debug output and new variables missing from the example file.

FAQ

Is a .env file secure?

It is fine for local development if excluded from Git. In production, prefer your host's encrypted environment settings or a secret manager.

What if a key is leaked publicly?

Revoke and rotate it immediately, check for misuse, then investigate how it leaked.

Do small projects really need this?

Yes. Small projects are frequently targeted by automated scanners looking for leaked keys.

Secrets management for small teams comes down to habits: keep secrets out of code, use environment variables and separate keys per environment, share through a password manager, rotate when people leave and keep secrets out of logs and front-end code.