Build repositories from GitLab Enterprise Edition in a private network
Stay organized with collections
Save and categorize content based on your preferences.
Cloud Build enables you to create triggers to build from repositories
hosted on GitLab Enterprise Edition,
allowing you to execute builds in response to events such as commit pushes or
merge requests associated with your GitLab Enterprise Edition repository.
This page explains how you can enable trigger functionality on a GitLab
Enterprise Edition instance if your instance is hosted in a private network.
Before you begin
Enable the Cloud Build, Secret Manager, Compute Engine, and Service Networking APIs.
Build repositories from GitLab Enterprise Edition in a private network
If your GitLab Enterprise Edition instance is only accessible within a
VPC network, you need to set up a
Service Directory service and build using private pools. The
project containing your VPC network can exist in a different
project than the one containing your Service Directory service.
Use the following instructions to ensure your instance is reachable prior to
creating triggers:
Ensure you have the Project IAM Admin role granted to the
Google Cloud project you intend to create your
Service Directory service in. To learn how to grant
IAM roles, see
Configuring access to Cloud Build resources.
Set up a Service Directory service by completing the following steps:
If you include a self-signed or private certificate when connecting your
GitLab Enterprise Edition host to Cloud Build, you must set the
host URI as the Subject Alternative Name (SAN) of your certificate.
Your GitLab Enterprise Edition trigger will now automatically invoke builds on
your GitLab Enterprise Edition instance based on your configuration.
Use Service Directory to reach hosts outside Google Cloud
Service Directory uses the IP address range 35.199.192.0/19 to
connect your host outside of Google Cloud. You must add this range to
an allowlist in your firewall. Additionally, your private network needs to be
configured to route this range through the Cloud VPN or Cloud Interconnect
connection.
If your connection uses a Cloud Router, you can configure your connection to
communicate
the range to your private network.
Use Cloud Load Balancing to reach hosts outside Google Cloud
If your network configuration does not allow you to route the
Service Directory IP address range 35.199.192.0/19 to the
Cloud VPN or Cloud Interconnect, you can
create a load balancer using
Cloud Load Balancing that directs traffic to your host.
When creating your TCP load balancer, consider the following:
Only a hybrid connectivity network endpoint group (NEG) is required to reach
your host.
The TCP load balancer does not require the unencrypted private key for your
SSL certificate.
Your Cloud VPN setup needs to use Cloud Router with global
dynamic routing. If your Cloud VPN uses static routing, you can use
a proxy that uses Cloud Service Mesh instead. To learn more, see Set up network
edge services for hybrid
deployments.
The data sent to GitLab Enterprise Edition from Cloud Build helps you
identify triggers by name and see build results on your GitLab Enterprise
Edition repositories.
The following data is shared between Cloud Build and GitLab
Enterprise Edition:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eCloud Build can trigger builds from GitLab Enterprise Edition repositories, even when the instance is within a private network, by responding to events like commit pushes or merge requests.\u003c/p\u003e\n"],["\u003cp\u003eTo enable builds from a private GitLab Enterprise Edition instance, you must set up a Service Directory service, ensure the instance is reachable, and use private pools for builds.\u003c/p\u003e\n"],["\u003cp\u003eService Directory requires specific configurations like a namespace, a service, and an endpoint with an internal IP and HTTPS port, all of which must be created within the same region as the Cloud Build host connection.\u003c/p\u003e\n"],["\u003cp\u003eAccess for the Cloud Build service agent to both the Service Directory and the VPC network must be granted using specific IAM role assignments.\u003c/p\u003e\n"],["\u003cp\u003eTo reach hosts outside of Google Cloud, Service Directory uses a specific IP range that must be allowlisted in the firewall, and an alternative to this is to use Cloud Load Balancing and its IP address in place of the host's.\u003c/p\u003e\n"]]],[],null,["# Build repositories from GitLab Enterprise Edition in a private network\n\nCloud Build enables you to create triggers to build from repositories\nhosted on [GitLab Enterprise Edition](https://about.gitlab.com/enterprise/),\nallowing you to execute builds in response to events such as commit pushes or\nmerge requests associated with your GitLab Enterprise Edition repository.\n\nThis page explains how you can enable trigger functionality on a GitLab\nEnterprise Edition instance if your instance is hosted in a private network.\n\nBefore you begin\n----------------\n\n-\n\n\n Enable the Cloud Build, Secret Manager, Compute Engine, and Service Networking APIs.\n\n\n [Enable the APIs](https://console.cloud.google.com/flows/enableapi?apiid=cloudbuild.googleapis.com,secretmanager.googleapis.com,compute.googleapis.com,servicenetworking.googleapis.com&redirect=https://cloud.google.com/build/docs/automating-builds/gitlab/build-repos-from-gitlab-enterprise-edition-private-network)\n\n\u003c!-- --\u003e\n\n- Follow the instructions to [connect a GitLab Enterprise Edition host](/build/docs/automating-builds/gitlab/connect-host-gitlab-enterprise-edition).\n- Follow the instructions to [connect a GitLab Enterprise Edition repository](/build/docs/automating-builds/gitlab/connect-repo-gitlab-enterprise-edition).\n\nBuild repositories from GitLab Enterprise Edition in a private network\n----------------------------------------------------------------------\n\nIf your GitLab Enterprise Edition instance is only accessible within a\nVPC network, you need to set up a\nService Directory service and build using private pools. The\nproject containing your VPC network can exist in a different\nproject than the one containing your Service Directory service.\nUse the following instructions to ensure your instance is reachable prior to\ncreating triggers:\n\n1. Enable the\n [Service Directory API](https://console.cloud.google.com/apis/library/servicedirectory.googleapis.com).\n\n2. Ensure you have the **Project IAM Admin** role granted to the\n Google Cloud project you intend to create your\n Service Directory service in. To learn how to grant\n IAM roles, see\n [Configuring access to Cloud Build resources](/build/docs/securing-builds/configure-access-to-resources).\n\n3. Set up a Service Directory service by completing the following steps:\n\n 1. [Configure a namespace](/../service-directory/docs/configuring-service-directory#configure_a_namespace)\n for your Google Cloud project.\n\n The region you specify in your namespace **must** match the region you\n specify in your Cloud Build host connection.\n 2. [Configure a service](/../service-directory/docs/configuring-service-directory#configure_a_service)\n in your namespace.\n\n 3. [Configure an endpoint](/../service-directory/docs/configuring-service-directory#configure_an_endpoint)\n for your registered service.\n\n When configuring an endpoint, you **must** use an internal IP address and\n specify an HTTPS port number in order for Cloud Build to reach your\n service.\n\n To learn more about private network access configuration, see\n [Configure private network access](/../service-directory/docs/configuring-private-network-access).\n Service Directory also provides integration with services\n such as load balancers and Google Kubernetes Engine (GKE).\n To learn more, see\n [Service Directory and load balancing overview](/../service-directory/docs/sd-lb-overview)\n or [Service Directory for GKE overview](/../service-directory/docs/sd-gke-overview).\n4. Grant Service Directory access to the Cloud Build service agent:\n\n export PROJECT_NUMBER=$(gcloud projects describe \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e --format=\"value(projectNumber)\")\n export CLOUD_BUILD_SERVICE_AGENT=\"service-$PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com\"\n gcloud projects add-iam-policy-binding \u003cvar translate=\"no\"\u003ePROJECT_ID_CONTAINING_SERVICE_DIRECTORY\u003c/var\u003e \\\n --member=\"serviceAccount:$CLOUD_BUILD_SERVICE_AGENT\" \\\n --role=\"roles/servicedirectory.viewer\"\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is your Cloud Build project ID.\n - \u003cvar translate=\"no\"\u003ePROJECT_ID_CONTAINING_SERVICE_DIRECTORY\u003c/var\u003e is the ID of your Google Cloud project that contains your Service Directory.\n5. Grant VPC network resource access to the Cloud Build service agent:\n\n export PROJECT_NUMBER=$(gcloud projects describe \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e --format=\"value(projectNumber)\")\n export CLOUD_BUILD_SERVICE_AGENT=\"service-$PROJECT_NUMBER@gcp-sa-cloudbuild.iam.gserviceaccount.com\"\n gcloud projects add-iam-policy-binding \u003cvar translate=\"no\"\u003ePROJECT_ID_CONTAINING_NETWORK_RESOURCE\u003c/var\u003e \\\n --member=\"serviceAccount:$CLOUD_BUILD_SERVICE_AGENT\" \\\n --role=\"roles/servicedirectory.pscAuthorizedService\"\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e is your Cloud Build project ID.\n - \u003cvar translate=\"no\"\u003ePROJECT_ID_CONTAINING_NETWORK_RESOURCE\u003c/var\u003e is the ID of your Google Cloud project that contains your network resource.\n6. Use [private pools](/build/docs/private-pools/private-pools-overview) to run\n your builds. If you have not created a private pool, see [create a new\n private pool](/build/docs/private-pools/create-manage-private-pools).\n\n7. Follow the instructions to\n [create a GitLab Enterprise Edition trigger](/build/docs/automating-builds/gitlab/build-repos-from-gitlab-enterprise-edition)\n to build repositories hosted on a GitLab Enterprise Edition instance.\n\n If you include a self-signed or private certificate when connecting your\n GitLab Enterprise Edition host to Cloud Build, you **must** set the\n host URI as the Subject Alternative Name (SAN) of your certificate.\n\nYour GitLab Enterprise Edition trigger will now automatically invoke builds on\nyour GitLab Enterprise Edition instance based on your configuration.\n\nUse Service Directory to reach hosts outside Google Cloud\n---------------------------------------------------------\n\nService Directory uses the IP address range `35.199.192.0/19` to\nconnect your host outside of Google Cloud. You must add this range to\nan allowlist in your firewall. Additionally, your private network needs to be\nconfigured to route this range through the Cloud VPN or Cloud Interconnect\nconnection.\n\nIf your connection uses a Cloud Router, you can configure your connection to\n[communicate](/../network-connectivity/docs/router/how-to/advertising-custom-ip)\nthe range to your private network.\n\nTo learn more, see [Configure private network access](/../service-directory/docs/configuring-private-network-access).\n\n### Use Cloud Load Balancing to reach hosts outside Google Cloud\n\nIf your network configuration does not allow you to route the\nService Directory IP address range `35.199.192.0/19` to the\nCloud VPN or Cloud Interconnect, you can\n[create a load balancer](/../load-balancing/docs/l7-internal) using\nCloud Load Balancing that directs traffic to your host.\n\nWhen you create the Service Directory endpoint, make sure to use\nthe IP address of the forwarding rule of the load balancer instead of the IP\naddress of your host. You can use an\n[internal HTTPS load balancer](/../load-balancing/docs/l7-internal/setting-up-int-https-hybrid)\nor an\n[internal transmission control protocol (TCP) load balancer](/../load-balancing/docs/tcp/set-up-int-tcp-proxy-hybrid)\nwhen creating your endpoint.\n\nWhen creating your TCP load balancer, consider the following:\n\n- Only a hybrid connectivity network endpoint group (NEG) is required to reach your host.\n- The TCP load balancer does not require the unencrypted private key for your SSL certificate.\n- Your Cloud VPN setup needs to use Cloud Router with global dynamic routing. If your Cloud VPN uses static routing, you can use a proxy that uses Cloud Service Mesh instead. To learn more, see [Set up network\n edge services for hybrid\n deployments](/../traffic-director/tutorials/network-edge-services-multi-environment).\n\nTo learn more about creating an HTTPS load balancer, see\n[Set up an internal Application Load Balancer with hybrid connectivity](/../load-balancing/docs/l7-internal/setting-up-int-https-hybrid).\nTo learn more about creating a TCP load balancer, see\n[Set up a regional internal proxy Network Load Balancer with hybrid connectivity](/../load-balancing/docs/tcp/set-up-int-tcp-proxy-hybrid).\n\nData sharing\n------------\n\nThe data sent to GitLab Enterprise Edition from Cloud Build helps you\nidentify triggers by name and see build results on your GitLab Enterprise\nEdition repositories.\n\nThe following data is shared between Cloud Build and GitLab\nEnterprise Edition:\n\n- Google Cloud project ID\n- Trigger name\n\nWhat's next\n-----------\n\n- Learn how to [manage build triggers](/build/docs/automating-builds/create-manage-triggers).\n- Learn how to [perform blue/green deployments on Compute Engine](/build/docs/deploying-builds/deploy-compute-engine)."]]