Stop coupling your Go imports to GitHub
Original: Don't couple your Go code to GitHub
Why This Matters
Vendor lock-in through import paths is a hidden operational cost most Go teams don't price in until it's too late.
Go developer Iain Cambridge argues that using github.com paths directly in import statements locks teams to a single hosting provider. The fix: a custom domain like go.iain.rocks that redirects to whichever git host you use, leaving import paths unchanged if you ever migrate.
Go's import system doubles as a fetch mechanism — 'import github.com/user/repo' tells the toolchain exactly where to pull code. Convenient, but it hard-wires your codebase to a specific hosting provider. Move from GitHub to GitLab and every import path in every dependent project breaks.
Cambridge cites a real-world case where a company ended up running GitHub, GitLab, and Azure DevOps simultaneously because migrating import paths was too costly. Paying for three platforms at once was apparently cheaper than the engineering effort to fix the coupling — a situation he describes as paying real money for a structural mistake.
The fix is straightforward. Set up a vanity domain (e.g., go.iain.rocks) that serves an HTML page containing a 'go-import' meta tag pointing at the actual repo. The Go toolchain reads that meta tag on fetch; human visitors get a 301 redirect to the GitHub page. Move to GitLab later and only the server config changes — every import path in every project stays identical.
Cambridge shares a working Nginx config and a minimal HTML template to implement this. Major projects like Uber's and MongoDB's Go packages already follow this pattern with go.uber.org and go.mongodb.org. His conclusion: any commercial team shipping Go code should treat a custom import domain as a baseline engineering decision, not an optional nicety.