GitLab support requires matching early-access agent and Rootly backend builds. Confirm availability with your Rootly representative before rollout.
Create a read-only GitLab token
Use a dedicated GitLab identity. The provider accepts a personal access token, a group access token, or a project access token with theread_api scope.
read_api is the only scope the agent needs; do not grant api, write, or
sudo. A group or project access token scopes upstream access even further and
composes cleanly with the local allowlist below.
The token is sent as PRIVATE-TOKEN or Authorization: Bearer, so treat it
like a password: prefer an expiry and rotate the projected Secret before it
expires. The agent rereads the token file for every request, so a rotated
Secret takes effect without editing the agent YAML or restarting. Write only
the token value to the Secret described in
Configure instances with Helm.
Configure instances with Helm
Create the GitLab token Secret separately. Therootly-private-agent namespace
must already exist; on a first install, run this after the base Helm installation
has created the namespace.
--from-file=ca.pem and ca_bundle_file when the GitLab certificate
chains to a CA already trusted by the agent image.
Add the provider and mount to your Helm values:
url plus /api/v4. url must use HTTPS unless you set
allow_insecure_http: true, which is intended only for local testing. Mount a
private CA with ca_bundle_file when needed; mutual TLS is supported with the
paired client_certificate_file and client_key_file paths. There is no
skip-certificate-verification option. The client certificate and key are
reread on each new TLS handshake. The CA bundle is read once at startup, so
restart the agent after replacing ca_bundle_file.
Scope and policy
allowed_groupslists full group paths (for exampleinfraorplatform/observability). Each allowed group includes all of its subgroups and the projects beneath them.allowed_projectslists full project paths (group/sub/project). It can narrow the scope further or add individual projects outside the allowed groups.- When both lists are empty, the provider permits every group and project the token itself can see. Either way, the agent rejects a call for a project outside the allowlist before any network request, and list results are filtered to the allowlist.
maximum_concurrency,maximum_result_bytes,maximum_itemsper list call,maximum_file_bytesforget_filecontent,maximum_diff_bytesper diff, andmaximum_timeout_secondsbound every call. Hard maxima are listed in Private Agent limits. Lower values tighten the provider; Rootly uses the advertised values to narrow tool limits.
Available tools
Every tool is a sensitive read.project inputs are always full paths such as
infra/api, never numeric IDs, and the agent URL-encodes them itself.
There are no write operations, no CI job logs or traces, and no access to
issues, wikis, snippets, or CI/CD variables.
Data redaction and limits
Before a result leaves your network, the agent removes:- token, credential, password, and secret fields (for example runner tokens) from API metadata;
- user email addresses (results keep
usernameandname); - avatar URLs and URL query strings;
- CI job logs and traces.
truncated: true when cut. List results always carry items and truncated.
A result that remains too large is rejected so AI SRE can narrow the request.
Results can enter AI model context, evaluation traces, and investigation or
conversation history under the Private Agent retention model.
Health, compatibility, and routing
Each configured instance reports independent health. An invalid token, TLS failure, or unavailable GitLab API marks only that instance unhealthy; other instances remain registered and routable. In AI SRE → Atlas → Private agents (AI & Agents → Private agents if your sidebar doesn’t have an AI SRE item), verify the provider ID, health, last check, and advertised capabilities. Compatibility CI runs the provider against GitLab CE 19.4. Other self-managed versions and GitLab.com use the same stable/api/v4 endpoints but are not
certified; confirm your version with your Rootly representative before
rollout.