Download from Github Package Registry without authentication

This cant be such a big technical challenge.

The problem here is clearly political/strategic

1 Like

Hi, did I understand correctly that users can’t run npm i @foo/bar --registry= without authenticating to github?
I couldn’t make it work on github, but it worked out of the box on gitlab…
If so, why is this marked as solved?!

1 Like

Super annoying. Should not be marked as “solved”

I’m experimenting with this feature for publishing from Maven. Given this restriction, I need to find a different solution. The loss of Jcenter is painful.

1 Like

Tired of this situation, I created a Gradle plugin (magik) which allows to publish directly to a github repository, acting as a maven repository.

Easy, fast, personal and, last but not least, public access.

  1. Build a package, release it on GPR.
  2. Feel excited. Its open source and free.
  3. Get a 401 trying to install without auth.
  4. Feel sad.
  5. Find thread from 2019, probably a solution in the thread.
  6. Get to end (2021) and realize still not supported.
  7. Feel sad.

I can’t believe the packages in the public repo can’t be accessed anonymously. In this way, the open sourced library will not be able to use this service at all.

1 Like

This is really disgusting. I used this when it was launched back in 2019 but saw the downloading also requires authentication, so maybe this shouldn’t be the case after a few months. Then I tried around July 2020 and was surprised to see that it’s still the case. Now, I’m trying in Aug 2021 and still the same.

They should remove this feature for the public completely.


+1. I was excited to use GPR, but this is a dealbreaker. I suppose I’ll have to go with GitLab.


Do we have a timeline for that? Just spent about hours trying to publish library and to find out i did it for nothing.

Any updates on this issue?

I suppose from everyone else already commenting, I don’t need to also make a comment just to register my own disappointment (although I am disappointed), but my question is more (and this is going to sound like a criticism, and I guess it sort of is, but I also mean it in the genuine sense), why was this ever the way it worked? How was anonymous access for public packages not the default? Wouldn’t you have needed to do extra work to make it the more useless way that it currently is?


Such a stupid decision.

1 Like

Most probably the initial use case was to provide company-intern package management. The system “”“works”"" also for public repos so it wasn’t extended further

1 Like

FYI has a free tier for publishing packages that can be accessed anonymously. I’m experimenting with them after finding out this unfortunate restriction.

Also JFrog offers an extensive package hosting system for free. Thats what i went with. I just would prefere using github itself a lot

+1 !!! I would also strongly vote for it. Public access to the maven packages is absolutely required for open source projects. The PAT way can be an additional option. The longer we have to wait for a solution the more people will look for other solutions and maybe even completely leave github (which is sad because generally github is great). I already thought about leaving :frowning:

Same thing there, mate :wink: Tested

Well, I also would need this feature. Not that GitHub cared about the hundreds of messages about this for the last few years :slight_smile:

1 Like

+1 vote for anonymous access to Package Registry for open source projects

With anonymous access to all public packages, GitHub packages would be a brilliant addition to the product. Without it, it’s completely useless to me.

It’s nice and all that workarounds exists, e.g. for NPM. However, luckily the security bot detects such tokens in commits to public repositories and revokes them (good feature :+1:). But even if you trick it by escaping some characters, it still seems dangerous to force people to create and disclose PATs for such a basic use-case (or ever, really). At least one person will select more scopes than read:packages and potentially compromise his account and all repositories he has access to.