> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/application-security/application-security/onboard-data-sources/onboard-version-control-systems/gitlab-self-managed-on-prem.md).
# GitLab Self Managed (On-Prem)
Integrate Cortex Cloud Application Security with your GitLab Self Managed (On-Prem) version control system (VCS) to enable security scans for exposed secrets, infrastructure-as-code (IaC) misconfigurations, vulnerabilities, package operational risks, and license compliance issues in your repositories. This integration allows you to analyze, prioritize, and resolve detected issues efficiently.
## Architecture and connectivity
Whether you need a Transporter depends on your GitHub Enterprise on-prem accessibility. If your instance is hosted on a private domain, a direct connection fails because Cortex Cloud cannot reach the on-premises host.
To solve this, the Transporter over Broker VM bridges the connection by:
* **Living inside your network** as an applet on the Broker VM
* **Initiating an outbound WebSocket connection** to the cloud, meaning no inbound firewall rules or direct IP access are needed
* **Proxying requests** from the cloud to internal resources, allowing Cortex Cloud to perform secure code scanning without exposing your internal network to the public cloud
#### Connection guidelines
* **Private domains (isolated environments)**: Always use a Transporter. Make sure the Transporter has an AppSec applet enabled so it appears in the onboarding wizard. An egress rule is not required
* **Public domains (internet-accessible)**: If your GitHub Enterprise on-prem instance is already internet-accessible or managed via existing connectivity solutions (such as a VPN or network peering), a Transporter is not needed. An egress rule is required
For more information on Transporter, refer to [Transporter over Broker VM](/application-security/application-security/onboard-data-sources/transporter-over-broker-vm.md).
If your GitLab self-managed instance is already internet-accessible or managed via existing connectivity solutions (such as a VPN or network peering), the Transporter is not needed.
## How to integrate GitLab Self Managed (On-Prem)
{% hint style="warning" %}
### Prerequisite
* **Cortex Cloud user permissions**: Ensure you have **View/Edit** permissions for **Data Sources and Integrations** (RBAC: AppSec Admin or Instance Administrator)
* **Gitlab permissions**: Authorize the user integrating Cortex Cloud Application Security with your GitLab Self Managed (On-Prem) instances with the following permissions:
* **Maintainer** permissions. Grants sufficient permissions to configure external integrations, manage repository access, and adjust CI/CD settings
* **api**: Grants full read and write access to the API, including all groups and projects, as well as permissions to interact with the container registry, the dependency proxy, and the package registry
* **Administrator repository permissions**: In order to scan pull requests (PRs), the user performing the integration must have administrative privileges for the repositories. This enables Cortex Cloud Application Security to set up subscription webhooks for the selected repositories
* **Onboarding port**: Port `443` is required for all on-premise onboarding for outbound HTTPS communication to Cortex Cloud. If the Transporter is used, it specifically uses port `443` for its WSS tunnel
* **Egress path**: Create an egress path to establish the designated route for outbound data transmission from Cortex Cloud to third party services. For more information about configuring egress paths,refer to [Egress configurations](/gateway-guide/egress-configurations.md)
{% endhint %}
### Onboarding steps
1. In the Cortex Cloud tenant.
1. Navigate to **Settings** → **Data Sources & Integrations** → **+ Add New**.
2. Search for GitLab Self Managed (On-Prem) , hover over it, and click Add or **Add Another Instance** if an instance has already been onboarded.
3. Enter your domain in the **Configure Domain** step of the wizard and click Register.
Note
The domain is the hostname associated with your GitLab Self Managed (On-Prem) instance.
Note
Ensure that you receive the Instance Successfully Created message on this step, indicating successful instance creation.
Read more...
| Category | Event | Description |
| -------- | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Projects | — | — |
| — | merge\_requests\_events | This event is triggered when merge or pull requests are created, updated, merged, closed, or have changes made to them |
| — | push\_events | This event occurs whenever code changes are pushed to a repository, indicating new commits being added to the version control history |
| — | tag\_push\_events | This event is triggered when new tags are pushed to a repository |
| — | note\_events | This event is generated when comments or notes are added to various objects within GitLab, such as issues, merge requests, or commits |
| — | confidential\_note\_events | Similar to note\_events, but specifically for confidential comments or notes that are restricted to certain users or groups |
| — | issues\_events | This event is triggered when issues are created, updated, closed, or have changes made to them |
| — | confidential\_issues\_events | Similar to issues\_events, but specifically for confidential issues that are restricted to certain users or groups |
| — | job\_events | This event occurs when jobs defined in CI/CD pipelines are created, updated, started, finished, or have changes made to them |
| — | pipeline\_events | This event is generated when pipelines are created, updated, started, finished, or have changes made to them |
| — | wiki\_page\_events | This event occurs when changes are made to wiki pages within GitLab, including creation, updates, and deletions |
| — | deployment\_events | This event is triggered when deployments are created, updated, started, finished, or have changes made to them |
| — | releases\_events | This event occurs when releases are created, updated, published, or have changes made to them |
| Groups | — | — |
| — | subgroup\_events | This event is specific to GitLab groups and occurs when changes are made to subgroups within a group hierarchy |
| System | repository\_update\_events | This event occurs whenever there are updates or changes made to a GitLab repository, including actions such as new commits, branch operations, tag updates, and modifications to repository settings |
## Manage the integration
#### Instance-level actions
1. Navigate to **Settings** → **Data Sources & Integrations** and search for **GitLab Self Managed (On-Prem)**.
2. Select the matching result.
3. Locate your instance from the displayed list, right-click it, then select an option:
* **Edit instance**: Opens the onboarding wizard, where you can change the instance configuration.
* **Delete instance**: Deletes the instance and previous scan data.
* **Copy entire row**: Copies all row values to the clipboard.
#### Repository-level actions
Right-click a connected repository to **Set Scanned Branches**, run a manual scan through **Scan Repository**, modify the **Scan Configuration**, or **Remove Repository** entirely. You can toggle specific scanners and manage PR behavior in **Scan Configuration**.
1. Locate your instance. See [Verify integration](#verify-integration) above.
2. Select the instance. A list of connected repositories appears.
3. Right-click a repository, select the required action, then click **Save**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/application-security/application-security/onboard-data-sources/onboard-version-control-systems/gitlab-self-managed-on-prem.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.