Vault — Dependencies#

Module info#

• Module: github.com/hashicorp/vault
• Go version: go 1.26.1
• Direct dependencies: 210
• Indirect dependencies: 336 (total unique module/version pairs in go.sum: ~965)
• Replace directives: 7 (5 for in-repo submodules; 2 for upstream bug workarounds)

Dependency categories#

Core HashiCorp ecosystem#

Vault is built almost entirely on HashiCorp’s own library stack. These are foundational:

Consensus / High-Availability Storage#

Vault’s integrated storage (Raft mode) is the default HA backend since Vault 1.4:

Plugin System#

Vault’s plugin architecture is explicit in go.mod — all built-in plugins are imported as direct module dependencies even though they run as separate processes via go-plugin:

Key Management / Encryption#

Vault’s seal/unseal and transit engine depend on a layered wrapping abstraction:

Cloud SDKs#

Cloud coverage is one of Vault’s defining dependency characteristics — every major cloud needs auth methods and secret engines:

Storage Backends#

Vault supports ~10 different physical storage backends; each requires its own client library:

Authentication Protocol Libraries#

Auth methods require low-level protocol libraries not covered by cloud SDKs:

Networking / Transport#

Observability#

HCP (HashiCorp Cloud Platform)#

Testing#

Other Notable#

Stdlib reliance#

Vault leans heavily on stdlib for its core plumbing. In the vault/ core package alone:

• context — 162 usages (request lifecycle, cancellation, deadline propagation)
• fmt — 127 (error formatting, debug output)
• time — 92 (lease TTLs, token expiry, TOTP windows)
• sync — 61 (mutexes, RWMutex, WaitGroup, Once across cluster state)
• encoding/json — 30 (HTTP API serialization)
• net/http — 27 (HTTP server and client)
• crypto/* (tls, x509, rand, sha256, hmac) — 25+ (TLS configuration, certificate handling, HMAC seals)

The stdlib crypto packages are treated as authoritative for anything not requiring cloud-KMS integration. Third-party crypto (tink, ProtonMail, x/crypto) is additive rather than replacement.

Shared dependencies#

Dependencies shared with other projects in the analysis set (Consul P12, and broadly across HashiCorp tools):

Vendoring#

Vault does not vendor. The module cache (via GOMODCACHE / GOPROXY) is relied upon at build time. Given the 210+ direct dependencies, vendoring the full tree would be impractical to maintain. The CI/CD pipeline uses a module proxy (likely proxy.golang.org or an internal proxy). The 7 replace directives serve two purposes:

1. In-tree submodule development: vault/api, vault/api/auth/*, and vault/sdk are developed in the same repository but published as separate modules. replace allows them to be tested together before release without a publish step.
2. Upstream bug workarounds: The github.com/99designs/keyring → github.com/Jeffail/keyring replace is explicitly documented — keyring has a zombie dbus-daemon bug triggered transitively via gosnowflake. The signedxml replace pins a moov-io fork.

Notable dependency decisions#

HashiCorp’s internal library stack vs. community alternatives: Vault uses hashicorp/cli instead of cobra, hashicorp/go-hclog instead of zap or logrus, and hashicorp/hcl instead of viper. This is a deliberate HashiCorp philosophy — own your toolchain. This creates tight coupling within the HashiCorp ecosystem but avoids external breakage.

Dual AWS SDK versions: Both aws-sdk-go (v1) and aws-sdk-go-v2/config appear as direct dependencies. V1 powers legacy components (IAM auth, S3 backend) that have not been migrated; v2 is used for newer services (RDS IAM auth). The coexistence adds ~3MB of binary bloat and is a known tech debt item common to large AWS-dependent Go projects.

All plugins compiled in: Unlike a true dynamic plugin system, Vault’s built-in plugins are compiled into the main binary as direct Go imports (the same binary is then extracted and re-executed as a subprocess by go-plugin). This means the main module’s go.mod accumulates the transitive dependencies of every built-in plugin — explaining much of the 210-dep count. A microservices or separately-compiled plugin model would dramatically reduce the core module’s dependency footprint.

KMS wrapping abstraction: The go-kms-wrapping family (7 wrappers) is a textbook dependency inversion: Vault’s seal subsystem depends on an interface (Wrapper), and each cloud KMS is a separate module satisfying that interface. This lets users avoid compiling in all cloud SDKs — but the current monorepo approach imports all of them anyway.

No Viper for configuration: Despite Viper being almost ubiquitous in Go CLIs, Vault uses hashicorp/hcl directly for its configuration files and hashicorp/go-secure-stdlib/parseutil for individual values. This is intentional: HCL provides richer syntax and clearer error messages for operator configuration than TOML/YAML-based Viper.

pkg/errors present but fading: github.com/pkg/errors appears as a direct dependency (used in some older packages), while newer code uses fmt.Errorf with %w. This mixed usage is typical of a codebase that predates Go 1.13 error wrapping but is gradually migrating.