Vendoring copies the source of every dependency into your repository, so builds do not need the network or the module cache. In Go, go mod vendor creates that directory. It buys offline, reviewable builds at the cost of larger diffs and an extra step on every update.
What the command creates
The Go modules reference says go mod vendor constructs a vendor directory in the main module's root containing copies of all packages needed to build and test packages in the main module. It also writes vendor/modules.txt, listing the vendored packages and the module versions they came from.
If go.mod has changed since modules.txt was generated, the go command reports an error, and you must run go mod vendor again.
How the build uses it
By default, if the go version in go.mod is 1.14 or higher and a vendor directory exists, the go command acts as if the vendor mode flag were set. In that mode it does not use the network or the module cache.
To force it, pass -mod=vendor. To turn it off, use -mod=readonly or -mod=mod.
The docs also note that go get does not work differently when vendoring is enabled. Updating is still go get followed by go mod vendor.
Reasons to vendor
- Air gapped or restricted builds. No download is needed at build time.
- Availability. A deleted upstream repository or a proxy outage cannot break a release build.
- Reviewable changes. Every dependency change shows up as source in a pull request.
- Audit trail. You can prove which source you built.
Reasons not to
- Large repositories and noisy diffs. One update can touch many files.
- False comfort. Vendored code is still third party code. Nobody reads thousands of changed lines carefully.
- Process burden. Someone must keep the vendor directory in sync with go.mod, and CI should check it.
- Missed fixes. Copies do not update themselves, so you need active scanning.
If you vendor, add these checks
- In CI, run go mod vendor and fail if the working tree changes. That catches a stale directory.
- Run a vulnerability scan against the module list, not just the source tree.
- Keep go.sum committed alongside.
- Review vendor changes for unexpected new files, such as scripts or binaries.
The tradeoff is the same one other ecosystems face when they commit dependency source: you gain control and give up convenience. Choose it for a reason, such as offline builds, instead of by habit.
Safeguard's SBOM and dependency scanning can read your module list, and a free scan is available at gold.safeguard.sh/scan. For how Go selects versions in the first place, see Go minimal version selection.
Quick check
Does Go use the vendor directory automatically?
Yes, if the go version in go.mod is 1.14 or higher and a vendor directory exists in the module root.
How do I know the vendor directory is stale?
If go.mod changed after modules.txt was generated, the go command reports an error. Run go mod vendor again.
Sources
Last reviewed: 19 October 2026.
