Infisical/infisical

What it does

You put secrets in it, organised by project and environment. From there it pushes them where they are needed, with published connections to code hosting, hosting providers and cloud accounts, so a changed password does not have to be copied by hand. Every secret is versioned, so a bad change can be rolled back to a known point. It can rotate secrets on a schedule and create short-lived ones that expire by themselves. A Kubernetes component and a separate agent inject secrets into running programs, so nothing has to read a file. Beyond secrets it manages certificates, with its own certificate authority or an external one, several enrolment methods, and code signing. It manages encryption keys. It also grants temporary access to systems such as PostgreSQL, SSH and Kubernetes, records the sessions, and rotates the credentials afterwards. Its command-line tool scans for over 140 kinds of secret, which is how you find the ones already committed. The newest release is v0.166.6, from 13 October 2026, and code landed today, from 29,254 commits. What is not in the free part is the ee folder, which holds paid features and needs a licence key, and the self-hosted enterprise offering, which the project asks you to arrange by meeting.

Why it matters

Who it suits. Any team past the point where secrets live in a chat history, and especially any team with a compliance question to answer about who can reach what. The scanning tool is useful even to people who adopt nothing else, because it finds keys already committed to a repository. The temporary-access part suits anyone who has given out a database password that was never changed afterwards. Skip it if one person runs everything and a password manager already covers it, because this is a service to operate.

Verdict. The most actively developed project in today's twelve, with a release yesterday and code today, and the thing to read carefully is the licence boundary rather than the feature list. MIT with a carved-out ee folder means running it free is fine and the paid features are visible in the repository, which is clearer than most arrangements of this kind. What the project does not publish is a plain list of which features are enterprise-only, so check that before building a plan around any single one. Size it generously: a secrets store that is unavailable stops deployments, so this is the kind of service to run with a backup and a restore you have tested. getsops/sops at 23,300 stars is the much simpler alternative under MPL-2.0 and solves a narrower problem well: it encrypts files in place so secrets can be stored in a repository, with no service to run at all. dani-garcia/vaultwarden at 67,400 stars is the choice when the secrets belong to people rather than to programs, and Edition 29 covered it.