Allowlist your gateway IP on GitHub
GitHub's IP allow list limits access to an organisation's resources — web UI, API and Git over HTTPS/SSH — to addresses you list. It's an Enterprise Cloud feature; Free, Team and Pro organisations don't have it. With a Reach gateway IP, the list is one entry per region.
Add the gateway IP
- Organisation → Settings → Authentication security.
- In IP allow list, enter the gateway IP in CIDR form (
203.0.113.10/32), add a description such asTYO Reach gateway, click Add. - Repeat for each gateway region your team uses.
Catch-all ranges such as 0.0.0.0/0 are rejected.
Enable enforcement
Only after the entries exist: tick Enable IP allow list and Save. Enforcement is immediate, though caching can take a few minutes to settle. From that point, members not routed through Reach get an access-denied page and failed API/Git calls.
GitHub Actions, Apps and Codespaces
- Actions: GitHub-hosted runners use changing IPs and will be blocked. Use self-hosted runners (or larger runners with static IPs) and add their addresses.
- GitHub Apps: turn on Enable IP allow list configuration for installed GitHub Apps so apps' published IPs are added automatically.
- Codespaces: enabling an allow list disables Codespaces for the organisation's repositories.
Git over SSH
SSH is checked too. Point Git at the local SOCKS proxy so pushes and pulls exit via Reach
— see Use Reach with your terminal for the
ProxyCommand snippet.
Common questions
We're on GitHub Team, not Enterprise — what can we do?
Nothing IP-based on GitHub's side. Require 2FA and SAML SSO where available; the gateway IP still helps with other tools' allowlists.
Does the allow list affect public repositories?
Only actions on the organisation's resources. Anonymous reads of public repos aren't blocked.
Enterprise-level vs organisation-level lists?
An enterprise account can define one list for all its organisations. Organisations can then add their own entries on top; the same gateway IP goes in either place.