Whitelist IP per repository or whole account

We are using a public repository (GitHub - netbeez/windows) to distribute our software. Once it’s installed, most uses have automatic updates, so once we upload a new release existing installations kick in their updating process.

What I am trying to achieve:
I’d like to be able to test the updating process before opening it to the public. One way to do that would be to restrict access to our repository to my public IP only, do my testing in our office, and once we are ready, open it to the public.

What might seem relevant (but not quite):
I see that the enterprise plan gives you the ability to manage access by IP (Managing allowed IP addresses for your organization - GitHub Docs) but this is only to manage log in access and not repository access.

Is there way to restrict access by IP to the repositories of our account?

If not, is there another way to do the updating process testing before release?

I’m not really sure what your goal is. You say you have an public (presumably open source) repository, so why are you trying to “hide” that repository to test the updating? Why not test it with the repo out in the open?

Alternatively, assuming you’re making a request to GitHub to check for a newer release, you could probably make a local Git repository and point your software to that.

This seems like an XY problem to me so it might help if you shared what the “updating process” is.

@mattfbacon I am sorry, some more context would help to understand what I am trying to do.

Our software runs on the background as a deamon on our users’s machines, and part of that is to check once an hour if there is a new version available on the github repository. If there is, the daemon downloads it and installs it.

So, as soon as I upload a new version, updates will start automatically.

In order to test the update process, before releasing to the general public I was thinking of:

  1. Restrict access to the repository only to my IP
  2. Run the daemon on my machine
  3. Upload the new release on the repository
  4. Test the update process on my machine
  5. If test passes, remove the IP restriction and make it available to the public

I can’t get step 1) working above from what I see.

So, I am asking whether there is a way to achieve 1) above or if there is another way to test my updating procedure with the production repository.


Allowed IP addresses are available with GitHub Enterprise Cloud and GitHub AE only that I am aware
reference link: managing-allowed-ip-addresses-for-your-organization

Additionally the configuration is organization wide not per repository.

Have you considered branching/forking and pointing your test client at the branch/fork you want to proved before merging back.
If you need your branch/fork absolutely hidden from the public world you will need to clone to a repository with ‘private’ visibility.

Thanks @byrneh but the IP whitelisting in the enterprise plan refers to the ability to log into the account and it doesn’t restrict access to the repositories you might have under the account. If it did, it would be good enough to restrict access for a while to the whole repository, do our testing, and open it back up again.

Branching or forking means creating a new repository with a different path name, but if you do that, as you said, you have to point to this new path and by that you really are not testing the release version. We do this testing actually already.

Also, if I make the repository private that’s also not what the production product needs to do its updates (it needs a public repository open to download any new version available).

@pvouzis I think you have misunderstood.
You login into a GitHub User account, there is no concept of logging in to an Organization or Enterprise account as such.
When accessing an Enterprise or Organization the allow list for IP addresses will block access via the web, API, and Git from any IP addresses that are not on the allow list, all authorization credential types, including personal access tokens and SSH keys, are filtered by IP allow lists for all apps, users, and roles.

It is your choice what you do I am just giving you the options and some facts, and there are so many ways this could be handled. I do find your approach strange though.

I am sure some would suggest having packaged release versions that are published and you could then have a lookup/redirection redirection to the current release you consider GA and to be used for auto updating clients, but you also have the option or testing an n+1 release you have published for yourself from the same repository.

Good luck with whatever you decide.

That’s understood. What I was looking for was to put IP restriction to an enterprise/organization repositories (including public ones) for downloading (and any other) purposes, and not the ability to access repositories for management.

I am not following you on this one. Can you elaborate a bit more?

To be clear, what is the problem with publishing the next release publicly and then testing the update mechanism?

Our software runs on the background as a deamon on our users’s machines, and part of that is to check once an hour if there is a new version available on the github repository. If there is, the daemon downloads it and installs it.

So, as soon as I upload a new version, user updates will start automatically, and that’s what I want to avoid by putting the IP restrictions so that I allow only my machine from my IP to access the repo and do the automatic update.

GitHub CLI releases
GitHub Desktop releases
Git releases

I believe the IP allow list filters on all forms of access to the repository as I mentioned, I have not seen any documentation to say it does not apply to a repository set as ‘Public’ visibility, but this is not something I have personally test.

As already mentioned your usage seems unusual, and you would also need to have a fixed Ip address for your client

So your update system is already working? In what way are you testing it then?

This sounds like it’d be a good idea to make the update system configurable. The best way to do it heavily depends on the details of your software, but having a sort of “beta release channel” seems like a reasonable solution: You could make an update available, test it a little more broadly (possibly even invite adventurous users to try and give feedback), and then offer it to everyone. One option might be to use a different URL to look for updates.

I think the confusion here in this thread is around the way you’re using the repository: you’re using it just as a release channel for builds rather than as a repository of source code that includes builds – and so temporarily enabling / disabling access makes sense because nobody is interacting with the repository itself – which is different to how a GitHub repository is typically used (and the reason this functionality doesn’t exist).

The use-case you’re describing sounds like you need pre-releases: a build that can be tested by a subset of users (you) before it is released to a wider audience. Are you in control of the code that performs the auto-updating? GitHub releases can be marked as a pre-release, so the right way to handle this use-case would be to have a flag within your application (e.g: INCLUDE_PRE_RELEASES) which is disabled by default, and the auto-updating code would determine whether or not to install a pre-release based on the value of the flag.

After you have validated a pre-release (by watching the auto-updater install the pre-release update in your test environment that has pre-releases enabled) you would return to GitHub to edit the Release and uncheck the “pre-release” box which would then mean the auto-updating process on all clients would download the update.

An alternative approach would be to have many repositories, each of which represents a release channel (e.g: production, beta, alpha) and your application would accept a link to a repository as a configuration option at runtime (default to the production repository). I would recommend the use of GitHub’s native “pre-release” though, as the ideal release process has no room for error between test and production.

@shrink You got all the points correct! My bad not clarifying how we use github, and I see now why most others were confused in here.

Currently we are following the multiple repositories approach: we build a version with a test repository burned into the updating mechanism, and once it passed testing, we do another build with the production repository.

But, as you can image, this is not ideal because I have to rebuild and it also doesn’t cover the test case that the correct repository is burned into the build. In fact, the reason I am trying to figure out a way to test this, is because in our last release we build the production version with (what we though) the release repository burned in, and then we realized that the build process was broken and the repository wasn’t burned correctly into the release.

I am in control of the updating code.

I looked into the prerelease and we might follow that road.

It sounds like the closest we can get, but that also suffers from the fact that you can’t really test if the updater checks correctly the prelease flag (how do you safely test that an unchecked prerelease does what it’s supposed to do?)

That why I was looking at the IP restriction: In that case we can take the repository down for the time we need to do our testing with the exact same code we are about to release, and once we confirm that that works, we can open it to the world.