How can `go mod tidy` download from the same domain but with different access tokens?

Hello, we are having a bit of an issue with go get with our own repository.


We are using two packages that we have hosted in our GitLab. Both packages are in different repositories, although they share the same domain.

  • Module 1 is at
  • Module 2 is at

Then, we have a go.mod file that requires both of them, like this.


go 1.20

require ( v0.0.0 v0.0.0

Each repository has a GitLab Deploy Token which grants read access to the code (so it can be cloned). In order for go get to use them, we are using the .netrc as explained here.
This works fine for a single repo/package. In the .netrc you add the user and token for the domain, and go get can download the package.


This works fine for a single package. However, when doing go mod tidy, you have to download both packages as specified in the go.mod (when they are not cached). The problem is that for private repos, go get will look for the domain in the .netrc, however, we have two modules with the same domain but different user and token. Therefore, go mod tidy fails, because it doesn’t know what user/token to use for each package, as it just considers the domain.


machine login module1_user password module1_token
machine login module2_user password module2_token

Both module1 and module2 are at but in different repos there.

Right now, the only way we were able to workaround this, was: by setting user1/token1 in the .netrc, then doing a go get for module1. Then, overriding for user2/token2 and go get for module2. This saves the packages in the cache and doesn’t need to be downloaded by the go mod tidy.

This approach is not ideal, as the go mod tidy cannot be done directly, you need to do the other steps first. It not only adds complexity, but it is also less secure as the user/tokens have to be outside the .netrc.

Question: Is there any way of avoiding this behavior, and telling go mod tidy/go get which user/token to use per package instead of domain?

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.