Secrets management is how a team stores, distributes and controls access to the credentials an application needs to run: API keys, database passwords, tokens, certificates, encryption keys. It covers where those values live, who can read them, how they reach your code, and what happens when one needs changing.
Every team does secrets management. Most do it accidentally, with a .env file on each laptop and a Slack message when something changes. That works until it doesn't, and this guide is about the point where it stops working and what to do then.
Written for teams of roughly 2 to 20. Most material on this topic is aimed at enterprises with a platform team, which makes a small team feel like it is doing everything wrong. Some of it genuinely does not apply to you, and this says so where that's the case.
What counts as a secret
Anything that grants access to something:
- API keys — Stripe, OpenAI, SendGrid, whatever you call
- Database credentials — connection strings, usernames, passwords
- Tokens — JWT signing secrets, OAuth client secrets, service account tokens
- Certificates and private keys — TLS certs, SSH keys
- Encryption keys
What is not a secret: a port number, a public API base URL, a feature flag, a log level. These are configuration. They live in the same .env file for convenience but they carry no risk if seen, and mixing the two is why people end up treating the whole file as either more or less sensitive than it is.
The test: if this value appeared in a public GitHub repo, would you have to change it? If yes, it's a secret.
Why the .env file stops working
A .env file is a text file of KEY=value lines that your app reads at startup. It is the right answer for one developer on one machine, and it is where nearly everyone starts. What is a .env file covers the format properly.
The problems appear in a predictable order.
Someone else needs the values. A second developer joins. The file is in .gitignore, correctly, so they can't get it from the repo. Someone pastes it into Slack. Your production database password now lives in a chat log with whatever retention policy Slack has, readable by anyone who joins the workspace later.
A credential changes. You rotate the database password. You update your file. The other two developers don't, and spend an hour debugging a connection error before someone remembers to tell them.
Environments get crossed. Someone runs a migration script with production credentials loaded because they copied the wrong file. This is the single most common small-team incident, and it is not an attack.
Someone leaves. They still have a file on their laptop with production credentials. There is no list of what to rotate because nobody wrote down what was in it.
A file gets committed. Someone runs git add -A in a hurry. Now the key is in git history forever, and deleting it in a later commit does not remove it.
None of these are exotic. They are the normal life cycle of a growing team, and they are what secrets management exists to prevent.
How secrets management works
Whatever the tool, the shape is the same.
One central store. Secrets live in one place instead of on each laptop, in CI settings, in a cloud console and in someone's password manager. The OWASP guidance calls this out as the foundational step, because scattered secrets can't be audited, rotated or investigated after an incident.
Access control. Each person and service can read only what they need. In practice for a small team this means at minimum: not everyone can read production.
Delivery to the application. The code needs the value at runtime. Three common mechanisms:
- Pull to a file: a CLI writes a
.envon demand, so your app reads it as before - Inject into the process: the tool runs your app with the values in its environment, no file on disk
- SDK fetch: the application calls the store's API at startup
Environment separation. Development, staging and production hold different values, and they can't be confused for one another.
An audit log. Who read what, who changed what, when. Not compliance theatre — this is what lets you answer "what did the person who just left have access to."
Rotation. Changing a credential and having every consumer pick up the new value without a manual round of messages.
What a small team actually needs
Ranked. Do them in this order.
1. Nothing sensitive in git. Check .gitignore covers .env and .env.*. If something was ever committed, rotate it and clean history. This is the highest-value thing on the list and costs nothing.
2. Separate environments. Different credentials for development, staging and production, held separately enough that using the wrong one is difficult rather than easy.
3. One agreed place. Even before you pick a tool: "secrets live here, and only here" beats four half-remembered locations.
4. A way to share that isn't chat. This is the point where a tool starts earning its cost. The value is not encryption — it's that there is one current copy and everyone gets it automatically.
5. Know who can read production. You don't need an access matrix. You need to be able to answer the question.
6. Rotate when people leave. The rotation that actually matters, and it's event-driven, not scheduled.
Further down, and honestly optional at your size: automated rotation schedules, dynamic secrets with short TTLs, formal approval workflows, full consumer inventories. These are good practices aimed at organisations with dedicated security staff. The OWASP cheat sheet explained covers which of its recommendations apply to a small team and which don't.
The options
Do nothing yet. Solo, no production environment, test credentials only. A .env in .gitignore is genuinely fine. Don't add tooling to solve a problem you don't have.
Encrypted files in git. SOPS or git-crypt encrypt the file so it can be committed, decrypted with a key you hold. Free, mature, no server. The cost is that key distribution and "who changed what" become your problem.
Your cloud provider's manager. AWS Secrets Manager, Google Secret Manager, Azure Key Vault. Cheap, IAM-native, excellent for services reading secrets at runtime. Weak for developers syncing a .env to a laptop — there's no team workflow. AWS Secrets Manager pricing covers the costs and the Parameter Store alternative.
Self-hosted open source. Infisical or HashiCorp Vault, run by you. No per-seat cost, full control, and you own the uptime, upgrades and the person who understands it. Vault pricing covers what "free" actually costs to operate.
A hosted secrets manager. Doppler, Infisical Cloud, Krypt and others. Nothing to run, built around the developer workflow. Most charge per seat, which is the main thing to check against your headcount. The full comparison is here.
Disclosure: we build Krypt, one of the hosted options. It's priced flat for the whole team rather than per seat. It has no SSO and no SOC 2, so if you need either, one of the others is the right pick and we'd say so.
How it fits with what you already have
Secrets management does not replace the tools you use — it feeds them.
Local development. The CLI writes your .env or injects values into the process. Your code is unchanged.
CI/CD. The pipeline holds one credential for the secrets store and pulls everything else at build or deploy time, instead of a dozen values copied into CI settings. Injecting environment variables into builds covers this per platform.
Docker. Values arrive via --env-file or the process environment, or BuildKit secrets for build-time credentials that must not persist in a layer. Docker Compose environment variables covers the details.
Your hosting platform. Railway, Vercel, Heroku and the rest have their own environment variable settings. Either you sync into them, or your app pulls at runtime. Heroku config vars covers that case.
Your language. Nothing changes in code. process.env.DATABASE_URL in Node, os.environ["DATABASE_URL"] in Python. The value just arrives differently.
Common mistakes
Treating the tool as the whole answer. A secrets manager gives you centralisation, access control and an audit log. It does not give you the discipline not to paste a key into Slack, and no product fixes that.
Putting secrets in a frontend build. Anything compiled into browser JavaScript is public. VITE_ and NEXT_PUBLIC_ prefixes exist to make you think before you do it.
Rotating on a calendar but not on departure. A quarterly schedule matters less than rotating the day someone leaves.
One shared credential for everything. When it leaks you can't tell which service was compromised, and rotating it breaks everything at once.
Adopting enterprise practices too early. Dynamic secrets and automated rotation pipelines are excellent and they assume infrastructure you probably don't have. Get the basics right first.
When to start
Three triggers. Any one of them is enough:
- A second person needs the same credentials
- You have a production environment you'd be upset to lose
- You've pasted a secret into a chat window
Before any of those, a .env file and good git hygiene is a complete answer.
FAQ
What is secrets management? Storing, distributing and controlling access to credentials an application needs — API keys, database passwords, tokens, certificates — across the people and systems that use them, including rotation and auditing.
What is the difference between secrets management and a password manager? A password manager stores credentials for humans to log in with. A secrets manager stores credentials for applications, separated by environment, delivered to code at runtime. Some products do both; most do one well.
What are secrets in DevOps? Any credential a system needs to authenticate: API keys, database passwords, service account tokens, TLS certificates, SSH keys, signing keys.
Do I need a secrets manager for a small project? Not if you're working alone with test credentials. You need one when a second person needs the same values, or when production credentials exist that you'd be upset to leak.
Is a .env file secure? The file itself is plain text and offers no protection. Security comes from what surrounds it: not committing it to git, restrictive file permissions, and never sending it over chat or email.
How do I share environment variables with my team safely? Not by chat or email. Either an encrypted file with the key distributed separately, or a secrets manager where each person pulls the current values with a command.
How do you automate secrets management in DevOps? Store secrets centrally, give the pipeline one credential to read them, pull at build or deploy time rather than copying values into CI settings, and rotate through the store so every consumer picks up the change automatically.
What is the OWASP guidance on secrets management? The OWASP Secrets Management Cheat Sheet covers the full lifecycle — creation, storage, access control, rotation, revocation, auditing — and recommends centralisation as the foundation. Explained for small teams here.