Secrets management for small web teams

Every web application has secrets: database passwords, payment gateway keys, API tokens for email and analytics, cloud credentials, signing keys. In large organizations these live in dedicated vaults with policies and audit trails. In small teams they tend to live wherever was convenient the day they were created: a committed .env file, a pinned message in a chat channel, a spreadsheet, a developer's laptop. When we audit a new client's codebase, we find at least one live credential in the Git history more often than not. None of this requires enterprise tooling to fix. Here is the lightweight approach we use with teams of two to twenty.

First, find what is already exposed

Before designing anything, find the secrets that have already leaked. Three places to look:

1. Git history. Run a secret scanner across the full history of every repository, not just the current branch. Deleting a file in a later commit does not remove it from history.
2. Chat and ticketing tools. Search for common patterns such as "password", "api_key", "sk_live" and "BEGIN PRIVATE KEY".
3. Shared documents and drives. Onboarding documents and handover notes are a frequent source.

Anything found must be rotated, not just deleted. Assume that a secret which has been in a repository, a chat log or a shared document has been copied somewhere you cannot see. Rewriting Git history is optional hygiene; rotation is mandatory.

Deleting a leaked key from the repository fixes nothing. Revoking and replacing it fixes the leak.

Decide where secrets live

A small team needs exactly two places for secrets, each with a clear purpose:

• A team password manager for secrets that humans use: hosting logins, registrar accounts, dashboard credentials, recovery codes. Organize it with shared vaults per client or project, and give access by role rather than by person where the tool allows.
• A runtime secret store for secrets that applications use. This might be your hosting platform's environment variable settings, your cloud provider's secret manager, or your CI system's encrypted secrets. The key property is that secrets are injected at deploy or run time and never stored in the repository.

Everything else, including chat, email, tickets and documents, is off limits for secrets. When someone needs to share a credential with a colleague, it goes through the password manager's sharing feature.

Keep secrets out of the codebase

Structure configuration properly

Applications should read secrets from environment variables or a secret store at runtime. Commit a .env.example file listing every variable the application needs, with placeholder values, so new developers know what to set up. The real .env goes in .gitignore from the first commit.

# .env.example
DB_HOST=127.0.0.1
DB_PASSWORD=change-me
STRIPE_SECRET_KEY=sk_test_placeholder
MAIL_API_KEY=

Block leaks before they happen

A pre-commit hook running a secret scanner catches most accidental commits on the developer's machine. As a second layer, run the same scanner in CI on every pull request, and enable secret scanning features in your repository host where available. The CI check matters because pre-commit hooks can be skipped or never installed.

Scope and rotate

Once secrets are stored properly, reduce the damage any single one can do:

• Use separate credentials per environment. Development, staging and production should never share a database password or payment key. Most payment and email providers offer test-mode keys for exactly this reason.
• Scope API keys to the minimum permissions. A key used only to send transactional email should not be able to manage domains or read contact lists.
• Prefer short-lived credentials where the platform supports them, such as cloud roles assumed by CI jobs instead of long-lived access keys.
• Rotate on a schedule and on events. We rotate high-value production secrets at least annually, and immediately when someone with access leaves or a leak is suspected.

Rotation is only painful if it has never been practiced. Write a short runbook for each critical secret: where it is used, how to generate a new one, where to update it and how to verify the change. The first rotation of a database password might take two hours; with a runbook, the next takes fifteen minutes.

Rotate when people leave

Secrets management is also an offboarding problem. When a developer or contractor leaves, list every secret they could read, in the password manager and in the runtime store, and rotate the ones that grant production access. Password managers make the first half easy because they show exactly which vaults a person could open. The second half is easier if runtime secrets are grouped by application and environment, so you can see at a glance which ones a departing person touched. Teams that skip this step often discover months later that a former contractor's laptop still holds a working production database password.

What this costs and what it saves

For a small team, the tooling cost is a password manager subscription and a few hours to wire up scanners and runtime secrets. The initial cleanup, including scanning history, rotating exposed keys and restructuring configuration, typically takes two to five days depending on the number of applications and integrations. Against that, a leaked cloud key can generate thousands of dollars in fraudulent compute charges within hours, and a leaked payment key can mean refunds, fines and a painful conversation with your provider.

We handle secret cleanup and runtime configuration as part of our CI/CD pipelines work, since that is where secrets are most often injected. For a broader review that includes secrets alongside access and infrastructure, see our security audits, and for teams moving to cloud-native secret stores, AWS setup and management covers the migration.

Get your secrets under control

Share the number of repositories and environments you run, and we will scope a fixed-price cleanup that finds exposed keys, rotates them and puts guardrails in place. Request your quote here.