Skip to main content
If your code host enforces an IP allowlist, permit traffic from Gitar’s public addresses. That covers a self-hosted instance behind a firewall, and a cloud instance with allowlisting turned on, such as GitHub or GitLab organization-level IP restrictions. For GitLab.com, allow all three IPv4 addresses and the IPv6 range below. Adding only IPv4 can leave project access and webhook registration blocked. Every outbound request Gitar makes leaves from these, including connection validation, repository clones, pushes, webhook registration, and code host API calls.

IPv4

Outbound IPv4 is translated to one of three addresses, one per availability zone:
Add all three. Gitar spreads work across availability zones and fails over between them, so an allowlist holding a subset breaks intermittently rather than cleanly.

IPv6

If your host publishes AAAA records, Gitar may reach it over IPv6. That traffic is not translated, so the source is the individual task’s address rather than one of the three above. Allow the whole range:
An IPv4-only allowlist is not sufficient for a host that supports IPv6. Blocked requests can time out or return an access error. GitLab can return 404 Project Not Found for project and webhook requests even when the same token can list projects and has Owner access to their group.If you would rather not allow the range and you control the hostname’s DNS, removing its AAAA records keeps Gitar on IPv4. That withdraws IPv6 from every other client of that hostname too, so it is not free.On a hosted code host you do not control those records, so allowlist the range. Organization and group-level allow lists on GitHub and GitLab take CIDR ranges only, so there is nothing narrower to scope there. Behind your own firewall you can also restrict to the ports your host serves.Gitar has no setting to force IPv4.
The IPv4 addresses are stable. They are Elastic IPs, held independently of the instances that use them, so they survive instance replacement and routine maintenance.The IPv6 range is the prefix assigned to Gitar’s production network rather than a separately held address, so it carries a weaker guarantee. We do not expect it to change, and will announce it here and in the release notes before it does. Watch those if your allowlist depends on this range.Both apply to every supported code host: GitHub, GitLab, Azure DevOps, and Bitbucket, and both are production-only. Gitar’s staging environment egresses from a different set, which is not customer-facing.