It is three in the afternoon on a Wednesday when a backend engineer who started two weeks ago asks in the team channel where the production database connection string lives.
Someone begins scrolling. Forty-odd screens up, they find a .env file that an intern posted six months ago. Three keys inside. Two have been rotated since. The third points at last year’s staging database. The copy that production actually runs sits on the ops engineer’s laptop, in a file named env_backup_final(2).txt.
The question gets answered, eventually. It is the second half of the story that stings: the intern left three months ago, and nobody remembered that his phone still holds a complete production config.
Nobody was careless here. It is more like a process with a missing part. Secrets never had one correct place to live, so they spread across chat history, note apps, CI variable boxes, and somebody’s home directory. Once they are spread out, rotation turns into archaeology. You have to find every copy before you can change anything.
A file format that has held on for too long
.env was not a mistake. It caught on more than a decade ago because it needed no explanation: one key and value per line, it runs locally, and you hand it to the process at deploy time.
What it assumes is that the file is safe and that you are the only one holding it. Both assumptions break as a team grows. The file has to reach a new colleague, go into CI, be readable by a test machine. So it copies. Once copies exist, “the current version” stops meaning anything. The one you edited may not be the one running. The key you deleted may still be in use by three services.
Infisical was built for this problem. It is open source on GitHub (https://github.com/Infisical/infisical), lives at infisical.com, and describes itself as a platform for managing secrets, certificates, and access. In the last couple of years it has also moved into credentials for AI agents. The core idea is plain: secrets stop moving around as files, they sit in one place, clients fetch them by identity, and the fetches leave a record.
For many teams that is enough. Enough and suitable are different words, which is why people still search for alternatives.
Why a team starts looking
The reasons tend to be specific rather than philosophical.
The first is the cost of self-hosting. Infisical can be deployed inside your own network, which matters a great deal to teams whose data cannot leave it. It is still a full service: a database, a cache, a backend process, plus upgrades, backups, and TLS. A team of five that only wanted secrets out of the group chat can end up spending half a day a month keeping a platform alive. That trade is not always worth it.
The second is the shape of the bill. The cloud product is tiered by seats and features, and headcount pushes you up a tier. Some teams have three or five services that need secrets and end up paying for the whole engineering department.
The third is the stack you already run. If everything sits on AWS, IAM already handles identity. Adding a separate permission system means every hire and every departure gets processed in two places. Every extra system is one more place to forget to sync.
The fourth is a narrow requirement. Some teams want exactly one thing: encrypt these config files and commit them to Git. No UI, no server, no dashboard for anyone to watch.
Those four situations point at different answers, so it helps to sort the problem before shopping.
Vaults, keychains, and envelopes
Tools on the market sit in roughly three positions, and understanding the layers is more useful than memorizing feature lists.
The first layer is the centralized secret service. It has a server, a database, an API, and clients trade identity for secrets. Infisical, HashiCorp Vault, Doppler, and AWS Secrets Manager belong here. They solve the single source of truth problem, and they bring access control and audit along with it.
The second layer is the password manager growing an arm for machines. 1Password and Bitwarden started out storing passwords for people, then added an interface for software. They solve the “we already pay for this” problem.
The third layer is not a service at all. It is file encryption. SOPS is the reference: it encrypts the values in config files, leaves the structure readable, and the result goes into Git. It solves the “I do not want to run another machine” problem.
The capability boundaries between these layers are wide. Putting all of them in one feature table produces odd conclusions. The question worth asking is whether you need a system that can answer “who read the production password, and when”, or a way to keep config files safely inside the repository.
HashiCorp Vault and OpenBao: the ceiling on capability, the floor on operations
Picture a payments company with a dozen backend engineers, three environments, and a compliance team that wants a report naming everyone who read the production database password and when. In that room, Vault is close to the default answer.
It has been around longer than anything else in this category, and its strongest feature is dynamic credentials. The database password is not stored and handed to you. It is generated per request, carries a time to live, and expires on its own. If an application is compromised or a log leaks a credential, the usable window is minutes. Static secret schemes cannot do that, and it is the main reason Vault has been hard to replace outright.
The price is operations. Vault does not work the moment it is installed. It needs storage of its own, either the integrated Raft backend or an external database, then initialization, then unsealing, then a plan for high availability and backups. Plenty of small teams stall on two things: TLS certificates and where to keep the unseal keys. Key custody is a philosophical problem dressed as a technical one. You split the key into shares for safety, distribute them, and then two of the holders take vacation in the same week.
Licensing has a dividing line. In 2023 HashiCorp moved Vault from MPL 2.0 to BSL 1.1, and the community forked OpenBao, which is now hosted by the Linux Foundation and remains MPL 2.0. So if the worry is whether the open version will stay open, OpenBao is that path. If you want vendor support and a hosted product, the enterprise and cloud offerings of Vault are still there.
In one sentence: a clear compliance requirement, someone who knows operations, and a need for dynamic credentials make the extra complexity worth it. Miss one of those three and the system tends to become something that was deployed and that nobody dares to touch.
Doppler: secret management as a web page
Doppler takes the opposite route. You sign up, create a project, create environments, paste the contents of a .env file, install a CLI, and prefix your start command with doppler run. Environment variables arrive in the process. The whole thing takes ten minutes and no documentation reading.
It is essentially pure SaaS, with no self-hosted product as the main offering. For a team whose secrets cannot leave the private network, that ends the conversation. For a group of ten with services on Vercel and Fly.io, it removes the most expensive part: nobody has to maintain a machine for secrets.
Pricing is tiered by seats and projects, with a free tier to try. Integrations are where it shines. GitHub Actions, GitLab, and Kubernetes all have documented paths, and pulling secrets in CI is mostly a copy of the docs.
The interface speaks plainly. Environments are dev, staging, prod. Secrets can be overridden per environment, and changes apply immediately without restarting the service. If your code reads environment variables at boot, you still restart, and no tool can decide that for you.
Its limits are equally clear. It stores static secrets. There are no dynamic credentials, and permissions are organized by project and environment. That is enough until someone asks for a rule saying this person may read three keys in production and nothing else, at which point the model starts to feel tight.
AWS Secrets Manager: if you already live in AWS
For a team whose stack is entirely on AWS, the attraction is not a feature. It is not adding a new trust boundary.
IAM already manages the identity of people and services, and Secrets Manager reuses it. Which Lambda can read which secret is an IAM policy. Rotation can be configured, and RDS credentials can rotate on a schedule with a Lambda doing the password change. Audit goes through CloudTrail. The logs are not pleasant to read, but they belong to the same system you already use.
The weak spot is everything outside AWS. Multi-cloud, a private data center, or a developer running a service on a Mac all need a detour. Cross-account sharing exists, though configuring it is not a good time.
Billing runs on the number of secrets and the number of API calls. Teams with many secrets and frequent reads should pay attention. If every Pod pulls its config at startup, the total climbs faster than intuition suggests. A cache layer or Parameter Store in front of the secret is the usual way to absorb some of those calls, which is a common pattern for anything priced per request.
The fit is specific: one cloud, identity already in IAM, and no appetite for buying a separate secrets product. If half your services run on Alibaba Cloud or in your own rack, the fit disappears quickly.
1Password and Bitwarden: grown out of password managers
The logic is easy to follow. The team already uses 1Password for logins, so letting machines read the same store sounds like a short step.
1Password’s Secrets Automation provides service accounts and a CLI, and CI jobs call op to fetch values. There is also a Connect service that can be self-hosted to route requests into the private network. Bitwarden’s Secrets Manager is a separate product priced by machine accounts and seats, usually cheaper than comparable tools and friendly to teams that prefer open source.
The advantage is habit. People already use it, onboarding is close to zero, and the interface is built for humans rather than for auditors reading a stream of logs. Telling a new colleague to look in 1Password requires no training.
The limit is the model. These tools are built around stored secrets. There are no dynamic credentials and no policy engine that goes down to a single key. By the time a team has dozens of people and needs to separate who reads production, who reads staging, and who can read a key without seeing its value, the available options run out. They are a good starting point, not always the destination.
SOPS: no server, ciphertext in Git
SOPS is a different species. It is a command line tool, not a service. It encrypts the values in YAML, JSON, and ENV files while leaving the keys in plaintext, so the encrypted file can be committed and the diff remains readable.
The encryption key can be a cloud KMS key from AWS, GCP, or Azure, or an age or PGP key. Who can decrypt depends on who holds permission on that KMS key. The file records which key was used, so rotating the key does not require editing each file.
The upside is zero infrastructure. No server, no availability, no backups, and no incident where the platform is down and nobody can deploy. Mozilla started the project, it is under MPL 2.0, and the community keeps it maintained.
The downside is the same property. No UI, no access log, no record of who read what and when. Rotation means re-encrypting every file, committing again, and walking through review again. With a large team, KMS permissions as the only gate are too coarse.
It fits where configuration already is code and the team reviews everything in Git, ideally with a GitOps flow: cluster manifests, Terraform variable files. In that setting SOPS is close to perfect. Asking it to also handle access control and audit is using the wrong tool.
Four dimensions, side by side
Feature lists mislead, because every tool claims environment separation, CI integration, and audit. What actually decides a purchase is four harder things: how you pay, where the data sits, who owns the code, and whether it plugs into the workflow you already have.
The table below compares only those four. Pricing is described by model rather than by number, since vendors change prices often enough that a fixed figure becomes misinformation within a quarter.
| Tool | Pricing model | Deployment | License | Integrations |
|---|---|---|---|---|
| Infisical | Free to self-host from source, cloud tiered by seats and features | Cloud or self-hosted | Core open source, enterprise features licensed separately | CLI, SDKs for major languages, Kubernetes Operator |
| HashiCorp Vault | Open source edition free, enterprise quoted by node and seat | Mostly self-hosted, hosted service available | BSL 1.1 for Vault, MPL 2.0 for OpenBao | HTTP API driven, pluggable auth and storage backends |
| Doppler | Tiered by seats and projects, free tier available | SaaS first | Closed source | CLI, SDKs, integrations for common CI systems and platforms |
| AWS Secrets Manager | Priced by secret count and API calls | Managed by AWS | Closed source | IAM, Lambda rotation, AWS SDKs |
| 1Password Secrets Automation | Bundled with the team subscription | SaaS plus a self-hostable Connect service | Closed source | CLI, service accounts, CI integrations |
| Bitwarden Secrets Manager | Priced by machine accounts and seats, free tier available | SaaS, self-hosting also possible | Core open source, some features licensed separately | CLI, SDKs, CI integrations |
| SOPS | Free | No service, local command line | MPL 2.0 | KMS, age, PGP, used with Git workflows |
There is no security column, and that is deliberate. At this level the encryption is not the weak part. Usage is. A Vault with permissions configured badly is more dangerous than a SOPS setup that is used correctly.
How to choose, based on the team you have now
After all of that, four questions cover most of the decision.
Do secrets need to leave your network. If a regulator or a customer contract says no, every SaaS option is out. What remains is self-hosted Infisical, Vault or OpenBao, self-hosted Bitwarden, and SOPS.
Is anyone willing to be on call for it. When a secrets system fails, deploys stop. If nobody can say “I own this”, a managed service you do not operate is a more responsible choice than the most capable self-hosted system.
Do you need dynamic credentials. If yes, the list narrows to Vault and OpenBao, because everything else stores static values. If no, do not pay for the complexity.
Would you rather spend money or time. SaaS bills monthly and the invoice is clear. Self-hosting saves cash and spends people. Small teams routinely underestimate the second cost.
One more item gets overlooked: migration. Moving secrets systems is not changing an API address. You rewrite how every service reads its values, rewrite CI configuration, and keep all of it correct during the most tense days of the project. Do it once, properly, or leave the current setup alone. Half-finished migrations leave two systems running in parallel, which is the worst state available.
Back to that Wednesday afternoon
Suppose the opening scene belongs to a real team. Their fix is small. Move the .env file out of chat and into one place. Give each environment an address and each person an account, instead of handing out a file. Add one line to the offboarding checklist: revoke secret access.
Which tool they pick matters less than the change in the question. From that day on, “where is the production config” has exactly one answer.
Tool selection gets written up as a feature matrix, but the thing that keeps people awake is rarely a missing feature. It is the memory, arriving at midnight, that someone who left six months ago may still carry a text file that opens the production database.
Which tool you choose depends on how long you want to keep thinking about it.
Related reading
- OpenObserve vs SigNoz: Which Self-Hosted Observability Stack Fits a Small Team?
- Sim vs n8n vs Dify: Which AI Agent Workflow Builder Fits a Small Team in 2026?
- Notion Alternatives 2026: Coda vs Slite vs Confluence vs Guru for Your Team Wiki
Stay updated with our latest AI insights
