# Vault: a secrets repository whose README is a contributor build guide

> hashicorp/vault is the Go server for secrets management, encryption as a service, and privileged access management, where every secret carries a lease and can be revoked as a tree. What the repository gives you in writing is how to build and test the server from source, not how to install or run it, and the license identifier in the Dockerfile header does not match what the repository metadata asserts.

**hashicorp/vault** — A tool for secrets management, encryption as a service, and privileged access management

- Repository: https://github.com/hashicorp/vault
- Website: https://developer.hashicorp.com/vault
- Stars: 36,300 · Forks: 4,762
- Language: Go
- License: NOASSERTION
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/hashicorp-vault

## Every command here builds the server, none of them install it

The commands in this repository assume a contributor setup and say so. Go must be installed, a GOPATH configured, and GOBIN pointed at the right place, with that directory on the path because some distributions ship older build tools. The repository also tells you to clone outside the GOPATH, since Vault uses Go Modules. After that the sequence is short:

```sh
$ make bootstrap
...
$ make dev
...
$ bin/vault
...
```

There is no package install, no checksum line, and no upgrade instruction anywhere in the file. A reader looking for the current release binary finds no command that fetches one, and the project routes them to the documentation site instead. That is a deliberate division of labour, but it means the repository cannot answer the two questions an operator asks first, which version to run and how to verify what you downloaded.

## make test needs Docker, and a single package at a time

The test target has a hard external dependency stated in the text: Docker must be installed, and the check is that the command exits with status 0. The Makefile shows what that target is actually made of. Package lists are generated per module with go list and filtered with grep to drop vendor directories, and the default test set excludes anything matching integ/. Timeouts are set as variables, with a 45 minute default, 60 minutes for extended runs, and 120 minutes for integration tests. Narrowing the scope is done by assigning the TEST variable rather than by passing a flag:

```sh
$ make test TEST=./vault
...
```

The consequence is that a contributor on a machine without Docker cannot run the suite at all, and one slow integration package can consume a two hour budget before anything else executes.

## The build reads its Go version out of a file

Version and build switches are spread across a file and a set of variables rather than a single config. The Go version comes from a file at the root, read by the Makefile as GO_VERSION_MIN and passed into the container build as a build argument. The Go command itself defaults to `GO_CMD?=GOWORK=off go`, so workspace mode is switched off deliberately even though go.work and go.work.sum exist in the root. CGO is off unless something turns it on, with the FDB_ENABLED variable setting CGO_ENABLED=1 and adding a foundationdb build tag, and BUILD_MINIMAL adding a minimal tag for a core-features-only server. The release path is a bin target that runs scripts/build.sh with the tags `ui` appended. Every one of those is an environment variable, so two builds from the same commit are not guaranteed to be the same binary unless you pin them.

## Every secret carries a lease, and revocation works on trees

The mechanism that distinguishes Vault from a key/value store is described in five bullets and the fourth and fifth are the interesting ones. Each secret is associated with a lease, and at the end of that lease Vault revokes the secret automatically, while clients renew through built-in renew APIs. Revocation is not limited to one value: it can take a tree of secrets, for example everything read by a specific user, or everything of a particular type, and the stated purpose is key rolling plus locking a system down after an intrusion. Dynamic secrets follow the same lifecycle, since a generated AWS keypair with permissions on an S3 bucket is revoked once its lease is up. Two things are worth noticing for a reader. The tree semantics mean revocation has a blast radius you choose, and the file describes no failure behaviour for a client that cannot renew in time.

## go.mod declares the module should not be imported, then replaces seven paths

The module file carries a policy comment and a set of rewrites at once. The declared version is a specific patch release:

```go
go 1.27.1

replace github.com/hashicorp/vault/api => ./api
```

and the comment above it states that the vault module is not intended to be imported into other projects, that the go directive is not consulted when building production binaries, and that sdk/go.mod should be updated whenever the value changes. Alongside that sit local replacements for the api package and three of its auth subpackages, plus internalshared, sdk, and version, so a build inside the repository always compiles against the checked out code rather than a published module. Two dependency rewrites are not local. keyring is pointed at a fork as a documented stopgap for a bug that leaves zombie dbus-daemon processes on each execution, and signedxml is replaced with a different maintainer's fork.

## BUSL-1.1 in the build file, nothing asserted in the metadata

Licensing here needs a reader with access to more than one file. No single identifier was extracted for this repository, so the license field reads NOASSERTION, while a LICENSE file sits in the root. The Dockerfile that builds the binary opens with its own header, copyright IBM Corp. 2016, 2026, and an SPDX identifier of BUSL-1.1, and the go.mod comments show the same careful attention to what is asserted when. For most consumers this is a detail that surfaces late, at the point where a legal review asks which terms apply to a redistributable binary, a container image, or a vendored copy. The consequence of the split is simple: read the LICENSE file and the file headers rather than relying on the repository summary, and get the answer in writing before you build a distribution on top of it.

## The documented container build targets s390x with enterprise tags

The Dockerfile documents its own reproduction path in comments, starting with the builder image and its build argument:

```sh
docker build -t builder --build-arg GO_VERSION=$(cat .go-version) .
```

The run step that follows is long, and it is not a development build. It passes a GitHub token, sets `GO_TAGS='ui enterprise cgo hsm venthsm'`, selects `GOARCH=s390x` and `GOOS=linux`, and ends in `make ci-build`. Two further lines show how to share the Go module cache and the local tool binaries as volumes so they are not downloaded each time. The base image is ubuntu:focal, chosen because its glibc is old enough for the supported distributions that require CGO. Note the version value in that example, 1.20.0-beta1, which is well behind the current release line, so copying the command verbatim reproduces an old version string. The command also requires a token and the toolchain, so it is a maintainer path, not an install path.

## The documentation lives in a different repository

The README is explicit that the documentation source is a separate project, hashicorp/web-unified-docs, and the website directory in this repository is not where the published guides are written. That has a second effect: this repository contains no configuration, policy, or install documentation to read offline. What it does contain is operational history, split into CHANGELOG.md alongside CHANGELOG-v0.md, CHANGELOG-v1.10-v1.15.md, and CHANGELOG-pre-v1.10.md, so a change that predates 1.10 lives in a file named for that range rather than in the main log. Supporting infrastructure sits around it too, with buf.gen.yaml and buf.lock for protobuf generation, a .golangci.yml, .yamllint, scan.hcl, .copywrite.hcl for copyright headers, a META.d directory, a make.bat for Windows, and a website directory. If your question is how to configure a secret engine or an auth method, none of these files answers it.

## Conclusion

Vault fits teams that want credentials issued on a lease and revoked in bulk, and that are prepared to treat a versioned server binary and a sealed storage backend as operational infrastructure rather than a library. It does not fit a team looking for a quick install line, because the repository documents a source build and sends installation to the website. Before you build on it, settle three things the repository leaves open: which license terms apply to your distribution, since the Dockerfile header and the repository metadata disagree, what your unseal and recovery procedure is, and which build tags your deployment actually needs, since minimal, foundationdb, and the enterprise set are all switched on by environment variables rather than a single config file.

## FAQ

### What is vault used for?

Vault is a tool for securely accessing secrets, and the project describes it as covering secrets management, encryption as a service, and privileged access management. It stores arbitrary key/value pairs, generates dynamic credentials for systems such as AWS or SQL databases, encrypts data without storing it, and records a detailed audit log.

### how to install vault

The repository does not contain a command that installs a released Vault binary. It covers building from source: install Go, set up a GOPATH, point GOBIN at $GOPATH/bin, clone the repository outside the GOPATH because Go Modules are used, then run make bootstrap and make dev, which places the binary in the bin and $GOPATH/bin folders.

### how to install vault cli

There is no separate CLI to install in this repository. The `vault` binary produced by make dev is the command line tool, and full installation instructions are published on the Vault documentation site rather than in the repository.

### how to use vault

The repository points to the Getting Started guides on HashiCorp's learning platform, to the documentation at developer.hashicorp.com/vault/docs, to the vault-examples repository for per-language integration samples, and to a sample application called hello-vault-go. The core model is that each secret is leased, renewed through built-in renew APIs, and revoked automatically when the lease ends.

## Sources

- [Official documentation](https://developer.hashicorp.com/vault)
- [Official README](https://github.com/hashicorp/vault#readme)
- [Project repository](https://github.com/hashicorp/vault)
- [Release notes](https://github.com/hashicorp/vault/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hashicorp-vault