Vault

What it is

Vault is a secrets management and data protection tool: it stores, brokers, and rotates credentials, API keys, certificates, and encryption keys so they don't end up hardcoded in config files or CI pipelines. It's listed here under "Provisioning" because a large chunk of its real-world use is dynamic secret generation — issuing short-lived database credentials, cloud IAM tokens, or TLS certs on demand rather than provisioning static ones. Beyond that, exact positioning/description isn't publicly available from the data we have, so take the category label with a grain of salt if you're evaluating it purely as a provisioning tool — it's broader than that.

Who builds it and why

35,858 GitHub stars and 1,617 contributors on a Go codebase points to a large, active open-source community layered on top of a commercial vendor (HashiCorp originally, though corporate backing details aren't confirmed in the data provided). Founding date isn't publicly available here, but this is a mature, widely-adopted project, not an early-stage bet. The contributor count and cadence (last commit July 2026) suggest ongoing active development rather than a project coasting on past momentum.

Production readiness signal

• Release cadence: Latest release is v2.0.3 — a major version bump from the 1.x line most engineers know, which means anyone running older Vault should budget time for upgrade/migration testing, not a drop-in update.
• Commit activity: Last commit dated 2026-07-01 — actively maintained, not abandoned.
• Contributor base: 1,617 contributors is a healthy, distributed maintainer pool — reduces single-point-of-failure risk on the project itself.
• License: Listed as NOASSERTION, which means the license isn't clearly detected/declared in the repo metadata. Don't assume this is Apache 2.0 or MPL just because that's historically been true for Vault — verify the actual LICENSE file and any BSL-style restrictions before you adopt it in a commercial product, especially if you're building a competing service on top of it.
• CNCF maturity: Not publicly available — Vault has historically not been a CNCF project (it's HashiCorp-governed), so don't expect graduation-level governance guarantees here.

Net: technically mature and battle-tested in the wild, but the licensing ambiguity is a real diligence item, not a footnote.

Who should use this

Teams that need centralized secrets management across multiple clouds or hybrid environments, anyone doing dynamic credential issuance (databases, cloud IAM, PKI), and organizations with compliance requirements around encryption-as-a-service and audit trails on secret access. If you're already running Kubernetes at scale and need something more robust than native Secrets objects (which are base64, not encrypted at rest by default), Vault fills that gap well. Platform teams building internal developer platforms who want a single API for secrets across many services are the classic fit.

Who should NOT use this

• Small teams with a single cloud provider: If you're all-in on AWS, GCP, or Azure, native secrets managers (AWS Secrets Manager, GCP Secret Manager) are less operational overhead and integrate more tightly with IAM.
• Anyone allergic to operational complexity: Vault requires unsealing, storage backend decisions, HA configuration, and careful upgrade planning. It's another stateful system to run and secure — running it badly is worse than not running it.
• Teams needing a fully OSS-guaranteed license: Given the NOASSERTION status, if your legal team requires unambiguous open-source licensing for compliance reasons, get clarity before adoption.
• Simple, low-secret-count environments: If you have a handful of API keys and no dynamic credential needs, this is overkill — a simpler secrets store or your cloud provider's native tool will save you operational burden.

Alternatives

• AWS Secrets Manager / GCP Secret Manager / Azure Key Vault — cloud-native, less flexible across providers, but zero infrastructure to run yourself.
• External Secrets Operator + cloud KMS — for Kubernetes-native teams who want secrets synced from cloud providers without running Vault's own infrastructure.
• SOPS + age/KMS — for teams wanting encrypted-secrets-in-git workflows without a running service at all.

Pricing

Core Vault is open source. Enterprise features (advanced replication, HSM integration, certain governance/compliance tooling) are commercially licensed — verify current terms directly, as licensing models in this space have shifted before and the NOASSERTION signal here means you should not assume terms without checking the source.