GitLab Network Documentation

Last updated: August 1, 2026

Purpose: This document supports firewall change requests. It gives the network flow specifications for the connection between your self-hosted GitLab instance(s) and the Aisle SaaS platform.

Firewall rules are necessary for GitLab Self-Managed and GitLab Dedicated instances only. For GitLab SaaS (gitlab.com), see the section “GitLab SaaS” at the end of this document.

Summary

Bidirectional traffic is necessary.
Grouped firewall rules can cover more than one GitLab instance.
The rules enable repository analysis, fix merge requests, automatic merge request review (PR bot), CI validation, and webhook notifications.

Caution: The Aisle egress IP and the Aisle inbound address are two different things. The egress IP is the source of the Aisle-to-GitLab traffic (Rule 1). It is static. Allow it by IP. The inbound webhook destination (Rule 2) is the FQDN {customer}.app.aisle.cloud on port 443. Allow it by FQDN, not by IP. The IP addresses behind that name can change without notice.

Firewall rules

#	Direction	Source	Destination	Port / protocol	Purpose
1	Inbound	Aisle egress IP	GitLab server(s)	443 · HTTPS / TLS	API calls, Git clone / fetch / push
2	Outbound	GitLab server(s)	Aisle tenant URL	443 · HTTPS / TLS	Webhook notifications (push, merge request, note, pipeline events)

Note: Aisle gives you the exact egress IP addresses and your tenant URL {customer}.app.aisle.cloud at onboarding. Programmatic access to the Aisle REST API uses a different endpoint, {customer}.api.aisle.cloud (port 443). The GitLab integration does not need it. If your internal systems will call the Aisle API (for example, from CI pipelines), request a separate egress rule for that FQDN.

Network flow diagram

Network flow: Rule 1 from Aisle Cloud to GitLab over HTTPS 443; Rule 2 from GitLab to Aisle webhooks, allowed by FQDN.

Figure 1 — Network flow. Rule 1 (solid line): Aisle to GitLab over HTTPS 443 for API v4 and Git. Rule 2 (dashed line): GitLab webhooks to Aisle through the egress proxy, allowed by FQDN.

Detailed firewall rule specifications

Rule 1 — Aisle to GitLab (API and Git operations)

Rule name	`AISLE-TO-GITLAB-API`
Action	ALLOW
Direction	INBOUND (to the customer network)
Source IP(s)	<Provided by Aisle>
Source port	Any (ephemeral)
Destination	All GitLab FQDNs (see the table below)
Destination port	443
Protocol	TCP / HTTPS / TLS 1.2+
Description	Aisle VCS integration — API and Git operations

More than one GitLab instance (grouped)

If you have more than one GitLab instance, list all destinations in one rule:

Instance name	FQDN	Public IP
GitLab-1	`gitlab-1.company.com`	example: 203.0.113.10
GitLab-2	`gitlab-2.company.com`	example: 198.51.100.20

Note: Enter the public IP that each FQDN resolves to from the internet. This is usually the WAF, the reverse proxy, or the load balancer address, not the internal server address.

Rule 2 — GitLab to Aisle (webhooks)

Rule name	`GITLAB-TO-AISLE-WEBHOOKS`
Action	ALLOW
Direction	OUTBOUND (from the customer network)
Source IP(s)	GitLab server IP(s)
Source port	Any (ephemeral)
Destination	`{customer}.app.aisle.cloud`
Destination port	443
Protocol	TCP / HTTPS / TLS 1.2+
Description	GitLab webhook notifications to Aisle

GitLab endpoints that Aisle uses

Aisle accesses these URL paths on your GitLab server(s):

Endpoint	Method	Path	Purpose
Projects list	GET	`/api/v4/projects`	List the accessible repositories
Project details	GET	`/api/v4/projects/:id`	Get the repository data
Branches	GET	`/api/v4/projects/:id/repository/branches`	List the branches
Merge requests	GET / POST	`/api/v4/projects/:id/merge_requests`	List and make MRs
Merge request	GET / PUT	`/api/v4/projects/:id/merge_requests/:mr_iid`	Get, update, and close MRs
MR commits	GET	`/api/v4/projects/:id/merge_requests/:mr_iid/commits`	Read the MR commit list
MR comments (notes)	GET / POST / PUT / DELETE	`/api/v4/projects/:id/merge_requests/:mr_iid/notes`	PR bot comments on MRs
MR diff comments	POST	`/api/v4/projects/:id/merge_requests/:mr_iid/discussions`	PR bot line-level review comments
Comment reactions	POST	`/api/v4/projects/:id/merge_requests/:mr_iid/notes/:note_id/award_emoji`	Acknowledge PR bot commands
Commit status	POST	`/api/v4/projects/:id/statuses/:sha`	Post the analysis status on commits
Commit details	GET	`/api/v4/projects/:id/repository/commits/:sha`	Look up commits for the status reports
Pipelines	GET	`/api/v4/projects/:id/pipelines`, `…/pipelines/:pipeline_id`, `…/pipelines/:pipeline_id/jobs`	CI validation (polling fallback)
Project members	GET	`/api/v4/projects/:id/members/all/:user_id`	Resolve the MR commenter permissions
Webhooks	GET / POST / PUT / DELETE	`/api/v4/projects/:id/hooks`	Control the webhooks
Token data	GET	`/api/v4/personal_access_tokens/self`	Validate the PAT
Current user	GET	`/api/v4/user`	Get the authenticated user
Git operations	GET / POST	`/.git/info/refs`, `/.git/git-upload-pack`, `/*.git/git-receive-pack`	Clone, fetch, and push (Git Smart HTTP)

Aisle webhook endpoint

GitLab sends the webhook notifications to this Aisle endpoint:

URL	`https://{customer}.app.aisle.cloud/api/v2/webhooks/vcs/gitlab`
Method	POST
Content-Type	`application/json`
Authentication	`X-Gitlab-Token` header

Note: Aisle makes the webhooks automatically through the GitLab API, with the PAT. Aisle makes and controls the webhook secret.

Events sent

Event	Trigger	Purpose
`push`	A push to a branch (Aisle filters the branches on its side)	Start the incremental analysis after a merge
`merge_request`	An MR opens, updates, merges, or closes	Start the automatic MR analysis (PR bot)
`note`	A comment on a merge request	Permit the PR bot commands
`pipeline`	A pipeline status change	CI validation of the Aisle fix MRs

Note: If GitLab cannot deliver the pipeline webhooks, CI validation gets the pipeline results from the GitLab API (polling) through Rule 1. The other events have no polling fallback.

Traffic flow sequence

Figure 2 — Traffic flow sequence across Aisle Cloud, the customer firewall or egress proxy, and self-hosted GitLab.

WAF / reverse proxy configuration

If your GitLab instance is behind a Web Application Firewall (WAF) or a reverse proxy, permit the URL patterns and the HTTP methods that follow.

Permitted URL patterns (inbound to GitLab)

/api/v4/projects*
/api/v4/personal_access_tokens/self
/api/v4/user
/*.git/*

Necessary HTTP methods

Path pattern	Methods
`/api/v4/projects*`	GET, POST, PUT, DELETE
`/api/v4/personal_access_tokens/self`	GET
`/api/v4/user`	GET
`/.git/`	GET, POST (Git Smart HTTP)

Note: Aisle uses all four HTTP methods under /api/v4/projects*: MR updates, review comments, commit statuses, and webhook control.

Possible WAF rule considerations

Rule category	Reason
Request body size limits	Git push operations can have large payloads
Rate limits	Repository synchronization can send bursts of requests
Bot detection	Server-to-server traffic has no browser fingerprint
(SQL) injection rules	API paths contain `:id` parameters, and these can trigger a rule

Outbound WAF / proxy (for the webhooks)

Permitted destination	`{customer}.app.aisle.cloud`
Port	443
Method	POST
Path	`/api/v2/webhooks/vcs/gitlab`

Per-instance checklist

For each GitLab instance, make sure that these conditions are true:

The instance FQDN resolves from the internet (public DNS).
The TLS certificate is valid and comes from a public CA.
The firewall rule includes this instance.
The external_url setting contains the public DNS name, not an internal name.

GitLab SaaS

For GitLab SaaS (gitlab.com), no firewall rules are necessary. Aisle connects to gitlab.com directly, and GitLab sends the webhooks to Aisle directly. Your network is not part of these flows.

One exception exists. GitLab Premium and Ultimate groups can restrict access by IP address (the group setting Restrict access by IP address). If your top-level group uses this restriction, add the Aisle egress IP addresses to the permitted list. For more data, see Restrict group access by IP address.