If you have a handful (say less than 10) repos, the article is right – Vault is an overkill. You can and should just check-in encrypted secrets with git-crypt o

If you have a handful (say less than 10) repos, the article is right – Vault is an overkill. You can and should just check-in encrypted secrets with git-crypt or SOPS. Whenever master enc/dec keys are rotated, you can afford to make a dozen PRs and commits. Note here - I'm not talking about rotating revoked secrets. I'm taking about the master key rotation. If you have hundreds of repos, the mere fact of "rotating" all secrets when the master key changes is a laborious task. Opening, tracking and waiting for hundreds of PRs to be merged, with stuff failing for unrelated reasons to secrets (random unit test or PR check failures, etc) will take months. https://12factor.net/config https://12factor.net/config – this exists for a reason. Your PR checks have nothing to do with production secrets. Your code is compiled with Java/Go/Node/whatever and is published as an artifact, and this also has nothing correlated to secrets nor configuration. You should be able to run the same artifact (docker image or jar or whatever) – with different configurations and secrets for different environments. While the article is good and technical, it skips over these parts. If you're just doing a toy service with no regard for anything of the above, then yeah, by all means just use SOPS and don't bother with vault. But if you're an organization, then don't read this assume that this works for 100s of services & engineers with differing CI/CD practices and schedules, and no luxury time to wait hours for a key=value change or waiting months for a full rotation.