Don't couple your Go code to GitHub
Points and comments are a snapshot, not live.
Using a custom domain for Go import paths decouples code from a specific git hosting provider.
Iain Cambridge argues that coupling Go module paths to hosting services like GitHub creates a migration problem: moving to GitLab or Azure DevOps requires changing every import path. He advocates using vanity domains (e.g., go.iain.rocks, go.uber.org) so the domain remains stable while the underlying git host can change. He provides an Nginx config and an index.html with go-import meta tags to redirect the Go tool to the actual repository, while human visitors get a permanent redirect to GitHub. He considers this essential for commercial teams to avoid unnecessary infrastructure coupling.
What commenters are saying
Commenters split into two camps: those favoring custom domains for flexibility and those noting the operational overhead and risk of domain expiration for open-source projects. Several point out that vendoring dependencies (go mod vendor) already solves the availability problem without custom domains. Others argue that migrating a large Go codebase is genuinely hard because different projects depend on different library versions, making search-and-replace insufficient. Some note that GitHub is effectively permanent for most projects, while personal domains may vanish if bills go unpaid. Several recommend internal module proxies as an alternative.