Yes. Run go mod vendor to copy the packages your build needs into a vendor directory. When that directory exists and your go.mod declares Go 1.14 or later, the go command uses it by default and loads packages from it instead of the network or module cache.
What the Go reference says
The Go modules reference states that go mod vendor creates a directory named vendor in the main module root with copies of all packages needed to build and test the main module's packages. It also writes vendor/modules.txt, listing vendored packages and the module versions they came from.
If go.mod changed after modules.txt was generated, the go command reports an error until you run the command again. Flags -mod=vendor, -mod=readonly and -mod=mod choose how modules are loaded.
Steps
go mod vendor
git add vendor go.mod go.sum
go build ./...
- Run the vendor command after any dependency change.
- Commit the vendor directory with go.mod and go.sum.
- In CI, add a check that vendoring is current: run the command and fail the job if the working tree changes.
- Build once with the network disabled to prove it works offline.
The proxy fallback option
Without vendoring, the GOPROXY setting is a comma separated list of proxy addresses plus the keywords direct and off. The go command tries the next entry only in documented cases, for example when requests to the first returned 404 or 410. A list such as an internal proxy first, then a public proxy, then direct, gives some redundancy, but it still needs the network somewhere.
Trade-offs
| Factor | Vendoring | Proxy list only |
|---|---|---|
| Builds offline | Yes | No |
| Repo size | Larger | Unchanged |
| Review of dependency changes | Visible in diffs | Only in go.sum |
| Upkeep | Must refresh after updates | None |
| Scanner coverage | Scan go.mod and the vendor tree | Scan go.mod |
Vendored code appears in pull requests, which can help review. It also means a change in a dependency can add thousands of lines to a diff. Many teams agree on a rule: reviewers check the go.mod and go.sum diff, and a tool checks that vendor matches.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how direct and transitive dependencies are listed. A vendor directory should match that inventory exactly.
Safeguard produces an SBOM and scans dependencies, including Go modules, and has a free scan you can try on a repository.
Quick check
Does vendoring remove the need to scan dependencies?
No. Vendored code can contain vulnerabilities just as downloaded code can. Keep scanning.
How do I turn vendoring off for one build?
Pass the readonly or mod value to the mod flag, as the Go reference describes.
Sources
Last reviewed: 19 October 2026.
