Gitlab CI runners public IP addresses (range)

Is there any official IP range for the Gitlab CI runners? I’d like to white-list an IP range which is allowed to connect to my CloudSQL database on Google Cloud Platform. The CI runner is running some Django admin commands that will need remote access to the SQL database during the setup.

Any ideas?


I have the same problem. I setup a test server and tried to deploy to this server. I ran tcpdump while the deployment was doing its thing and analyzed the dumps with wireshark.
The runners public IPs seem to be all over the place, so it looks like it is impossible to whitelist an IP range.

I would be very interested in a solution though. Let’s hope there is a hidden configuration option somewhere or any way to get more manageable public IPs.
I was thinking that some sort of proxy could be helpful, but I am not very confident with my network skills.

I have the same issue for our development servers, our production servers are updated through the AWS cli but our development servers need to be updated with SFTP. I would like to allow an ip-range to use our ssh ports, any updates on this topic?

You’re not alone on this request. Here is a related feature proposal that could use your support.

We’re using hosted service, with shared runners, and three out of four runners fall in the following CIDR: which is:

And the fourth which is “” falls in the CIDR

White listing these two CIDR works for us currently. Not sure IPs changes dynamically / occasionally or not, but it’s working for now. Hope this helps…


Thanks, I just verified that these are still the same with a dig and a whois.

A minor security concern though:

These appear to be public cloud (Digital Ocean) CIDR blocks. I just recommend that if you do whitelist these CIDRs do it in your CI pipeline and close the firewall rules when done.

1 Like

Are these ips still the valid gitlab ips? Didn’t gitlab switch to google cloud recently? Does anyone know?
I’ve tried whitelisting these for our gitlab-ci ssh connection and it is timing out.


You could do a DNS lookup on these endpoints yourself and verify this via a whois on the resulting IPs.

I can confirm that this currently seems unchanged:

 robert > bug/DDPQAI-2189 > … > infrastructure_as_code $ dig +short
 robert > bug/DDPQAI-2189 > … > infrastructure_as_code $ dig +short
 robert > bug/DDPQAI-2189 > … > infrastructure_as_code $ dig +short
 robert > bug/DDPQAI-2189 > … > infrastructure_as_code $ whois | grep -i ^cidr
 robert > bug/DDPQAI-2189 > … > infrastructure_as_code $

Hello all,

It looks like this changed, and shared runners are now being hosed in GCP:


$ while read -r CIDR_RECORD; do 
      dig @ \
          +short TXT "$CIDR_RECORD" | \
              grep -Pow '(\d+\.){3}\d+\/\d+'; 
  done < <(
      dig @ \
          +short TXT | \
              grep -Pow '\_cloud.[^\ ]*.com'

These CIDRS might change again in the future, so it will probably be worth running that while loop when you read this. Note <() doesn’t work in POSIX (/bin/sh) so you would need to output that first dig (the one that the loop iterates over) to a file for the second dig (the one inside the while read loop).

Or you could simply run a bash docker image and use it as written if you don’t have bash locally.


That was useful! Thanks! :smiley:

Hi Robert,
if we’re creating and using our own runner from GitLab how to know the IP, Successful pipeline should hit the server of type CPanel. TO unblock it in firewall need list of IPs’.

Thanks in Advance