Vendoring vs Module Proxy — When Each Makes Sense
Default: module proxy wins
For most projects GOPROXY=https://proxy.golang.org,direct is correct and you should leave it alone. The proxy caches immutable versions, your CI gets reproducible builds without a vendor tree committed to git.
When vendoring is worth it
- Air-gapped build environments with no proxy access.
- Projects where you need to patch a dependency without forking it publicly.
- When you want a single
git cloneto be self-contained for auditors.
The -mod=vendor trap
If you commit a vendor/ directory, Go will use it automatically in module-aware mode (Go 1.14+). But if go.sum drifts from the vendor tree — e.g., after go get -u without re-vendoring — you get confusing errors. Always run go mod vendor immediately after any dependency change.
Hybrid approach
Keep the proxy as default, vendor only the dependencies you patch. Use replace directives in go.mod to point at the local vendor path. Clean and auditable.