Connecting a Private Self-Managed GitLab to AWS DevOps Agent

AWS DevOps Agent can investigate your code, pipelines, and merge requests and help you troubleshoot - but only once it can reach your GitLab. If your GitLab is self-managed and private (no public internet exposure), you connect it using a Private Connection, which reaches into your VPC using Amazon VPC Lattice.

This post walks through the connection end to end so you can ask the agent questions about your repositories on demand - list projects, summarize a repo, review a file, or investigate a pipeline.

Scope: this covers connecting the agent to GitLab so you can investigate your repositories on demand - list projects, summarize a repo, review a file, or investigate a pipeline.

Values in <angle brackets> (like <GITLAB_PRIVATE_IP> or <GITLAB_HOSTNAME>) are placeholders - substitute your own.

---

How it works

AWS DevOps Agent  →  Private Connection  →  GitLab
                     (auto-creates the VPC Lattice
                      resource gateway + ENI in your VPC)

When you create the Private Connection, the DevOps Agent service provisions the VPC Lattice resource gateway and its network interface (ENI) in your VPC for you - you don't build those yourself. The agent then reaches GitLab through that gateway, entirely over private networking.

---

Prerequisites

• AWS DevOps Agent enabled in your account (the AWSServiceRoleForAIDevOps service-linked role exists).
• A self-managed GitLab (Community Edition is fine) reachable by a private IP inside a VPC.

---

Step 1 - On GitLab: create a token

1. Create a Personal Access Token (User Settings → Access Tokens):

   • Scopes: api, read_repository, read_virtual_registry, read_registry, self_rotate.

   • Expiration: cap it at 365 days (the maximum accepted).

   • Role: the token's user needs at least Maintainer on the projects you'll connect.

   Note on self_rotate: it doesn't do anything yet, but add it now so you don't have to recreate the token later when it becomes required.

   Note: a Group Access Token (GAT) is also valid instead of a Personal Access Token. If you use one, enter the GAT in the Access Token field in Step 3.

2. Have GitLab's server TLS certificate (PEM) ready. If GitLab uses a self-signed or private-CA certificate, you'll paste it into the Private Connection in Step 2. You can read it from the server, e.g.:

   cat /etc/gitlab/ssl/<GITLAB_HOSTNAME>.crt
   

   (If GitLab uses a publicly trusted certificate, you can skip the cert step.)

   Full chain option: the certificate field also accepts a full chain. If GitLab's cert comes from a private/enterprise CA with intermediates, paste leaf → intermediate(s) → root, in that order - otherwise the connection fails. The single-leaf cat above works when there are no intermediates (e.g. a self-signed cert). See troubleshooting private connections for full certificate chain guidance.

---

Step 2 - Create the Private Connection

In the DevOps Agent console → Private connections → Configure private connection:

Field	Value
Name	e.g. gitlab-private
VPC where your resource is located	<VPC_ID>
Subnets	<PRIVATE_SUBNET_ID> (the console lists Availability Zones that VPC Lattice doesn't support - pick a supported one). This walkthrough uses a single subnet, but the docs recommend subnets across at least two AZs for HA.
IP address type	IPv4
Security groups associated with your connected resources	<GITLAB_SG_ID> (or any SG that permits reaching GitLab)
DNS resolution (Advanced → Service target details)	In VPC (private DNS) - note: because this walkthrough uses GitLab's IP as the host address, this setting has no effect either way
Host address	<GITLAB_PRIVATE_IP> - GitLab's private IP
Certificate public key	if GitLab uses a self-signed or private-CA cert, paste its PEM (the cert from Step 1)

The certificate is what lets the agent complete the TLS handshake to GitLab, so paste it here.

-----BEGIN CERTIFICATE-----
... your GitLab server certificate (PEM) ...
-----END CERTIFICATE-----

Alternative (no IP required). If GitLab's hostname resolves through a private hosted zone, you can set DNS resolution to "In VPC" and use the hostname itself as the host address - no IP needed.

Creation can take up to ~10 minutes. When it shows Completed, the resource gateway and its ENI have been created in your subnet. Make sure GitLab's security group allows inbound from that gateway ENI.

---

Step 3 - Register the GitLab capability

In the DevOps Agent console → Register GitLab Account / Group:

Field	Value
Name	e.g. gitlab
Connecting as a person or a group	Personal (or Group, with a Group Access Token)
GitLab URL	https://<GITLAB_HOSTNAME> - the hostname (https)
Access Token	<PAT>
Private connection	select the connection from Step 2 - do not leave this blank

Selecting the private connection is what routes the capability through your private path. If you leave it blank, the agent tries to reach GitLab over the public internet, which won't work for a private instance.

---

Step 4 - Add to an Agent Space and select a project

Enable the GitLab capability in your Agent Space, then select the project(s) you want the agent to work with. Once selected, the repository is available to the agent.

---

Validate

Ask the agent, for example:

• "List my GitLab projects."
• "Summarize the repository <group>/<project>."
• "Review the main application file and its tests - any bugs?"

If it lists and reads your project, the connection is working end to end.

---

Gotchas & troubleshooting

Symptom	Cause	Fix
Association fails / "Could not complete request to provider"	A hostname was put in the connection host address while DNS resolution was not set to "In VPC" (Lattice couldn't resolve it)	Use the private IP as host address (or set DNS resolution to "In VPC" if the hostname resolves via a private hosted zone); the hostname still goes on the capability
Empty project list, and no traffic reaches GitLab	Agent doesn't trust GitLab's TLS certificate	Paste GitLab's server cert PEM in the Private Connection's Certificate public key field
Agent can't reach GitLab	Security group doesn't allow the gateway ENI	Allow inbound from the resource gateway ENI to GitLab
Connection shows Completed but no ENI is created	A Service Control Policy is denying vpc-lattice:*	Ensure no SCP blocks VPC Lattice for the DevOps Agent service-linked role (visible in CloudTrail)
Connection stuck in Create failed	Port range where start equals end (e.g. 443-443) is rejected	Use a single port or a real range (not 443-443)
Leftover resource gateways / ENIs after deleting a connection	The AWSAIDevOpsManaged tag was removed, which blocks cleanup	Keep the AWSAIDevOpsManaged tag intact so the service can clean up the gateway/ENI
Adding a project fails on authorization	Token role too low	The token's user needs Maintainer or above

---

Summary

To connect a private self-managed GitLab to AWS DevOps Agent:

1. On GitLab, create a PAT (api, read_repository, read_virtual_registry, read_registry, self_rotate) and grab the server cert.
2. Create a Private Connection using GitLab's private IP or the alternative, and paste GitLab's cert (it also auto-builds the Lattice gateway + ENI).
3. Register the GitLab capability using the hostname + PAT, and select the private connection.
4. Add it to your Agent Space, select a project, and start asking questions.

For more help, see the AWS documentation on troubleshooting private connections.