CI artifacts to use Google Cloud CDN

Oct 25, 2022 · 3 min read
Stan Hu GitLab profile

Over the next month and going forward, requests for GitLab CI artifacts downloads may be redirected to Google Cloud CDN instead of Google Cloud Storage. We anticipate that GitLab CI users may benefit from faster downloads from edge caches closest to your location.

Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

How will this work?

Currently when a CI runner or other client downloads a CI artifact, responds with a 302 redirect to a time-limited, pre-signed URL with a domain of

After this change, the domain will change to

The exception is for requests originating from within the Google Cloud Platform. These will continue to be redirected to Cloud Storage.

When will this change occur?

We expect to start the transition around the end of October 2022. This will be a gradual transition using a percentage-based rollout, so we anticipate that you will see an increasing number of your requests redirected to Google Cloud CDN instead of Google Cloud Storage until all of the requests are served by the former.

You can follow along with the progress of this initiative and raise any questions in this issue. We will post more detailed timelines in that issue as we refine the rollout plan.

How does this change impact you?

Since GitLab CI runners and certain clients automatically handle URL redirections already, we expect that downloads for CI artifacts should continue to work without any action.

We encourage upgrading to the latest version of the GitLab Runner in order to take advantage of the CDN. This feature was introduced in GitLab Runner v13.1.0. If a runner cannot download from the CDN host, it will retry without the CDN and download the artifact directly through

However, if you have a firewall that only allows, you will need to add ( to the allow list.

What do these warning messages mean?

With this change, users may see warning messages in the CI job logs:

read: connection reset by peer

ERROR: Downloading artifacts from coordinator... error couldn't execute GET against<job id>/artifacts?direct_download=true: Get "
read tcp> read: connection reset by peer  id=1234 token=<some token>
WARNING: Retrying...                                error=invalid argument
Downloading artifacts from coordinator... ok        id=1234 responseStatus=200 OK token=<some token>

This error suggests the runner was not able to access the CDN. Check your network firewalls and allow access to the IP

Note that there are two Downloading artifacts from coordinator messages. The second attempt succeeded because the runner retried without the CDN.

x509: certificate signed by unknown authority

ERROR: Downloading artifacts from coordinator... error couldn't execute GET against<job id>/artifacts?direct_download=true: Get " x509: certificate signed by unknown authority  id=1234 token=<some token>

If you see this error with a Windows runner, upgrade to v15.5.0 since it is compiled with Go 1.18, which supports using the system certificate pool.

Otherwise, this error suggests the runner is configured with custom SSL certificates. You may need to update your certificates or include the certificates directly in the bundle.

Authentication required

Some clients may report a 401 error with Authentication required after requesting to download a job artifact:

<?xml version='1.0' encoding='UTF-8'?><Error><Code>AuthenticationRequired</Code><Message>Authentication required.</Message></Error>

This error message suggests the HTTP client is following the 302 redirect and sending the Authorization header with the redirected URL. This is a known issue with Java HTTP clients.

Update your client to drop the Authorization header the redirect. Google Cloud Storage ignores this header if it were set, but Cloud CDN rejects requests that have the Authorization header set.

“ CI artifacts to use Google Cloud #CDN. Find out how this will impact GitLab CI users.” – Stan Hu

Click to tweet

Edit this page View source