In our CI setup we ended up fixing it like this (which I still consider very hacky though): git config --global url.https://our-new-domain.com/.insteadOf h

In our CI setup we ended up fixing it like this (which I still consider very hacky though): git config --global url.https://our-new-domain.com/.insteadOf https://gitlab.com/ This allowed us to keep our code unchanged and still be able to build it on different CI servers (e.g. our public as well as private instances). Specifically, for Gitlab our replacement config looks like this: git config --global url.https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_HOSTNAME}/.insteadOf https://gitlab.com/ This assumes that all packages hosted on gitlab.com are available on our local Gitlab instance, which can be problematic as well (for example if we would import/use an open-source package hosted on gitlab.com along with our own code). In that case we would need a replacement config that would only match our groups/namespaces on gitlab.com. I vastly prefer the Rust way of doing things though, as I don't think using domains as a namespace is a good way. For example, most code hosting sites will shut down or be deprecated eventually (possible even Github at some point), which for Go will lead to a lot of headaches since there's no way to know where a given package will end up when it's no longer available at its original location.