To help GitLab customers maximize their platform investments, we developed the GitLab CI/CD Observability solution as part of our Platform Excellence program, which transforms raw pipeline metrics into actionable operational insights.

A leading financial services organization partnered with GitLab's customer success architect to gain visibility into their GitLab self-managed deployment. Together, we implemented a containerized observability solution combining the open-source gitlab-ci-pipelines-exporter with enterprise-grade Prometheus and Grafana infrastructure.

In this article, you'll learn the challenges they faced managing pipelines at scale and how GitLab CI/CD Observability addressed them with a practical, end-to-end implementation.

The challenge: Measuring CI/CD performance

Before implementing any observability solution, define your measurement landscape:

• What metrics matter? Pipeline duration, job success rates, queue times, runner utilization
• Who needs visibility? Developers, DevOps engineers, platform teams, leadership
• What decisions will this drive? Infrastructure investment, bottleneck remediation, capacity planning

Solution architecture: A full set of dashboards for observability

Once deployed, the observability stack provides a set of Grafana dashboards that give real-time and historical visibility into your CI/CD platform. A typical deployment includes:

• Pipeline Overview Dashboard: A top-level view showing total pipeline runs, success/failure rates over time (as stacked bar or time-series charts), and average pipeline duration trends. Panels use color-coded status indicators (green for success, red for failure, amber for cancelled) so platform teams can spot degradation at a glance.
• Job Performance Dashboard: Drill-down panels showing individual job duration distributions (histogram), the top 10 slowest jobs by average duration, and job failure heatmaps by project and stage. This is where teams identify specific bottleneck jobs worth optimizing.
• Runner & Infrastructure Dashboard: Combines Node Exporter host metrics (CPU, memory, disk) with pipeline queue-time data to correlate infrastructure saturation with pipeline wait times. Useful for capacity planning decisions such as scaling runner pools or upgrading instance sizes.
• Deployment Frequency Dashboard: Tracks deployment count and deployment duration over time per environment, aligned with DORA metrics. Helps engineering leadership assess delivery throughput and environment drift (commits behind main).

Each dashboard is provisioned automatically via Grafana's file-based provisioning, so it deploys consistently across environments. The dashboards can be further customized with Grafana variables to filter by project, ref/branch, or time range.

The solution requires two exporters:

• Pipeline Exporter: Collects CI/CD metrics via GitLab API (pipeline duration, job status, deployments)
• Node Exporter: Collects host-level metrics (CPU, memory, disk) for infrastructure correlation

Prerequisites:

• GitLab Self-Managed Version 18.1+
• Container orchestration platform: A Kubernetes cluster (recommended for enterprise deployments) or a container runtime such as Docker/Podman for smaller scale or proof-of-concept environments. The primary deployment guide below targets Kubernetes; a Docker Compose alternative is provided in the appendix for local testing and evaluation
• GitLab Personal Access Token (read_api scope)

Kubernetes deployment (recommended)

For enterprise environments, deploy each component as a separate Deployment within a dedicated namespace. This approach integrates with existing cluster infrastructure, secrets management, and network policies.

1. Create namespace and secret

kubectl create namespace gitlab-observability

# Create the GitLab token secret (see Secrets Management section below
# for enterprise-grade approaches using external secret operators)
kubectl create secret generic gitlab-token \
  --from-literal=token=glpat-xxxxxxxxxxxx \
  -n gitlab-observability

2. Deploy the Pipeline Exporter

# exporter-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gitlab-ci-pipelines-exporter
  template:
    metadata:
      labels:
        app: gitlab-ci-pipelines-exporter
    spec:
      containers:
        - name: exporter
          image: mvisonneau/gitlab-ci-pipelines-exporter:latest
          ports:
            - containerPort: 8080
          env:
            - name: GCPE_GITLAB_TOKEN
              valueFrom:
                secretKeyRef:
                  name: gitlab-token
                  key: token
            - name: GCPE_CONFIG
              value: /etc/gcpe/config.yml
          volumeMounts:
            - name: config
              mountPath: /etc/gcpe
      volumes:
        - name: config
          configMap:
            name: gcpe-config
---
apiVersion: v1
kind: Service
metadata:
  name: gitlab-ci-pipelines-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: gitlab-ci-pipelines-exporter
  ports:
    - port: 8080
      targetPort: 8080

3. Deploy Node Exporter (DaemonSet)

# node-exporter-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          ports:
            - containerPort: 9100
---
apiVersion: v1
kind: Service
metadata:
  name: node-exporter
  namespace: gitlab-observability
spec:
  selector:
    app: node-exporter
  ports:
    - port: 9100
      targetPort: 9100

4. Deploy Prometheus

# prometheus-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus
  template:
    metadata:
      labels:
        app: prometheus
    spec:
      containers:
        - name: prometheus
          image: prom/prometheus:latest
          ports:
            - containerPort: 9090
          volumeMounts:
            - name: config
              mountPath: /etc/prometheus
      volumes:
        - name: config
          configMap:
            name: prometheus-config
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus
  namespace: gitlab-observability
spec:
  selector:
    app: prometheus
  ports:
    - port: 9090
      targetPort: 9090

5. Deploy Grafana

The Grafana deployment below starts with authentication disabled (GF_AUTH_ANONYMOUS_ENABLED: true) for initial setup convenience.

This setting allows anyone with network access to view all dashboards without logging in. For production deployments, remove this variable or set it to false and configure a proper authentication provider (LDAP, SAML/SSO, or OAuth) to restrict access to authorized users.

# grafana-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  replicas: 1
  selector:
    matchLabels:
      app: grafana
  template:
    metadata:
      labels:
        app: grafana
    spec:
      containers:
        - name: grafana
          image: grafana/grafana:10.0.0
          ports:
            - containerPort: 3000
          env:
            # REMOVE or set to 'false' for production.
            # When 'true', any user with network access can
            # view dashboards without authentication.
            - name: GF_AUTH_ANONYMOUS_ENABLED
              value: 'true'
          volumeMounts:
            - name: dashboards-provider
              mountPath: /etc/grafana/provisioning/dashboards
            - name: datasources
              mountPath: /etc/grafana/provisioning/datasources
            - name: dashboards
              mountPath: /var/lib/grafana/dashboards
      volumes:
        - name: dashboards-provider
          configMap:
            name: grafana-dashboards-provider
        - name: datasources
          configMap:
            name: grafana-datasources
        - name: dashboards
          configMap:
            name: grafana-dashboards
---
apiVersion: v1
kind: Service
metadata:
  name: grafana
  namespace: gitlab-observability
spec:
  selector:
    app: grafana
  ports:
    - port: 3000
      targetPort: 3000

6. Set network policy

Restrict inter-pod traffic to only the required communication paths:

# network-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: observability-policy
  namespace: gitlab-observability
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    # Prometheus scrapes exporter and node-exporter
    - from:
        - podSelector:
            matchLabels:
              app: prometheus
      ports:
        - port: 8080
        - port: 9100
    # Grafana queries Prometheus
    - from:
        - podSelector:
            matchLabels:
              app: grafana
      ports:
        - port: 9090

7. Validate

kubectl get pods -n gitlab-observability
kubectl port-forward svc/grafana 3000:3000 -n gitlab-observability
curl http://localhost:3000/api/health

Configuration reference

Exporter configuration

# gitlab-ci-pipelines-exporter.yml (ConfigMap: gcpe-config)
log:
  level: info
gitlab:
  url: https://gitlab.your-domain.com
  maximum_requests_per_second: 10
project_defaults:
  pull:
    pipeline:
      jobs:
        enabled: true
wildcards:
  - owner:
      name: your-group-name
      kind: group
    archived: false

Prometheus configuration

# prometheus.yml (ConfigMap: prometheus-config)
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'gitlab-ci-pipelines-exporter'
    static_configs:
      - targets: ['gitlab-ci-pipelines-exporter:8080']
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

Grafana data sources

# datasources.yml (ConfigMap: grafana-datasources)
apiVersion: 1
datasources:
  - name: Prometheus
    type: prometheus
    access: proxy
    url: http://prometheus:9090
    isDefault: true
# dashboards.yml (ConfigMap: grafana-dashboards-provider)
apiVersion: 1
providers:
  - name: 'default'
    folder: 'GitLab CI/CD'
    type: file
    options:
      path: /var/lib/grafana/dashboards

Key metrics

Pipeline Exporter metrics

Node Exporter metrics

Troubleshooting

Air-gapped Grafana plugin installation

For offline environments, install plugins manually. Example for Kubernetes:

# Copy plugin zip into the Grafana pod
kubectl cp grafana-polystat-panel-2.1.16.zip \
  gitlab-observability/grafana-<pod-id>:/tmp/
# Extract plugin
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  sh -c "unzip /tmp/grafana-polystat-panel-2.1.16.zip -d /var/lib/grafana/plugins/"
# Restart Grafana pod
kubectl rollout restart deployment/grafana -n gitlab-observability
# Verify installation
kubectl exec -it -n gitlab-observability deploy/grafana -- \
  ls -al /var/lib/grafana/plugins/

Enterprise considerations

For regulated industries, ensure:

• Token security: Store GitLab Personal Access Tokens in a dedicated secrets manager rather than hardcoded in ConfigMaps. Enforce token rotation policies and limit scope to read_api only.
• Network segmentation: Deploy behind a reverse proxy with TLS termination. In Kubernetes, use an Ingress controller with automated certificate provisioning.
• Authentication: Configure Grafana with your organization's identity provider (SAML, LDAP, or OAuth/OIDC) to enforce role-based access control on dashboards.

Why GitLab?

GitLab's API-first design enables custom observability solutions that complement native capabilities like Value Stream Analytics and DORA metrics. The open architecture allows organizations to integrate proven open-source tooling — like the gitlab-ci-pipelines-exporter — directly with their existing enterprise infrastructure, without disrupting established workflows.

As your observability maturity grows, GitLab's built-in Observability capabilities provide a natural next step — offering deeper, integrated visibility without additional tooling. Learn more about what's available natively in the platform for GitLab Observability.

Claude powers capabilities across GitLab Duo Agent Platform as the default model out of the box, across a variety of use cases from code generation and review to agentic chat and vulnerability resolution. If you've used GitLab Duo, you've already experienced how Duo agents automate workflows across the entire software development lifecycle (SDLC).

This accelerates the integration of Claude’s capabilities into GitLab, broadens how enterprises can deploy them, and reinforces what makes GitLab fundamentally different as a platform for software development and engineering: governance, compliance, and auditability built into every AI interaction.

"GitLab Duo has accelerated how our teams plan, build, and ship software. The combination of Anthropic's Claude and GitLab's platform means we're getting more capable AI without changing how we work or how it is governed."

– Mans Booijink, Operations Manager, Cube

The real differentiator: Governed AI

With GitLab, governance controls and auditing are built into the SDLC. When Claude suggests a code change through the GitLab Duo Agent Platform, that suggestion flows through the same merge request process, the same approval rules, the same security scanning, and the same audit trail as every other change. AI doesn't get a shortcut around your controls. It operates within them.

As GitLab moves deeper into agentic software development, where AI autonomously handles well-defined tasks, the governance layer becomes more important. An AI agent that can open a merge request, help resolve a vulnerability, or refactor a service needs to be auditable, attributable, and subject to the same policy enforcement as a human developer. That requirement is an architectural decision GitLab made from the start, and one that grows more consequential as AI agents take on broader responsibilities.

Enterprise deployment flexibility

This also expands how organizations access the latest Claude models through GitLab. Claude is available within GitLab through Google Cloud's Vertex AI and Amazon Bedrock, which means enterprises can route AI workloads through the hyperscaler commitments and cloud governance frameworks they already have in place. No separate vendor contract. No new data residency questions. Your existing Google Cloud or AWS relationship is the on-ramp.

GitLab is now also available in the Claude Marketplace, allowing customers to purchase GitLab Credits and apply them toward existing Anthropic spending commitments – consolidating AI spend and simplifying how teams discover and procure GitLab alongside their Anthropic investments.

Advancing an agentic future

GitLab's vision for agentic software development, where AI handles defined tasks autonomously across planning, coding, testing, securing, and deploying, requires models with strong reasoning, reliability, and safety characteristics. It also requires a platform where those autonomous actions are fully governed.

Agentic workflows demand models with strong reasoning, reliability, and safety characteristics, criteria that guide how GitLab selects and integrates AI model partners. And GitLab's governance framework helps ensure that as AI agents assume more advanced development work, enterprises maintain full visibility and control over what those agents do, when they do it, and how changes are tracked.

What this means for GitLab customers

If you're already using GitLab Duo Agent Platform, you'll get access to Claude models and deeper AI assistance across your software development lifecycle, all within the governance framework you already rely on.

If you're evaluating AI-powered software development platforms, you shouldn't have to choose between advanced AI capabilities and enterprise control. This strategic integration is built to deliver both.

Want to learn more about GitLab Duo Agent Platform? Get a demo or start a free trial today.

The problem is that without the right tools, AI agents are essentially guessing when it comes to your GitLab projects. They might hallucinate the details of an issue they've never seen, summarize a merge request based on stale training data rather than its actual state, or require you to manually copy context from a browser tab and paste it into a chat window just to get started. Every one of those workarounds is friction: it slows you down, introduces the possibility of error, and puts a hard ceiling on what your agent can actually do on your behalf. glab changes that by giving agents a direct, reliable interface to your projects.

With glab, your agent fetches what it needs directly from GitLab, acts on it, and reports back — so you spend less time relaying information and more time on the work that matters.

In this tutorial, you'll learn how to use glab to give AI agents structured, reliable access to your GitLab projects. You'll also discover how that unlocks a faster, more capable development workflow.

How to connect your AI agent to GitLab through MCP

The most direct way to supercharge your AI workflow is to give your AI agent native access to glab through Model Context Protocol (MCP).

MCP is an open standard that lets AI tools discover and use external capabilities at runtime. Once connected, your AI assistant can read issues, comment on merge requests, check pipeline status, and write back to GitLab, all without copying anything from the UI or writing a single API call yourself.

To get started, run:

# Start the glab MCP server
glab mcp serve

Once your MCP client is configured, your AI can answer questions like "What's the status of my open MRs?" or "Are there any failing pipelines on main?" by querying GitLab directly, not scraping the web UI, not relying on stale training data. See the full setup docs for configuration steps for Claude Code, Cursor, and other editors.

One detail worth knowing: glab automatically adds --output json when invoked through MCP, for any command that supports it. Your agent gets clean, structured data without you needing to think about output formats. And because glab uses the official MCP SDK, it stays compatible as the protocol evolves.

We've also been deliberate about which commands are exposed through MCP. Commands that require interactive terminal input are intentionally excluded, so your agent never gets stuck waiting for input that will never come. What's exposed is what actually works reliably in an agent context.

Let your AI participate in code review

Most developers have a backlog of MRs waiting for review. It's one of the most time-consuming parts of the job and one of the best places to put AI to work. With glab, your agent doesn't just observe your review queue, it can work through it with you.

See exactly what still needs addressing

Start with this:

glab mr view 2677 --comments --unresolved --output json

This input returns the full MR: metadata, description, and every unresolved discussion, as a single structured JSON payload. Hand that to your AI and it has everything it needs: which threads are open, what the reviewer asked for, and in what context. No tab-switching, no copy-pasting individual comments.

{
  "id": 2677,
  "title": "feat: add OAuth2 support",
  "state": "opened",
  "author": { "username": "jdwick" },
  "labels": ["backend", "needs-review"],
  "blocking_discussions_resolved": false,
  "discussions": [
    {
      "id": "3107030349",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "dmurphy" },
          "body": "This error handling will swallow panics — consider wrapping with recover()",
          "created_at": "2026-03-14T09:23:11.000Z"
        }
      ]
    },
    {
      "id": "3107030412",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "sreeves" },
          "body": "Token refresh logic needs a test for the expired token case",
          "created_at": "2026-03-14T10:05:44.000Z"
        }
      ]
    }
  ]
}

Instead of reading through every thread yourself, you ask your agent "what do I still need to fix in MR 2677?" and get back a prioritized summary with suggested changes. This all happens from a single command.

Close the loop programmatically

Once your AI has helped you address the feedback, it can resolve discussions:

# List all discussions — structured, ready for the agent to process
glab mr note list 456 --output json

# Resolve a discussion once the feedback is addressed
glab mr note resolve 456 3107030349

# Reopen if something needs another look
glab mr note reopen 456 3107030349

[
  {
    "id": 3107030349,
    "body": "This error handling will swallow panics — consider wrapping with recover()",
    "author": { "username": "dmurphy" },
    "resolved": false,
    "resolvable": true
  },
  {
    "id": 3107030412,
    "body": "Token refresh logic needs a test for the expired token case",
    "author": { "username": "sreeves" },
    "resolved": false,
    "resolvable": true
  }
]

Note IDs are visible directly in the GitLab UI and API, no extra lookup needed. Your agent can work through the full list, verify each fix, and resolve as it goes.

Talk to your AI about your code more effectively

Even if you're not running an MCP server, there's a simpler shift that makes a huge difference: using glab to feed your AI better information.

Think about the last time you asked an AI assistant to help triage issues or debug a failing pipeline. You probably copied some text from the GitLab UI and pasted it into the chat. Here's what your agent is actually working with when you do that:

open issues: 12 • milestone: 17.10 • label: bug, needs-triage ...

Compare that to what it gets with glab:

[
  {
    "iid": 902,
    "title": "Pipeline fails on merge to main",
    "labels": ["bug", "needs-triage"],
    "milestone": { "title": "17.10" },
    "assignees": []
  },
  ...
]

Structured, typed, complete; no ambiguity, no parsing guesswork. That's the difference between an agent that can act and one that has to ask follow-up questions.

If you're using the MCP server, you get this automatically: glab adds --output json for any command that supports it. If you're working directly from the terminal, just add the flag yourself:

# Pull open issues for triage
glab issue list --label "needs-triage" --output json

# Check pipeline status
glab ci status --output json

# Get full MR details
glab mr view 456 --output json

We've significantly expanded JSON output support in recent releases. It now covers CI status, milestones, labels, releases, schedules, cluster agents, work items, MR approvers, repo contributors, and more. If glab can retrieve it, your AI can consume it cleanly.

A real workflow

$ glab issue list --label "needs-triage" --milestone "17.10"
--output json

Agent: I found 2 unassigned bugs in the 17.10 milestone that need triage:
1. #902 — Pipeline fails on merge to main (opened 5 days ago)
2. #903 — Auth token not refreshing on expiry (opened 4 days ago)
Both are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?

Your agent is never limited to built-in commands

glab's first-class commands cover the most common workflows, but your agent is never limited to them. Through glab api, it has authenticated access to the full GitLab REST and GraphQL API surface, using the same session, with no extra credentials or configuration required.

This is a meaningful differentiator. Most CLI tools stop at what their commands expose. With glab, if GitLab's API supports it, your agent can do it. It's always working from a trusted, authenticated context.

A practical example: fetching just the list of changed files in an MR before deciding which diffs to pull in full:

# Get changed file paths — lightweight, no diff content yet
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[].new_path'

# Then fetch only the specific file your agent needs
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[] | select(.new_path == "path/to/file.go")'

"internal/auth/token.go"
"internal/auth/token_test.go"
"internal/oauth/refresh.go"

For anything the REST API doesn't cover (epics, certain work item queries, complex cross-project data), glab api graphql gives you the full GraphQL interface:

  glab api graphql -f query='
{
  project(fullPath: "gitlab-org/gitlab") {
    mergeRequest(iid: "12345") {
      title
      reviewers { nodes { username } }
    }
  }
}'

{
  "data": {
    "project": {
      "mergeRequest": {
        "title": "feat: add OAuth2 support",
        "reviewers": {
          "nodes": [
            { "username": "dmurphy" },
            { "username": "sreeves" }
          ]
        }
      }
    }
  }
}

Your agent has a single, authenticated entry point to everything GitLab exposes without the token juggling, separate API clients, or configuration overhead.

What's coming and your feedback

Two improvements we're actively working on will make glab even more useful for agent workflows:

Agent-aware help text. Today, --help output is written for humansvat a terminal. We're updating it to surface the non-interactive alternative for every interactive command, flag which commands support --output json, and generally make help a useful resource for agents discovering capabilities at runtime — not just humans.

Better machine-readable errors. When something goes wrong today, agents get the same human-readable error messages as terminal users. We're changing that so errors in JSON mode return structured output, giving your agent the information it needs to handle failures gracefully, retry intelligently, or surface the right context back to you.

Both of these are in active development. If you're already using glab with an AI tool, you're exactly the audience we want feedback from.

• What friction are you hitting? Commands that don't behave well in agent contexts, error messages that aren't actionable, gaps in JSON output coverage. We want to know.
• What workflows have you unlocked? Real usage patterns help us prioritize what to build next.

Join the discussion in our feedback issue — that's where we're shaping the roadmap for agent-friendliness, and where your input will have the most direct impact. If you've found a specific gap, open an issue. If you've got a fix in mind, contributions are welcome. Visit CONTRIBUTING.md to get started.

The GitLab CLI has always been about giving developers more control over their workflow. As AI becomes a bigger part of how we all work, that means making glab the best possible interface between your AI tools and your GitLab projects. We're just getting started and we'd love to build the next part with you.

Why is this change happening?

This change is necessary because curl 8.18.0 deprecated compilation against OpenSSL 1.x, which prevents us from continuing our previous approach on Amazon Linux 2 and AlmaLinux 8 (affecting RHEL 8 customers). GitLab provides most dependencies for Omnibus-GitLab, but in FIPS packages we link to the distribution's cryptographic libraries rather than bundling our own — and we are now extending that model to curl.

For maintainability and security reasons, we are applying this change to all FIPS packages, including distributions with OpenSSL 3.0 or later. All FIPS customers are affected.

What do I need to do?

GitLab Self-Managed

GitLab 19.0 will be available starting on May 21, 2026.

Learn more about the release schedule.

Starting with the 19.0 Omnibus-GitLab FIPS package, the bundled curl will be removed and replaced with the curl provided by the customer's Linux distribution. The customer's GitLab instance will continue to work as expected. This change has no other impact and doesn't require any immediate action.

Important implication

GitLab will no longer be responsible for shipping security updates to curl specifically in FIPS packages, and it will be up to the customer to keep their own OS's curl up to date to receive fixes/security patches. Scanner findings for curl will now reflect the host OS package rather than a GitLab-bundled version. This is consistent with how OpenSSL is already handled in FIPS environments.

What do I do if I still have problems?

If you need assistance, please open an issue in the omnibus-gitlab issue tracker.

That is why we opened GitLab Duo Agent Platform and invited developers worldwide to build AI agents that help teams ship secure software faster. Not chatbots that answer questions, but agents that jump into workflows, respond to events, and act on your behalf. The GitLab AI Hackathon ran from February 9 to March 25, 2026, on Devpost, the hackathon platform. Google Cloud and Anthropic joined as co-sponsors.

When my team planned this hackathon with Google Cloud and Anthropic, I asked the judges to score four things: technical work, design, potential impact, and idea quality. We hoped for strong turnout. What we got surprised all of us. Nineteen judges spent 18 days reviewing every entry. Google Cloud and Anthropic provided judges, prizes, and cloud access. The community built hundreds of agents and flows because they wanted to solve these problems.

Nearly 7,000 developers showed up. They built 600+ agents and flows in weeks. The prizes across all categories totaled $65,000 from GitLab, Google Cloud, and Anthropic.

If you have ever watched a senior engineer leave and take half the team's knowledge with them, you know why the winning project hit so hard.

Read on to find out what the community built.

Grand Prize: LORE

LORE, the Living Organizational Record Engine, uses eight agents with a router that sends each question to the right agent, logic to prevent circular loops in the knowledge graph, a visual dashboard, and carbon tracking. The command-line tool ships with 43 tests (yes, 43 tests in a hackathon project).

LORE solves a real problem: the knowledge that lives in engineers' heads and walks out the door when they leave. In my experience, a hackathon project with 43 tests is rare. That many tests in a hackathon project tells you something about the team behind it.

Judge April Guo (Anthropic) wrote: "This feels like a product, not a hackathon project."

Google Cloud winners

Gitdefender won the Google Cloud Grand Prize. It works inside code review workflows, finding and fixing security issues. It spots the bug, writes the fix, and opens the code review. No developer needs to step in.

Aegis won the Google Cloud Runner Up. It gives AI-powered explanations for every decision it makes, deployed to Google Cloud and ready for production use.

Anthropic winners

GraphDev won the Anthropic Grand Prize. It maps code links and shows how systems change over time. Judge Aboobacker MK (GitLab) noted it was "in sync with our work on GitLab knowledge graph." Judge Ayush Billore (GitLab) wrote: "Loved the demo and UX, super useful for understanding how the system evolved and what gets impacted by changes." You can see the full impact of a change before you make it.

DocSync won the Anthropic Runner Up. It uses three agents: Detector, Writer, and Reviewer. If DocSync is confident in the fix, it opens a code review. If not, it creates an issue for a human to check.

Category winners

Most Technically Impressive

Database migrations break things. Time-Traveler creates a safe copy of your production setup, runs the migration against that copy, and reports the result. It runs five agents connected by a bridge, with real Google Cloud deployment, real PostgreSQL migrations, and real data.

Most Impactful

RedAgent checks AI-generated security reports, closing the trust gap between AI findings and developer action. If your team uses AI for security scanning, you know this problem. I have seen teams dismiss AI findings because they could not verify them. RedAgent gives teams a way to check AI output before it reaches developers.

Easiest to Use

Launch Control delivers polished UX and solid infrastructure, and scored well on sustainability too.

The sustainability signal

Five projects won prizes or bonuses for environmental impact. Software delivery has a carbon cost as CI/CD pipelines, but now LLMs also run compute at scale. We created the Green Agent category to challenge developers to measure and reduce that footprint. Stacy Cline and Kim Buncle from GitLab's sustainability team helped judge the Green Agent category.

Green Agent prize

GreenPipe scans CI/CD pipelines for environmental impact and produces carbon footprint reports. Judges Kim Buncle and Rajesh Agadi (Google) both backed the project.

Sustainable Design bonus

Sustainable Design bonuses were awarded to the projects with exceptional sustainability practices in their design, from model optimization techniques to energy-efficient architecture choices.

• BugFlow turned one bug report into 10 fixes in 20 minutes.
• DELTA Cyber Reasoning is automated fuzz testing for security.
• CarbonLint applied code analysis to energy use.
• TFGuardian features a carbon footprint analyzer, among other agents.

Congratulations on all the Sustainable Design bonus winners!

Judge Jens-Joris Decorte (TechWolf) cited the result: Costs dropped from $556 to $18 per month, a 96% carbon cut (that is a $538 monthly saving with a sustainability label on it).

Honorable mentions and the long tail

Six projects received honorable mentions:

• SecurityMonkey injects known vulnerabilities into a test branch and scores how well your security scanners catch them.
• stregent monitors CI/CD pipelines and lets developers investigate and merge fixes from WhatsApp without opening a laptop.
• Compliance Sentinel scores every merge request for compliance risk and blocks the merge if critical violations are detected.
• Carbon Tracker calculates the carbon footprint of each CI/CD pipeline job and posts optimization tips on the merge request.
• RepoWarden is the first Living Specification Engine, an AI system that captures why code was written, not just what it does.
• MR Compliance Auditor collects evidence across merge requests, maps it to SOC 2 controls, and streams compliance scores to a live dashboard.

My favorite quote from the judging came from Luca Chun Lun Lit (Anthropic), who described stregent's mobile-first approach: "Being able to essentially code from your phone is a next level in the engineering experience."

Explore the 600+ entries in the project gallery.

What comes next

Every agent in this hackathon worked within a single project. They still delivered impressive results. Some participants ran a local knowledge graph alongside their agents to surface code relationships and dependencies within the repo. LORE captures project history. Gitdefender finds vulnerabilities. Pairing agents with richer local context is already helping contributors build sharper tools. The next hackathon will build on what contributors are already doing with richer context. Sign up on contributors.gitlab.com to be the first to know when details drop.

Get started

A special thanks to Lee Tickett (GitLab) and Mattias Michaux (GitLab) for orchestrating the orchestrators and innovators behind this hackathon!

Thank you to every developer who submitted. Nearly 7,000 of you showed what GitLab Duo Agent Platform can do when a community decides to build. I am proud of what you built here, and I cannot wait to see what you build next.

Build your own agent on GitLab Duo Agent Platform. Browse community-built agents in the AI Catalog. You orchestrate. AI accelerates.

GitLab Duo Agent Platform enables you to handle planning, merge pipelines, security scanning, vulnerability remediation, and more as part of your GitLab workflows, while the GitLab AI Gateway routes model calls to Bedrock (or GitLab-managed Bedrock-backed endpoints, depending on your setup). That means you can build on the identity and access management (IAM) policies, virtual private cloud (VPC) boundaries, regional controls, and cloud spend commitments you already have in AWS.

If you already use Amazon Bedrock and want AI to help inside the work you already do in GitLab, not in yet another standalone chat tool, this is the pairing for you.

In this article, we look at the real problem many teams face today: AI is fragmented, data paths are fuzzy, and Bedrock investment gets underused when AI sits outside the software development lifecycle. Then we break down your deployment options for GitLab Duo Agent Platform:

• Integrated with self-hosted models on Amazon Bedrock for GitLab Self-Managed deployments and self-hosted AI gateway
• Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab Self-Managed deployments and GitLab-hosted AI gateway
• Integrated with GitLab-operated models on Amazon Bedrock (with GitLab-owned keys) for GitLab.com instances and GitLab-hosted AI gateway

We wrap with a summary on how this approach helps avoid shadow AI and point-tool sprawl without creating a parallel tech stack for AI tooling.

AI everywhere, control nowhere

Somewhere in your company right now, software teams might be using an AI tool that your security team hasn't approved. Prompt data might be leaving your environment through a path no one has fully mapped. And your organization’s Amazon Bedrock investment might be underused while individual teams expense separate AI tools, pulling workloads and cloud spend away from the platforms you’ve already committed to.

Instead of being a people problem, this might be an architecture problem. And it surfaces the same three constraints in nearly every enterprise:

Operational fragmentation. Each team, or sometimes even an individual developer, picks their own development toolset, including AI tooling and model selection. That fragmentation makes end-to-end governance within the software development lifecycle nearly impossible.

Security and sovereignty. Where does prompt and code data actually flow? Who owns the logs?

Cloud spend optimization. Commitments to key cloud providers like AWS are diluted as workloads and AI usage drift to point tools outside of customers’ existing agreements.

GitLab Duo Agent Platform and Amazon Bedrock help solve this together. The division of labor is straightforward: Duo Agent Platform owns the workflow orchestration with agentic AI for software development, Bedrock owns the inference layer and hosts approved foundational models, and your organization has full control over the data and policy boundaries you already defined in AWS. Three jobs, three owners, no fragmentation.

GitLab Duo Agent Platform: The agentic control plane

GitLab Duo Agent Platform is GitLab's agentic AI layer: a framework of specialized agents and flows that operate simultaneously and in-parallel, going beyond the traditional stage-based handoffs and helping automate work across the entire software lifecycle. Rather than a single assistant responding to prompts, Duo Agent Platform enables teams to orchestrate many AI agents asynchronously using unified data and project context, including issues, merge requests, pipelines, and security findings. Linear workflows are turned into coordinated, continuous collaboration between software teams and their AI agents, at scale.

With that control plane in place, the natural next question is which AI foundation should power these agents. For customers who run GitLab Self-Managed on AWS and need inference traffic, prompt data, and logs to also stay within their AWS environment along with their software lifecycle data, Amazon Bedrock acting as the AI inference layer is the natural fit.

Amazon Bedrock: The trusted AI foundation

Amazon Bedrock is a fully managed, serverless foundation model layer that runs entirely within your AWS environment. Customer data stays in the customer's AWS account: inputs and outputs are encrypted in transit and at rest, never shared with model providers, and never used to train base models. Bedrock carries compliance certifications across GDPR, HIPAA, and FedRAMP High, covering many regulated industry requirements out of the box. Teams can also bring fine-tuned models from elsewhere via Custom Model Import and deploy them alongside native Bedrock models through the same infrastructure, without managing separate deployment pipelines. Bedrock Guardrails adds configurable safeguards across all models for content filtering, hallucination detection, and sensitive data protection.

Together, GitLab Duo Agent Platform and Bedrock consolidate DevSecOps orchestration and AI model governance, helping eliminate the fragmentation that happens when teams roll out AI tools independently.

Choosing your deployment path

The integration delivers the same core GitLab Duo Agent Platform capabilities regardless of how it is deployed. What varies is who runs GitLab, who operates the AI Gateway, and whose Bedrock account the inference runs through. The right pattern depends on where your organization already operates.

At a high level, the integration has three main components:

• GitLab Duo Agent Platform: agentic workflows embedded across the software development lifecycle
• AI Gateway (GitLab-managed or self-hosted): the abstraction layer between Duo Agent Platform and the foundational model backend
• Amazon Bedrock: the AI model and inference substrate

Choosing a deployment pattern is informed by where an organization wants to place the levers of control. The patterns below are designed to meet teams where they already are, whether that's SaaS-first, self-managed for compliance, or all-in on AWS with existing Bedrock investments.

How customers use GitLab Duo Agent Platform with Amazon Bedrock

Platform teams can use GitLab Duo Agent Platform with Amazon Bedrock to standardize which models handle code suggestions, security analysis, and pipeline remediation. This helps enforce guardrails and logging centrally rather than letting individual teams adopt separate tools independently.

Security workflows see particular benefit. GitLab Duo Agent Platform agents can propose and validate fixes for security findings within GitLab, helping reduce the manual triage work developers would otherwise handle outside the platform.

For enterprises already committed to AWS, routing AI workloads through Bedrock from within GitLab enables you to keep developer AI usage aligned with existing cloud agreements rather than generating separate, unplanned spend.

Closing the loop

The constraints that slow enterprise AI adoption are often not technical. They are organizational: fragmented tooling, ungoverned data flows, and cloud spend that never consolidates. Those are the problems that can stall AI programs even after the pilots succeed.

GitLab Duo Agent Platform and Amazon Bedrock help address each one directly. Platform teams get consistent governance, auditability, and standardized paths for AI usage across the software development lifecycle. Development teams get streamlined, agentic workflows that feel native to GitLab. And AWS-centric organizations get to extend their existing Bedrock investment rather than build parallel AI infrastructure alongside it.

The result is an AI program that scales without fragmenting. Governance and velocity on the same stack, serving the same teams, under policies the organization already owns.

To explore which deployment pattern is right for your organization and how to align GitLab Duo Agent Platform and Amazon Bedrock with your existing AWS strategy, contact the GitLab sales team and we’ll help you design and implement the best architecture for your environment. You can also visit our AWS partner page to learn more.

Pluggable Object Databases

Git already has the ability to store references with either the "files" backend or with the "reftable" backend. This is achieved by having proper abstractions in Git that allows us to have different backends.

But references are just one of the two important types of data that are stored in repositories, with the other being objects. Objects are stored in the object database, and each object database in turn consists of multiple object sources where objects can be read from or written to. Each object source either stores individual objects as so-called "loose" objects, or compresses multiple objects into a "packfile" in your .git/objects directory.

Until now, however, these sources did not have a proper abstraction boundary, so the storage format for objects is completely hardcoded into Git. But this is finally changing with pluggable object databases! The concept is straightforward and similar to how we did this for references in the past: Instead of having hardcoded code paths for how to store objects, we introduce an abstraction boundary that allows us to have different backends for storing objects.

While the idea is simple, the implementation is not, as we have hardcoded assumptions about the storage formats used in Git all over the place. In fact, we have started working on this topic in Git 2.48, which was released in January 2025. Initially, we focused on making object-related subsystems self-contained and creating proper subsystems for the existing backends that we had in Git.

With Git 2.54, we have now reached a milestone: The object database backend is now pluggable. Not all of Git's functionality is covered yet, but introducing an alternate backend that handles a meaningful subset of operations is now a realistic undertaking.

For now, only local workflows like creating commits, showing commit graphs, or performing merges will work with such an alternative implementation. This notably excludes anything that interacts with a remote, such as when you want to fetch or push changes. Regardless, this is the culmination of almost two years of work spanning across almost 400 commits that have been merged upstream, and we will of course continue to iterate on this effort.

So why does this matter? The idea is that it becomes practical to introduce new storage formats into Git. Examples could be:

• A storage format that is able to store large binary files more efficiently than packfiles do today
• A storage format that is custom-tailored for GitLab to ensure that we can serve repositories to our users even more efficiently than we currently can

This is a large-scale effort that is likely to shape the future of Git and GitLab.

This project was led by Patrick Steinhardt.

Easier editing of your commit history

In many software development projects it is common practice for developers to not only polish the code they want to contribute, but to also polish the commit history so that it becomes easy to review. The result is a set of small and atomic commits that each do one thing, with a good commit message that describes the intent of the commit as well as specific nuances.

Of course, more often than not, these atomic commits are not something that just happens naturally during the development process. Instead, the author of the changes will gain a better understanding of what they are while iterating on them, and the way to split up the commits will become clearer over time. Furthermore, the subsequent review process may result in feedback that requires changes to the crafted commits.

The consequence of this process is that the developer will have to rewrite their commit history many times during the development process. Historically, Git has allowed for this use case via interactive rebases. These interactive rebases are an extremely powerful tool: They let you reorder commits, rewrite commit messages, squash multiple commits together, or perform arbitrary edits of any commit.

But they are also somewhat arcane and hard to understand. The user needs to figure out the base commit for the rebase, they need to understand how to edit a somewhat obscure "instruction sheet," and they need to be aware of how the stateful rebasing process works. For example, users are presented with an instruction sheet similar to the following when rebasing a topic branch:

pick b60623f382 # t: detect errors outside of test cases # empty
pick b80cb55882 # t: prepare `test_match_signal ()` calls for `set -e`
pick 5ffe397f30 # t: prepare `test_must_fail ()` for `set -e`
pick 5e9b0cf5e1 # t: prepare `stop_git_daemon ()` for `set -e`
pick 299561e7a2 # t: prepare `git config --unset` calls for `set -e`
pick ed0e7ca2b5 # t: detect errors outside of test cases

So while interactive rebases are powerful, they are also quite intimidating for the average user.

It doesn't have to be this way, though. Tools like Jujutsu provide interfaces that are much easier to use compared to Git, as you can for example simply execute jj split to split up a commit into two commits. With Git and interactive rebases, this use case requires a lot of different steps with confusing command line arguments.

We have thus taken inspiration from Jujutsu and have introduced a new git-history(1) command into Git that is the foundation for better history editing. For now, this command has two subcommands:

• git history reword allows you to easily rewrite a commit message. You simply give it the commit whose message you want to reword, Git asks you for the new commit message, and that's it.
• git history split allows you to split up a commit into two, which is inspired by jj split. You give it a commit, Git asks you which changes to stage into which commit and for the two commit messages, and then you're done.

This is of course only a start, and we want to add additional subcommands over time. For example:

• git history fixup to take staged changes and automatically amend them to a specific commit
• git history drop to remove a commit
• git history reorder to reorder the sequence of commits
• git history squash to squash a range of commits

But that's not all! In addition to making history editing easy, this new command also knows to automatically rebase all of your local branches that previously included this commit. So that means that you can even edit a commit that is not on the current branch, and all branches that contain the commit will be rewritten.

It may seem puzzling at first that Git is automatically rebasing dependent branches, as that is a significant diversion from how git-rebase(1) works. But this is part of a bigger effort to bring better support for Stacked Diffs to Git, which are a way to create a series of multiple dependent branches that can be reviewed independently, but that together work towards a bigger goal.

This project was led by Patrick Steinhardt with support from Elijah Newren.

A native replacement for git-sizer(1)

The size of a Git repository is an important factor that determines how well Git and GitLab can handle it. But size alone is not the only factor, as the performance of a repository is ultimately a combination of multiple different dimensions:

• The depth of the commit history
• The shape of the directory structure
• The size of files stored in the repository
• The number of references

These are only some of the dimensions one needs to consider when trying to predict whether Git will be able to handle a repository well.

But while it is clear that the mere repository size is insufficient, Git itself does not provide any tooling that gives the user an easy overview of these metrics. Instead, users are forced to rely on third-party tools like git-sizer(1) to fill this gap. This tool does an excellent job at surfacing this information, but it is not part of Git itself and thus needs to be installed separately.

Observability of repository internals is critical to us at GitLab, so we introduced a new git repo structure command into Git 2.52 to display repository metrics, which we have extended in Git 2.53 to show inflated and disk sizes for objects by type.

In Git 2.54, we are now iterating some more on this command so that we don't only show the overall size, but also show the largest objects by type:

$ git clone https://gitlab.com/git-scm/git.git
$ cd git
$ git repo structure
Counting objects: 410445, done.
| Repository structure      | Value       |
| ------------------------- | ----------- |
| * References              |             |
|   * Count                 |    1.01 k   |
|     * Branches            |       1     |
|     * Tags                |    1.00 k   |
|     * Remotes             |       9     |
|     * Others              |       0     |
|                           |             |
| * Reachable objects       |             |
|   * Count                 |  410.45 k   |
|     * Commits             |   83.99 k   |
|     * Trees               |  164.46 k   |
|     * Blobs               |  161.00 k   |
|     * Tags                |    1.00 k   |
|   * Inflated size         |    7.46 GiB |
|     * Commits             |   57.53 MiB |
|     * Trees               |    2.33 GiB |
|     * Blobs               |    5.07 GiB |
|     * Tags                |  737.48 KiB |
|   * Disk size             |  181.37 MiB |
|     * Commits             |   33.11 MiB |
|     * Trees               |   40.58 MiB |
|     * Blobs               |  107.11 MiB |
|     * Tags                |  582.67 KiB |
|                           |             |
| * Largest objects         |             |
|   * Commits               |             |
|     * Maximum size    [1] |   17.23 KiB |
|     * Maximum parents [2] |      10     |
|   * Trees                 |             |
|     * Maximum size    [3] |   58.85 KiB |
|     * Maximum entries [4] |    1.18 k   |
|   * Blobs                 |             |
|     * Maximum size    [5] | 1019.51 KiB |
|   * Tags                  |             |

|     * Maximum size    [6] |    7.13 KiB |

[1] f6ecb603ff8af608a417d7724727d6bc3a9dbfdf
[2] 16d7601e176cd53f3c2f02367698d06b85e08879
[3] 203ee97047731b9fd3ad220faa607b6677861a0d
[4] 203ee97047731b9fd3ad220faa607b6677861a0d
[5] aa96f8bc361fd84a1459440f1e7de02ab0dc3543
[6] 07e38db6a5a03690034d27104401f6c8ea40f1fc

With this information we're now almost feature-complete as compared to git-sizer(1). We're not done yet, though — we plan to eventually add additional features such as:

• Severity levels as they exist in git-sizer(1)
• Graphs that show you the distribution of object sizes
• The ability to scan objects reachable via a subset of references

This project was led by Justin Tobler.

New infrastructure for repository maintenance

Whenever you write data into a Git repository you will typically end up adding more loose objects. Left unmanaged, this leads to a large number of separate files in your .git/objects/ directory, which slows down several operations that want to access many objects at once. Git thus regularly packs these objects into "packfiles" to ensure good performance.

This isn't the only data structure that may become inefficient over time: Updating references may create loose references, reflogs will need trimming, worktrees may become stale, and caches like commit-graphs need to be refreshed regularly.

All of these tasks have historically been managed by git-gc(1). However, this tool has a monolithic architecture, where it basically executes all of the tasks required in sequential order. This foundation is hard to extend and doesn't give the end user much flexibility in case they want to slightly modify how housekeeping is performed.

The Git project introduced the new git-maintenance(1) tool in Git 2.29. In contrast to git-gc(1), git-maintenance(1) is not monolithic but is instead structured around tasks. These tasks are freely configurable by the user so that the user can control which tasks are running, giving them much more fine-grained control over repository maintenance.

Eventually, Git has migrated to use git-maintenance(1) by default. But in the beginning, the only task that was default-enabled was the git-gc(1) task, which as you might have guessed, simply executes git gc. To manually run maintenance using this new command you can execute git maintenance run, but Git knows to execute this automatically after several other commands.

Over the last couple releases we have implemented all the individual tasks that are supported by git-gc(1) in git-maintenance(1) to ensure that we have feature parity between these two tools.

Furthermore, we have implemented a new task that uses Git's modern architecture for repacking objects with geometric compaction. Geometric compaction is a much better fit for large monorepos, and with our efforts to make them work well with partial clones that landed in Git 2.53 they are now a full replacement for our previous repacking strategy in Git.

In Git 2.54, we have now reached another significant milestone: Instead of using the git-gc(1)-based strategy by default, we are now using geometric repacking with fine-grained individual maintenance tasks! Besides being more efficient for large monorepos, it also ensures that we have an easier foundation to iterate on going forward.

The git-maintenance(1) infrastructure was originally implemented by Derrick Stolee and geometric maintenance was introduced by Taylor Blau. The effort to introduce the new fine-grained tasks and migrate to the new maintenance strategy was led by Patrick Steinhardt.

Read more

This article highlighted just a few of the contributions made by GitLab and the wider Git community for this latest release. You can learn about these from the official release announcement of the Git project. Also, check out our previous Git release blog posts to see other past highlights of contributions from GitLab team members.

The defender side of the equation hasn't kept pace. One third of exploited Common Vulnerabilities and Exposures (CVEs) in the first half of 2025 showed activity on or before disclosure day, before most teams even know there's something to patch. AI is compressing that window further, accelerating attackers and flooding teams with whitehat disclosures faster than they can triage. Defender tooling has improved, but most organizations can't operationalize it fast enough to close the gap between discovery and exploitation.

When the window between disclosure and exploitation is measured in hours, the security team can't be the last line of defense. Security has to run where code enters the system: in the pipeline, on every merge request, enforced by policy. The fixes that can be automated should be. The ones that can't need to reach the right human faster than they do today.

Known vulnerabilities are already outpacing remediation

The bottleneck isn't detection, it's acting at scale on what teams already know. Sixty percent of breaches in the 2025 Verizon DBIR involved exploiting known vulnerabilities where a patch was already available. Teams couldn’t close them in time.

The backlog was untenable before Mythos. Developers spend 11 hours per month remediating vulnerabilities post-release instead of shipping new work. Over half of organizations have at least one open internet-facing vulnerability, and the median time to close half of those is 361 days. Exploitation takes hours, while remediation takes months.

AI-assisted development is widening the gap, and stakeholders know it. By June 2025, AI-generated code was adding over 10,000 new security findings per month across Fortune 50 repositories, a 10x jump from six months earlier. Georgia Tech identified 34 CVEs attributable to AI-generated code in March 2026, up from 6 in January, and that count reflects only the ones where AI authorship is clear. AI coding assistants hallucinate package names, reach for outdated patterns, and copy insecure examples from training data. More code, more dependencies, and more vulnerabilities per line are generated faster than security teams can review them.

Defenders need to harness frontier AI models, too — not bolted onto the SDLC as external tooling, but running inside the same policies, approvals, and audit trail as the rest of the team.

Security at the speed of AI coding

When a critical CVE drops, how quickly can your team confirm which projects are affected? How many tools does an alert cross before a developer can submit a fix?

The teams that benefit most from AI already have policies, enforcement, and controls embedded in their development workflows. AI amplifies that foundation. It doesn't replace it.

Enforcement at the point of change. As exploitation windows compress, every line of code entering a repository needs to pass through a defined set of controls. Not a separate review, in a different tool, by a different team. Organizations need the ability to enforce security policies across every group and project, with the merge request as the enforcement point. Policies defined once, applied everywhere, with exceptions reviewed, approved, and logged.

Simple issues caught before the merge request, not during. Hardcoded secrets, known-vulnerable imports, and deprecated API calls can be flagged in the IDE before a developer pushes a commit. Catching them at authoring time means fewer findings blocking the MR, so review cycles go to the findings that require cross-component context: reachability, exploitability, and architectural risk.

Triage automated by default, not by exception. Embedding security into every merge request creates a volume problem. More scans, more findings, more noise reaching developers who aren’t trained to distinguish a reachable critical from a theoretical one. AI must handle false positive detection, reachability, exploitability context, and severity assessment before a developer sees the finding, so the findings they see actually warrant their time.

Remediation governed like any other change. AI-based remediation compresses the timeline for closing vulnerabilities, but every generated fix must move through the same governance as a human-authored change: policies enforce scans, the right reviewers approve, and evidence is recorded. GitLab’s automated remediation capability proposes each fix in a merge request with a confidence score. The MR records which policy applied, which scans ran, what they found, and who approved. Human code and AI-generated code move through the same process, with the same audit trail.

What a ready pipeline looks like

Here's how these pieces work together when a high-severity vulnerability is discovered and the clock is running.

A proof-of-concept exploit for a vulnerability in a popular open-source package appears on a security mailing list. There’s no CVE, no National Vulnerability Database (NVD) entry, and no scanner signature yet. The security team finds out the usual way: someone shares it in Slack.

A security engineer asks the security agent if the package is in use, which projects have affected versions, and whether any vulnerable call paths are reachable in production. The agent checks the dependency graph for every project, matches the affected versions and entry points from the disclosure, and returns a ranked list of exposed projects with details about reachability. There’s no need to search through repositories by hand or wait for a scanner update. The question, "Are we exposed?" is answered in minutes.

The engineer starts a remediation campaign for every exposed project. The remediation agent suggests fixes: version updates where a patched release is available, and targeted call-path patches where it is not. Scan execution policies are already in place for projects tagged SOC 2. The engineer hardens the rules to block merges on any merge request that introduces or keeps the affected dependency, and an approval policy now requires security sign-off on every fix. The agent's first proposed patch fails the pipeline when an integration test catches a regression. The agent revises the patch based on the test failure, and the second attempt passes. Developers review the changes, security signs off under the stricter policy, and merges proceed across the campaign.

At the next audit review, the security team presents a report showing how policies were enforced and risks were reduced during the campaign. It includes scan results, policies applied, approvers, and merge timestamps for every MR in every affected project. The evidence was automatically generated in flight, not assembled after the fact.

Close the gaps now

Mythos exists today, and comparable models will be in attacker hands within a year. Every month between now and then is a chance to strengthen your software supply chain.

Ask these questions about your pipeline:

• How do you enforce that security scans run on every merge request, not just the projects where teams configured them?
• If a compromised package entered your dependency tree today, would your pipeline catch it before build?
• When a scanner flags a critical finding, how many tool boundaries does it cross before a developer starts the fix?
• If an AI agent proposed a code fix for a vulnerability, what process would that fix go through before reaching production, and is that process auditable?
• When auditors ask for evidence that a specific policy was enforced on a specific change, how long does it take to produce?

If the answers expose gaps, address them now. Talk to a GitLab solutions architect about the role of security governance in your development lifecycle.

For organizations in regulated industries, including finance, healthcare, defense, and public sector, the policy shift raises questions that go beyond individual developer preferences. It forces a harder look at a question that engineering and security leaders should be asking every AI vendor in their stack: Do you train on our code?

GitLab's answer is no. GitLab does not train AI models on customer code at any tier, and AI vendors are contractually prohibited from using customer inputs or outputs for their own purposes. The GitLab AI Transparency Center makes that commitment auditable: a single location documenting which models power which features, how data is handled, subprocessor relationships, and data retention periods. The GitLab AI Transparency Center also lists the compliance status of each feature, including confirmation that GitLab's current AI features do not qualify as high-risk systems under the EU AI Act. It's a standard GitLab CEO Bill Staples has consistently reiterated and one reflected in GitLab's mission and Trust Center.

What the policy change actually means

GitHub's announcement also specifies that the data may be shared with GitHub affiliates, including Microsoft, for AI development purposes.

A policy change of this nature forces organizations to re-examine their AI governance posture, audit their Copilot license tiers, and confirm that the right controls are configured across their teams.

Why AI governance matters in regulated environments

Source code is often among an organization's most sensitive intellectual property. It may contain references to internal systems, reflect proprietary business logic, or touch data flows governed by strict retention and access policies. When that code passes through an AI assistant, questions about training data usage, model vendor relationships, and data residency become compliance concerns.

The exposure is particularly acute for financial services firms that have invested in proprietary algorithms, fraud detection logic, credit risk models, underwriting rules, trading strategies. When AI tooling processes that code and uses it to train models serving competitors, vendor data practices become an IP concern.

Financial institutions operating under the Federal Reserve's Supervisory Guidance on Model Risk Management (SR 11-7) and the Digital Operational Resilience Act (DORA) are required to maintain documented, auditable oversight of third-party technology providers, including understanding how those providers handle data. Third-party AI tools used in development workflows increasingly fall within the scope of model risk oversight, and material changes to vendor data practices require updated documentation.

In the public sector, the National Institute of Standards and Technology Special Publication 800-53 (NIST 800-53) and the Federal Information Security Modernization Act (FISMA) establish that sensitive or classified code must never leave a controlled boundary. For U.S. Department of Defense and intelligence community environments in particular, a vendor's default data posture is an operational concern. In healthcare, the Health Insurance Portability and Accountability Act (HIPAA) governs how patient-adjacent data is handled by third parties, and development environments that touch clinical systems increasingly fall within that scope.

Across all of these contexts, the common thread is the same: A vendor policy that changes data usage defaults, requires individual opt-out, and offers different protections depending on account tier introduces exactly the kind of uncontrolled variable that compliance teams cannot afford.

What regulated industries actually need from AI vendors

Regulated organizations have largely moved past debating whether to adopt AI in development workflows. The focus now is on doing so in a way they can defend to regulators, boards, and customers. That shift has surfaced a consistent set of requirements regardless of sector.

Contractual certainty. Regulated firms need to know, with specificity, what happens to their data. A clear, documented, unconditional commitment is what's required, not something that varies by plan or requires action before a deadline.

Auditability. Model risk management frameworks require organizations to understand and validate the AI systems they deploy, including the training data behind those models and the third parties involved in their development. Vendors who cannot answer these questions create documentation risk for the organizations relying on them.

Separation from vendor incentives. When an AI vendor trains models on customer usage data, code and workflows become inputs to a system that also serves competitors. For institutions with proprietary trading logic, underwriting models, or fraud detection systems, that's a genuine IP exposure.

GitLab's position on AI data governance

GitLab does not use customer code to train AI models. This commitment applies at every tier, and AI vendors are contractually prohibited from using inputs or outputs associated with GitLab customers for their own purposes.

This is a deliberate architectural and policy choice, not a feature of a particular pricing tier. As GitLab's post on enterprise independence notes, data governance has become "an increasingly critical factor in enterprise technology decisions, driven by a complex web of national and regional data protection laws and growing concern about control over sensitive intellectual property."

GitLab is also cloud-neutral and model-neutral while supporting self-hosted deployments, not commercially tied to any single cloud provider or large language model (LLM). That independence matters for regulated organizations evaluating vendor concentration risk. The AI Continuity Plan documents how vendor changes are managed, including material changes to how AI vendors treat customer data, a direct response to the governance requirements under frameworks like DORA.

The governance gap AI teams need to close

GitHub's policy update is a reminder that for organizations in regulated industries, understanding exactly how an AI tool handles data is a prerequisite for using it at all. That means asking vendors for clear, documented answers: Is our data used for model training? Who are your AI model subprocessors? What happens if a vendor changes its data practices? Can we deploy in a way that keeps all AI processing within our own infrastructure? What indemnification do you offer for AI-generated output?

Vendors who can answer those questions clearly, and document those answers in an auditable form, are vendors you can build on. Those who cannot will create compliance debt every time they ship a policy update. And when a vendor can change its data practices with 30 days notice, that's not a partnership built for regulated industries. That's a liability.

Learn more about GitLab's approach to AI governance at the GitLab AI Transparency Center.

One of the greatest barriers to broader AI adoption isn't skepticism about the technology. It's uncertainty about managing spend. Without budget caps, a busy month could produce unexpected expenses. Without per-user limits, a handful of power users could burn through the team's credits before the month is over. And without either, engineering leaders who want to expand their use of agentic AI for software development have to jump through more hoops for budget approval.

Since its general availability, GitLab Duo Agent Platform has provided usage governance and visibility. With GitLab 18.11, we're introducing usage controls for GitLab Credits: spending caps and budget guardrails that give your organization even more control and transparency over how credits are consumed.

Managing GitLab Credits

GitLab 18.11 adds three layers of control over GitLab Credits consumption: a subscription-level spending cap, per-user credit limits, and visibility into cap status and enforcement.

Subscription-level spending cap

Billing account managers can now set a hard monthly ceiling for on-demand GitLab Credits consumption for their entire subscription.

Here's how it works:

• Set a cap in the Customers Portal under your subscription's GitLab Credits settings.
• Enforce spend limits automatically. When on-demand usage reaches the cap, DAP access is paused for all users on that subscription until the next monthly period begins.
• Make adjustments as you go. Raise or disable the cap mid-month to restore access.

The cap resets each monthly period and your configured limit carries forward unless you change it. Because usage data is synchronized periodically rather than in real time, a small amount of additional usage may occur after the cap is reached before enforcement takes effect. See the GitLab Credits documentation for details.

User-level spending caps

Not every user consumes credits at the same rate, and that's expected. But when one or two power users account for a disproportionate share of the pool, the rest of the team can lose access before the month is over.

Per-user credit caps prevent any single user from consuming more than their fair share:

• Flat per-user cap. Set a uniform credit limit that applies equally to every user on the subscription through the GitLab GraphQL API. Unlike the subscription-level cap, the per-user cap applies to a user's total consumption across all credit sources.
• Custom per-user overrides. For organizations that need differentiated limits, you can set individual credit caps for specific users through the GraphQL API. For example, you could give your staff engineers a higher allocation while applying a standard limit to the broader team.
• Individual enforcement. When a user reaches their cap, they retain full access to GitLab. Only their Duo Agent Platform credit usage is paused until the next billing cycle. Everyone else keeps working uninterrupted until they hit their own limit or the subscription-level cap is reached, whichever comes first.

Visibility and notifications

When a subscription-level cap is reached, GitLab sends an email notification to billing account managers so they can take action: raise the cap, wait for the next period, or redistribute credits.

Within GitLab, group owners (GitLab.com) and instance administrators (Self-Managed) can view which users have been blocked due to reaching their per-user cap and restore access by adjusting the cap through the GraphQL API.

How budget guardrails help organizations scale AI usage

Guardrails are essential as organizations ramp up their AI adoption. Here's why:

Predictable AI budgets

Usage controls for GitLab Duo Agent Platform turn AI into a bounded, predictable budget item using on-demand GitLab Credits. That makes it easier to deploy agents across the software development lifecycle and get sign-off from finance, justify renewals, and plan quarterly spend.

Governance and chargeback

Large organizations often need to align AI consumption with internal budgets, cost centers, or departmental policies. Per-user caps give platform teams a straightforward mechanism to allocate credits fairly and track consumption at the individual level. The API import options make it practical to manage caps at enterprise scale. Combined with per-user usage data from the GitLab Credits dashboard, organizations can track consumption patterns to inform their own internal chargeback or budget allocation processes.

Confidence to scale

Many customers start GitLab Duo Agent Platform with a small pilot group. Usage controls remove risks associated with expanding that pilot across the organization. You can roll out Duo Agent Platform to hundreds or thousands of developers knowing there's a hard ceiling protecting your budget. If usage grows faster than expected, you'll hit the cap, not an unexpected invoice.

Addressing the seat-based and visibility conundrum

Many AI coding tools take a seat-based approach to cost management. You buy a fixed number of seats at a flat per-user price, and that's your budget. It's simple, but rigid. You pay the same whether a developer uses the tool ten times a day or never touches it. And as vendors introduce premium models and usage-based overages on top of seat pricing, the cost predictability that seat-based licensing promised starts to erode.

GitLab takes a different approach. Usage-based pricing with hard caps and a single governance dashboard. You get the flexibility of paying for what your teams actually use, with the budget predictability of enforced spending limits.

Real-world usage controls

One example is a mid-size SaaS customer that wants to protect their monthly budget. A 200-person engineering organization sets a subscription-level cap equal to their expected on-demand usage. Their VP of Engineering can confidently tell finance that GitLab Duo Agent Platform spend will never exceed the approved amount, even as they onboard new teams. If they approach the cap mid-month, the billing account manager gets a notification and can decide whether to raise the limit or wait for the next period.

At GitLab, we also work with large enterprises that want to keep usage fair across teams. A global financial services company with 2,000 developers uses per-user caps to ensure equitable access. Staff engineers working on complex refactoring projects get a higher individual allocation via API, while most developers receive a standard flat cap. No single user can exhaust the pool, and the platform team uses the per-user usage data in the GitLab Credits dashboard to track consumption patterns and inform quarterly budget planning.

Getting started

Usage controls are available for both GitLab.com and Self-Managed customers running GitLab 18.11. Different controls are configured in different places depending on the scope and your role.

Subscription-level cap

Billing account managers set the subscription-level on-demand cap in the Customers Portal:

1. Sign in to the Customers Portal.
2. On your subscription card, navigate to GitLab Credits settings.
3. Enable the monthly on-demand credits cap and enter your desired limit.

Flat per-user cap

The flat per-user cap can be set through the GitLab GraphQL API by namespace owners (GitLab.com) or instance administrators (Self-Managed). Check the GitLab Credits documentation for the latest on available configuration surfaces.

Custom per-user overrides

For differentiated limits, namespace owners (GitLab.com) and instance administrators (Self-Managed) can set individual caps programmatically. This is useful for automation and infrastructure-as-code workflows.

Monitor usage and cap status

• Customers Portal: View detailed usage and cap status.
• GitLab.com: Group owners can view blocked users under Settings > GitLab Credits.
• Self-Managed: Instance administrators can view cap status and blocked users under Admin > GitLab Credits.

GitLab Duo Agent Platform is ready to scale

Usage controls are available now in GitLab 18.11. If you've been waiting for the right guardrails before expanding GitLab Duo Agent Platform across your organization, this is your moment. Set your caps, roll out Duo Agent Platform to more teams, and start shipping faster!

Learn more about GitLab Credits and usage controls.

For teams running agents across the full software delivery lifecycle, Opus 4.7 brings meaningful improvements to the tasks that matter most: the complex, multistep work that requires sustained reasoning, precise instruction following, and the ability to verify its own outputs before surfacing results.

Stronger reasoning across every agent workflow

The most significant gain is in how Opus 4.7 handles difficult, long-running work. GitLab's internal evaluations showed improved performance over both Sonnet 4.6 and Opus 4.6. That combination translates directly to agents that work more efficiently across CI/CD pipelines, code review, vulnerability resolution, and other multi-tool workflows where compounding errors are costly.

Teams with established agent workflows should note that Opus 4.7 interprets instructions more precisely than prior models, which means it executes more faithfully on complex, conditional tasks. For example, agents handling multistep remediation sequences complete each step as specified, giving teams more predictable, auditable outcomes.

Agents keep work moving from code to production

The promise of agents embedded across every stage of the software development lifecycle is that work stops waiting on people to move it forward. Opus 4.7 helps make that promise more reliable in practice.

At the code generation and test creation stage, agents benefit from Opus 4.7's ability to verify its own outputs before surfacing results. Less back-and-forth, faster iteration, fewer interruptions that pull developers out of flow. In security and vulnerability workflows, stronger instruction adherence means agents stay on task through multistep remediation sequences, completing the work as scoped rather than requiring course corrections along the way.

In CI/CD, where pipeline failures can become team-wide blockers, Opus 4.7's long-horizon consistency matters most. Agents investigating failures, analyzing logs, and proposing fixes work through that sequence coherently, without losing context mid-run. The work gets resolved rather than escalated.

GitLab Duo Agent Platform connects these stages by design. Opus 4.7 strengthens the intelligence layer that runs across all of them, so agents coordinating across planning, development, security, and deployment have a more capable model driving decisions at every handoff.

Pricing and availability

Claude Opus 4.7 is available now in GitLab Duo Agent Platform via model selection. For a full list of models available for Duo Agent Platform along with their respective credit consumption, please visit our documentation.

You can start a free trial of GitLab Duo Agent Platform today. If you are already using GitLab in the free tier, you can sign up for Duo Agent Platform by following a few simple steps.

And if you are an existing subscriber to GitLab Premium or Ultimate, you can simply turn on Duo Agent Platform and start using the GitLab Credits that are included with your subscription.

This blog post contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934. Although we believe that the expectations reflected in these statements are reasonable, they are subject to known and unknown risks, uncertainties, assumptions and other factors that may cause actual results or outcomes to differ materially. Further information on these risks and other factors is included under the caption "Risk Factors" in our filings with the SEC. We do not undertake any obligation to update or revise these statements after the date of this blog post, except as required by law.

In GitLab 18.11, two new foundational agents for Duo Agent Platform address specific gaps in the development lifecycle that AI has largely left untouched:

• CI Expert Agent (now in beta) focuses on the gap between writing code and getting it into a running pipeline
• Data Analyst Agent (now generally available) focuses on the gap between shipping code and being able to answer basic questions about how that delivery is actually going.

These are problem areas that couldn't be solved by a general-purpose assistant. A tool running outside GitLab can generate a YAML file or answer a question, but it has no awareness of how your pipelines have historically performed, where failures cluster, or what your actual MR cycle times look like. That context lives in GitLab. These agents do too.

Fast CI setup with CI Expert Agent

AI has made it easier than ever to write code. Getting that code into a running pipeline is still something most teams do days, or weeks, later — if at all. The blank-page problem isn't in the editor anymore. The blank page is now in .gitlab-ci.yml.

Developers who have never configured CI don't know what language detection looks like in YAML, what their test commands should be, or how to validate the result before pushing. Teams either copy a config from a previous project that may not fit, stitch together examples from documentation, or wait for the one person who's done it before. If that person isn't available, CI becomes the thing you'll "get to later." Later becomes never.

When CI never happens, the impact shows up everywhere else. Changes ship without a reliable safety net, regressions surface in production instead of in pipelines, and work piles up in bigger, riskier batches because no one wants to be the person who “breaks the build.” Over time, teams normalize working in the dark, often relying on undocumented institutional knowledge and ad-hoc testing, instead of having a fast, predictable feedback loop baked into every change.

CI Expert Agent, now available in beta, removes that friction. It inspects your repository, identifies your language and framework, and proposes a working build and test pipeline tailored to what's actually there — then explains every decision in plain language. The target: a running pipeline in minutes, with no YAML written by hand.

What CI Expert Agent does:

• Repo-aware pipeline generation detects language, framework, and test setup
• Generates valid, runnable build and test configurations
• Guided first-pipeline flow with plain-language explanation of each step in Agentic Chat
• Native GitLab CI semantics with no config translation required

Because it runs inside GitLab and sees real pipeline behavior over time, each improvement can build on how teams actually work, not just on static examples.

CI Expert Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium, Ultimate Editions with Duo Agent Platform enabled.

Query GitLab data in plain language with Data Analyst Agent

AI has sped up how teams ship. Answering basic questions about how that work is going has gotten harder, not easier.

How long are MRs sitting in review? Which pipelines are slowing teams down? Are deployment targets actually being hit? These questions used to be answerable by glancing at a dashboard. Now, with more code, more teams, and more complexity, the data exists — it's in GitLab — but accessing it still means waiting on an analytics team, filing a dashboard request, or learning GLQL.

Data Analyst Agent targets that gap. Ask a natural-language question and get an instant visualization in Agentic Chat. No query language, no dashboard request, no waiting for the answers to be assembled by someone else.

For example, the agent can answer questions about the following topics for these roles:

• Engineering managers: MR cycle time, throughput by project, where reviews get stuck
• Developers: Contribution patterns, flaky tests blocking their MRs, pipeline speed trends
• DevOps and platform engineers: Pipeline success/failure rates, runner utilization, deployment frequency
• Engineering leadership: Cross-portfolio deployment frequency, project health metrics, lead time comparisons

Now generally available in 18.11, the agent covers MRs, issues, projects, pipelines, and jobs — full software development lifecycle coverage, expanded from the beta scope. Because Data Analyst Agent queries what's already in GitLab, the context is always current, and there's no pipeline to maintain or third-party tool to keep synchronized. Generated GitLab Query Language queries can be copied and used anywhere GitLab Flavored Markdown is supported, with direct export to work items and dashboards on the roadmap.

Data Analyst Agent is available on GitLab.com, Self-Managed, Dedicated; Free, Premium and Ultimate Edition with Duo Agent Platform enabled.

One platform, connected context

Both agents run inside GitLab, with access to the code, pipelines, issues, and merge requests already there. That's what separates platform-native AI from a disconnected assistant: the context is always current, and it only gets more useful over time. CI Expert Agent and Data Analyst Agent represent two concrete steps toward a platform where AI doesn't just help you write code faster; it helps you understand, ship, and maintain what gets built.

Start a free trial of GitLab Duo Agent Platform to experience these foundational AI agents.

Now generally available, Agentic SAST Vulnerability Resolution automatically generates ready-to-merge code fixes to remediate SAST vulnerabilities. With this capability:

• Developers stay in flow
• Vulnerabilities get resolved before they reach production
• AppSec teams spend less time on triage and chasing down developers to close the loop

Agentic SAST Vulnerability Resolution is the future of application security. GitLab 18.11 also delivers faster SAST scanning, smarter prioritization, and tighter governance across the platform.

Auto-remediation without breaking your flow

When AI is generating code at scale, the math changes. A security backlog that once grew linearly now compounds with every model-assisted commit. There is no version of this problem that gets solved by asking developers to context-switch more and continue manually remediating vulnerabilities. According to GitLab's 2025 DevSecOps Report, developers already spend 11 hours per month remediating vulnerabilities post-release — that is, fixing issues that are already exploitable in production instead of shipping new work.

Agentic SAST Vulnerability Resolution changes the economics of that cycle. When a SAST scan completes, findings automatically kick off the SAST false positive detection flow. Confirmed true positives go directly into the Agentic SAST Vulnerability Resolution Flow, where GitLab Duo Agent Platform:

• Analyzes the vulnerability in context
• Generates a fix that addresses the root cause
• Validates the fix through automated testing

The developer receives a ready-to-merge MR with a confidence score so they can make an informed decision on how to remediate the vulnerability. The sprint stays on track, developers stay in flow, and vulnerabilities get resolved before they ever reach production.

Accelerating software production also means not waiting on your scanner. GitLab 18.11 introduces incremental scanning for Advanced SAST, so developers get vulnerability results without waiting for a full scan to complete, and pipelines keep moving.

Remediate by business risk, not just by score

Autonomous remediation only works if the signal driving it is trustworthy. When severity scores don't reflect real exploitability, developers stop trusting the signal and start ignoring it.

GitLab 18.11 addresses this issue on four levels. First, vulnerability scores are now grounded in Common Vulnerability Scoring System (CVSS) 4.0, the most current industry standard, with more granular metrics that better capture real-world exploitability. The score developers see in GitLab reflects the most current industry standard for measuring real-world risk.

From there, AppSec teams can define policy-based rules that automatically adjust vulnerability severity scores based on signals like Common Vulnerabilities and Exposures (CVE), Common Weakness Enumeration (CWE), and file path/directory. Once a policy is set, the severity overrides apply immediately so developers work from a backlog that reflects actual business risk, not raw scanner output.

Risk-based enforcement doesn't stop at the backlog. AppSec teams can now configure approval policies to block or warn based on Known Exploited Vulnerabilities (KEV) status or Exploit Prediction Scoring System (EPSS) score thresholds. When a merge gets blocked, developers know it's because the vulnerability has real-world exploitability data behind it, not a score that didn't account for their environment.

Lastly, the new Top CWEs security dashboard chart gives teams visibility into which vulnerability classes are appearing most frequently across their projects. Instead of chasing individual findings, teams can identify patterns, prioritize at the root cause-level, and address systemic risk before it compounds.

Stronger security controls with less operational overhead

An autonomous remediation pipeline is only as good as the security scanner coverage underneath it. If the scanner enablement is inconsistent, the findings flowing into the pipeline are incomplete and so are the fixes.

GitLab 18.11 introduces Security Manager, a new default role built specifically for security professionals. With the Security Manager role, security teams can enforce security scanners, define and configure security policies, manage vulnerability triage and remediation workflows, and maintain compliance frameworks and audit streams, without needing code modification or deployment permissions. Security teams get the access necessary for their jobs, and no more, keeping permissions scoped to the work at hand and keeping code and deployment permissions with developers.

For AppSec teams, getting consistent SAST scanner coverage across multiple projects and groups just got significantly easier. SAST configuration profiles give security teams a single place to define scanning once and apply it across every project in a group in one action. Teams no longer have to write and maintain YAML policy files, depend on developers to configure scanners, or manually check each project to find coverage gaps.

Get started with agentic vulnerability remediation today

GitLab 18.11 delivers the full vulnerability workflow in one platform: AI that automatically remediates vulnerabilities, smarter prioritization that cuts through vulnerability noise, and governance controls that give security teams the right access and coverage at scale.

To see how GitLab Duo Agent Platform puts automated remediation directly in your developer workflow, start a free trial of GitLab Ultimate today.

We know that managing breaking changes across a major upgrade is time-consuming: It requires investigation and coordination across your organization. In response, we introduced a breaking change approval requirement that mandates impact mitigation and leadership sign-off before any breaking change can proceed. That process is working, and we're committed to continuing to drive that number down.

Below you'll find every breaking change in GitLab 19.0, organized by deployment type and impact, alongside the mitigation steps you need to upgrade with confidence.

Deployment windows

Here are the deployment windows you need to know.

GitLab.com

Breaking changes for GitLab.com will be limited to these two windows:

• May 4–6, 2026 (09:00–22:00 UTC) — primary window
• May 11–13, 2026 (09:00–22:00 UTC) — contingency fallback

Many other changes will continue to roll out throughout the month. You can learn more about the breaking changes occurring within each of these windows in the breaking changes documentation.

Note: Breaking changes may fall slightly outside of these windows in exceptional circumstances.

GitLab Self-Managed

GitLab 19.0 will be available starting on May 21, 2026.

Learn more about the release schedule.

GitLab Dedicated

The upgrade to GitLab 19.0 will take place during your assigned maintenance window. You can learn more and find your assigned maintenance window in your Switchboard portal. GitLab Dedicated instances are kept on release N-1, so the upgrade to GitLab 19.0 will take place in the maintenance window during the week of June 22, 2026.

Visit the Deprecations page to see a full list of items scheduled for removal in GitLab 19.0. Read on to learn what's coming and how to prepare for this year's release based on your specific deployment.

Breaking changes

Here are the breaking changes that are high impact.

High impact

1. Support for NGINX Ingress replaced by Gateway API with Envoy Gateway

GitLab Self-Managed (Helm chart)

The GitLab Helm chart has bundled NGINX Ingress as the default networking component. NGINX Ingress reached end-of-life in March 2026, and GitLab is now transitioning to Gateway API with Envoy Gateway as the new default.

Starting with GitLab 19.0, Gateway API and the bundled Envoy Gateway become the default networking configuration. If migration to Envoy Gateway is not immediately feasible for your deployment, you can explicitly re-enable the bundled NGINX Ingress, which remains available until its planned removal in GitLab 20.0.

This change does not impact:

• The NGINX used in the Linux package
• GitLab Helm chart and GitLab Operator instances that use an externally managed Ingress or Gateway API controller

GitLab will provide best-effort security maintenance for the forked NGINX Ingress chart and builds until full removal. To ensure a smooth transition, plan your migration to the provided Gateway API solution or an externally managed Ingress controller ahead of the 19.0 upgrade.

Deprecation notice

2. Removal of bundled PostgreSQL, Redis, and MinIO from the GitLab Helm chart

GitLab Self-Managed (Helm chart)

The GitLab Helm chart has long bundled Bitnami PostgreSQL, Bitnami Redis, and a fork of the official MinIO chart to make setting up GitLab easier in proof-of-concept and test environments. Due to changes in licensing, project maintenance, and public image availability, these components will be removed from the GitLab Helm chart and GitLab Operator with no replacement.

These charts are explicitly documented as not recommended for production usage. Their sole purpose was to enable quick-start test environments.

If you are running an instance with the bundled PostgreSQL, Redis, or MinIO, follow the migration guide to configure external services before upgrading to GitLab 19.0. The Redis and PostgreSQL provided by the Linux package are not impacted by this change.

Deprecation notice

3. Resource Owner Password Credentials (ROPC) OAuth grant removed

GitLab.com | Self-Managed | Dedicated

Support for the Resource Owner Password Credentials (ROPC) grant as an OAuth flow will be fully removed in GitLab 19.0. This aligns with the OAuth RFC Version 2.1 standard, which removes ROPC due to its inherent security limitations.

GitLab has already required client authentication for ROPC on GitLab.com since April 8, 2025. An administrator setting was added in 18.0 to allow controlled opt-out ahead of the removal.

After the 19.0 upgrade, ROPC cannot be used under any circumstances, even with client credentials. Any applications or integrations using this grant type must migrate to a supported OAuth flow — such as the Authorization Code flow — before upgrading.

Deprecation notice

4. PostgreSQL 16 no longer supported — PostgreSQL 17 is the new minimum

GitLab Self-Managed

GitLab follows an annual upgrade cadence for PostgreSQL. In GitLab 19.0, PostgreSQL 17 becomes the minimum required version, and support for PostgreSQL 16 is removed.

PostgreSQL 17 is available as of GitLab 18.9, so you can upgrade at any time before the 19.0 release.

For instances running a single PostgreSQL instance installed via the Linux package, an automatic upgrade to PostgreSQL 17 may be attempted during the 18.11 upgrade. Ensure you have sufficient disk space to accommodate the upgrade.

For instances using PostgreSQL Cluster, or those that opt out of the automated upgrade, a manual upgrade to PostgreSQL 17 is required before upgrading to GitLab 19.0.

Deprecation notice | Upgrade guide

Medium impact

Here are the breaking changes that are medium impact.

1. Linux package support for Ubuntu 20.04 discontinued

GitLab Self-Managed

Ubuntu standard support for Ubuntu 20.04 ended in May 2025. In accordance with GitLab's Linux package supported platforms policy, packages are dropped once a vendor stops supporting the operating system.

From GitLab 19.0, packages will no longer be provided for Ubuntu 20.04. GitLab 18.11 will be the last release with Linux packages for this distribution.

If you currently run GitLab on Ubuntu 20.04, you must upgrade to Ubuntu 22.04 or another supported operating system before upgrading to GitLab 19.0. Canonical provides an upgrade guide to help with the migration.

Deprecation notice

2. Support for Redis 6 removed

GitLab Self-Managed

In GitLab 19.0, support for Redis 6 is removed. Before upgrading, instances using an external Redis 6 deployment must migrate to either Redis 7.2 or Valkey 7.2, which is available in beta from GitLab 18.9 with general availability planned for GitLab 19.0.

The bundled Redis included with the Linux package has used Redis 7 since GitLab 16.2 and is not affected. Only instances using an external Redis 6 deployment must act.

Migration resources are available for common platforms:

• AWS ElastiCache: Upgrade to Redis 7.2 or Valkey 7.2
• GCP Memorystore: Upgrade to Redis 7.2 or Valkey 7.2
• Azure Cache for Redis: Managed Redis 7.2 or Valkey 7.2 is not yet available on Azure. You can self-host on Azure VMs or AKS, or use the Linux package installation, which will support Valkey 7.2 with GitLab 19.0 GA.
• Self-hosted: Upgrade your Redis 6 instance to Redis 7.2 or Valkey 7.2.

Deprecation notice | Requirements documentation

3. heroku/builder:22 image replaced by heroku/builder:24

GitLab.com | Self-Managed | Dedicated

The cloud-native buildpack (CNB) builder image used in Auto DevOps has been updated to heroku/builder:24. This affects pipelines that use the auto-build-image provided by the Auto Build stage of Auto DevOps.

While most workloads will be unaffected, this may be a breaking change for some users. Before upgrading, review the Heroku-24 stack release notes and upgrade notes to assess your impact.

If you need to continue using heroku/builder:22 after GitLab 19.0, set the CI/CD variable AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER to heroku/builder:22.

Deprecation notice

4. Mattermost removed from the Linux package

GitLab Self-Managed

In GitLab 19.0, bundled Mattermost is removed from the Linux package. Mattermost was first bundled with GitLab in 2015, but has since matured its own standalone deployment options. Additionally, with Mattermost v11, GitLab SSO was deprecated from their free offering, reducing the value of the bundled integration.

Customers not using the bundled Mattermost will not be impacted. If you currently use it, refer to Migrating from GitLab Omnibus to Mattermost Standalone in the Mattermost documentation for migration instructions.

Deprecation notice

5. Linux package support for SUSE distributions discontinued

GitLab Self-Managed

In GitLab 19.0, Linux package support for SUSE distributions ends. This affects:

• openSUSE Leap 15.6
• SUSE Linux Enterprise Server 12.5
• SUSE Linux Enterprise Server 15.6

GitLab 18.11 will be the last version with Linux packages for these distributions. The recommended path forward is to migrate to a Docker deployment of GitLab on your existing distribution, avoiding the need to change your underlying operating system to continue receiving upgrades.

Deprecation notice

Low impact

Here are the breaking changes that are low impact.

1. Spamcheck removed from Linux package and GitLab Helm chart

GitLab Self-Managed

In GitLab 19.0, Spamcheck is removed from the Linux package and GitLab Helm chart. It is primarily relevant to large public instances, which is an edge case in GitLab's customer base. The removal reduces package size and dependency footprint for the majority of customers.

Customers not currently using Spamcheck will not be impacted. If you currently use the bundled Spamcheck, you can deploy it separately using Docker. No data migration is required.

Deprecation notice

2. Slack slash commands integration removed

GitLab Self-Managed | Dedicated

The Slack slash commands integration is deprecated in favor of the GitLab for Slack app, which provides a more secure integration with the same capabilities.

From GitLab 19.0, users will no longer be able to configure or use Slack slash commands. This integration only exists on GitLab Self-Managed and GitLab Dedicated — GitLab.com users are not affected.

To check if your instance is impacted, see the impact check guidance.

Deprecation notice

3. Bitbucket Cloud import via API no longer supports app passwords

GitLab.com | Self-Managed | Dedicated

Atlassian has deprecated app passwords (username and password authentication) for Bitbucket Cloud and has announced that this authentication method will stop working on June 9, 2026.

From GitLab 19.0, importing repositories from Bitbucket Cloud through the GitLab API requires user API tokens instead of app passwords. Users importing from Bitbucket Server, or from Bitbucket Cloud through the GitLab UI, are not affected.

Deprecation notice | Impact check

4. Trending tab removed from Explore projects page

GitLab.com | Self-Managed | Dedicated

The Trending tab in Explore > Projects and its associated GraphQL arguments are removed in GitLab 19.0. The trending algorithm only considers public projects, making it ineffective for Self-Managed instances that primarily use internal or private project visibility.

In the month before the GitLab 19.0 release, the Trending tab on GitLab.com will redirect to the Active tab sorted by stars in descending order.

Also removed: the trending argument in the Query.adminProjects, Query.projects, and Organization.projects GraphQL types.

Deprecation notice

5. Container registry storage driver updates

GitLab Self-Managed

Two legacy container registry storage drivers are being replaced in GitLab 19.0:

• Azure storage driver: The legacy azure driver becomes an alias for the new azure_v2 driver. No manual action is required, but proactive migration is recommended for improved reliability and performance. See the object storage documentation for migration steps. Deprecation notice
• S3 storage driver (AWS SDK v1): The legacy s3 driver becomes an alias for the new s3_v2 driver. The s3_v2 driver does not support Signature Version 2 — any v4auth: false configuration will be transparently ignored. Migrate to Signature Version 4 before upgrading. Deprecation notice

6. ciJobTokenScopeAddProject GraphQL mutation removed

GitLab.com | Self-Managed | Dedicated

The ciJobTokenScopeAddProject GraphQL mutation is deprecated in favor of ciJobTokenScopeAddGroupOrProject, introduced alongside the CI/CD job token scope changes in GitLab 18.0. Update any automation or tooling using the deprecated mutation before upgrading.

Deprecation notice

7. ci_job_token_scope_enabled projects API attribute removed

GitLab.com | Self-Managed | Dedicated

The ci_job_token_scope_enabled attribute in the Projects REST API is removed in GitLab 19.0. This attribute was deprecated in GitLab 18.0 when the underlying setting was removed, and has since always returned false.

To control CI/CD job token access, use the CI/CD job token project settings.

Deprecation notice

8. Unauthenticated Projects API pagination limit enforced on GitLab.com

GitLab.com

To maintain platform stability and ensure consistent performance, a maximum offset limit of 50,000 will be enforced for all unauthenticated requests to the Projects List REST API on GitLab.com. For example, the page parameter will be limited to 2,500 pages when retrieving 20 results per page.

Workflows requiring access to more data must use keyset-based pagination parameters. This limit applies only to GitLab.com. On GitLab Self-Managed and GitLab Dedicated, the offset limit will be disabled by default behind a feature flag.

Deprecation notice

Resources to manage your impact

We've developed specific tooling to help customers understand how these planned changes impact their GitLab instance(s). Once you've assessed your impact, we recommend reviewing the mitigation steps provided in the documentation relevant to each change to ensure a smooth transition to GitLab 19.0.

GitLab Detective (Self-Managed only): This experimental tool automatically checks a GitLab installation for known issues by looking at config files and database values. Note: it must run directly on your GitLab nodes.

If you have a paid plan and have questions or require assistance with these changes, please open a support ticket on the GitLab Support Portal.

If you are a free GitLab.com user, you can access additional support through community sources such as GitLab Documentation, the GitLab Community Forum, and Stack Overflow.

Through this exciting partnership, GitLab Duo Agent Platform automates software development orchestration and lifecycle context via its integration with Vertex AI on Google Cloud, which powers the model tier for agent calls. Software teams keep working on issues, merge requests, pipelines, and security workflows while inference follows the Google Cloud posture they already defined.

Advances in Google Cloud’s Vertex AI models expand how Google Cloud customers can use GitLab Duo Agent Platform in their environment. Customers get an AI-powered DevSecOps control plane in GitLab, backed by a rapidly advancing AI infrastructure foundation in Vertex AI and Duo Agent Platform’s flexible deployment and integration options. The combination enables more capable, governed agentic workflows that operate at enterprise scale.

Agents that work across the full lifecycle

Many AI tools focus on a single task: generating code faster. GitLab Duo Agent Platform goes further. It orchestrates AI agents across the entire software development lifecycle (SDLC), from planning through security review to delivery, across many teams with many projects and releases. At this scale, AI coding assistants are necessary for continuous innovation but not sufficient.

Single-purpose coding assistants rarely see the full state of a project. Backlog shape, open merge requests, failing jobs, and security findings live in GitLab, but a separate chat window in a coding assistant does not inherit that full picture of the SDLC. The gap shows up as manual handoffs, duplicate explanations to an AI that lacks context, and governance teams trying to map data flows across tools that were never designed as one system.

GitLab Duo Agent Platform helps close that gap by running agents and flows on the same objects engineers use every day. Vertex AI then supplies the models and services those agents call when Google Cloud is your chosen inference home, with GitLab’s AI Gateway mediating access so administrators keep a clear map of what connects to what. For instance, GitLab Duo Planner Agent analyzes backlogs, breaks epics into structured tasks, and applies prioritization frameworks to help teams decide what to build next. Security Analyst Agent triages vulnerabilities, details risks in plain language, and recommends remediation in priority order. Built-in flows connect these agents into end-to-end processes, without requiring developers to manage every handoff manually.

Agentic Chat in GitLab Duo Agent Platform ties the experience together for developers. They query in natural language to get context-aware responses with multi-step reasoning that draws on the full state of a project: its issues, merge requests, pipelines, security findings, and codebase. Because GitLab serves as the system of record for the SDLC with a unified data model, GitLab Duo agents operate with lifecycle context that falls outside the reach of standalone, tool-specific AI assistants.

Amplified by Vertex AI

GitLab Duo Agent Platform is designed to be model-flexible, routing different capabilities to different models based on what performs best for a given task. That architectural choice pays off on Google Cloud, where Vertex AI acts as the managed environment for foundation models and related services, providing a broad model ecosystem and managed infrastructure that helps push the platform's capabilities further.

The latest generations of AI models available through Vertex AI bring significant improvements in reasoning, tool use, and long-context understanding compared to previous iterations — the same properties that GitLab's agents rely on across many projects and teams with large, complex codebases. Longer context windows and richer tool integration in the underlying models expand what agents can accomplish in a single pass, which is especially important for workloads like deep backlog analysis or monorepo security review.

Vertex AI Model Garden, with access to a wide range of foundation models, gives customers the breadth to make these choices based on performance, cost, and regulatory requirements rather than vendor lock-in.

Moreover, GitLab customers can use Bring Your Own Model (BYOM) for Duo Agent Platform so approved providers and gateways land where your security model expects them. GitLab’s 18.9 launch coverage of self-hosted Duo Agent Platform and BYOM describes how that wiring works. With this deployment option, customers gain access to a wider set of model options they can tailor to their software development process: the right model for the right workflow, with the right guardrails.

For GitLab, the decision to build on Vertex AI was driven by the need for enterprise-grade reliability and unparalleled model breadth. Vertex AI and Model Garden completely abstract the heavy lifting of LLM hosting — meaning rapid version delivery, robust security, and strict governance are seamlessly built into the integration. Beyond offering Gemini models, Vertex AI provides global, low-latency access to a vast catalog of third-party and open-source models.

Combined with Google Cloud's industry-leading approach to data privacy and model protection, Vertex AI emerged as the clear choice to power GitLab's next-generation developer experience.

By integrating Vertex AI Model Garden into its backend, GitLab supercharges its DevSecOps platform without passing any complexity on to users. Development teams are not burdened with evaluating or managing underlying LLMs; instead, they experience a streamlined, AI-assisted workflow for building their applications.

GitLab completely abstracts cloud orchestration, enabling developers to focus entirely on writing great code, while Vertex AI powers the features and functionality that assist them.

What this means for customers on Google Cloud

GitLab Duo Agent Platform already delivers AI agents that operate across the full software lifecycle within a single, governed system of record. On Google Cloud, it enables rapid innovation as Vertex AI continues to advance the model and infrastructure layers.

For Google Cloud customers, this integration means streamlined software delivery while maintaining strict enterprise governance. For platform engineering groups, it means normalizing which Vertex-backed models power suggestions, analysis, and remediation inside GitLab instead of cataloging dozens of client-side tools. Security programs benefit when agents propose and validate fixes in the same place developers already triage findings, cutting context switching and reducing work that would otherwise spill into unmanaged channels.

From a cloud economics and policy angle, drawing agent inference toward Vertex from within GitLab keeps usage nearer to the agreements and controls you already run on Google Cloud, which helps avoid duplicate spend and shadow paths that bypass procurement.

Because Vertex AI is an underlying infrastructure provider for GitLab Duo Agent Platform, organizations are enabled to dramatically lift developer productivity without the overhead and risk of managing fragmented AI toolchains. Teams stay aligned within a single, secure system of record, helping them build applications faster and ship with confidence.

The GitLab and Google Cloud collaboration has been building since 2018. Today, it represents one of the most comprehensive paths for organizations moving from AI experiments to fully governed, agentic software development on Google Cloud. As both platforms continue to advance — GitLab expanding its agent orchestration and developer context, and Vertex AI pushing the boundaries of model capability and agent infrastructure — the value for joint customers will continue to grow.

Start a free trial of GitLab Duo Agent Platform to experience the power of GitLab and Vertex AI on Google Cloud.

This year's assessment is notable for a specific reason: Omdia expanded its evaluation criteria, and for the first time, AI development tools were scored on full software lifecycle capability, not just coding. That shift mirrors where the AI evolution is heading and shook up which vendors came out on top.

Download the full Omdia Universe report.

About Omdia Universe

Omdia Universe plots vendors across Solution Capability and Strategy and Execution, producing three tiers: Leaders (strongest on both axes, recommended for every shortlist), Challengers (narrower feature range or earlier in maturity), and Prospects (earlier-stage or adjacent-fit vendors).

What changed in this year's assessment

The expansion of Omdia's criteria reflects something practitioners are already experiencing. AI coding tools have raised developer output significantly, and applications that once took weeks can now be prototyped in a fraction of the time. But acceleration at the coding stage does not automatically translate to faster delivery. Review backlogs grow. Security findings accumulate. Deployments still require coordination across teams using tools that were not designed to work together.

Omdia captured this dynamic directly: The tools pulling ahead are the ones that handle testing, security, deployment, and orchestration. Not just code generation. That finding drove the decision to broaden the assessment criteria and separated the Leaders from the Challengers.

The other major shift in this year's report is how Omdia treated agentic AI. The 2026 assessment weighted agentic capabilities as a current evaluation dimension rather than a future consideration. This includes whether a platform can coordinate multiple tasks autonomously, orchestrate handoffs between specialized agents, and support teams at different stages of agent adoption.

Where GitLab scored

GitLab earned best-in-class scores in three categories:

Solution Breadth: 100%. Coverage of the full SDLC in a single platform, from planning and requirements through deployment and issue management. This includes lifecycle phases that most AI coding tools do not touch. For example, prebuilt agents like Planner Agent and Security Analyst Agent extend AI assistance into sprint planning, vulnerability triage, and remediation guidance: the parts of the lifecycle where delivery actually gets stuck.

Strategy and Innovation: 88%. Differentiation through end-to-end orchestration, privacy-first architecture with no training on private data, and multi-model support via partnerships with Anthropic, Google, and AWS. Teams can select models suited to their workload and data requirements. The platform's approach to unified context, where agents collaborate across issues, merge requests, pipelines, and security findings without losing state, is an example of the architectural innovation Omdia recognized in this category.

Core Features: 82%. This score reflects deep coverage across the parts of the lifecycle where engineering teams spend most of their time. Code is generated with real-time context from the IDE and codebase, tested across unit, integration, and security dimensions, and reviewed with prioritization built in. DevOps automation handles CI/CD, GitOps, and root cause analysis for pipeline failures. The AI Impact Dashboard gives teams measurable visibility into cycle times, deployment frequency, and where AI is actually moving the needle on productivity.

GitLab also earned top-tier recognition for Extended Features (80%) and Vendor Execution (88%).

The changing role of human developers and AI agents

One of the more substantive findings in the Omdia report concerns the evolving role of the software developer alongside these tools. Development teams are increasingly a mix of AI engineers and their AI agents, with engineers supervising and directing agentic AI. With AI coding generating the bulk of the code, the human's job shifts toward ensuring technology requirements are actually met, supervising quality, applying right guardrails, designing autonomous production pipelines, and mediating between business goals and the use of agentic AI across the software lifecycle.

This shift has implications for how organizations evaluate their AI investments. A team that has automated code generation but still handles review, testing, and deployment manually has not yet truly accelerated software innovation. The productivity gain from faster coding compounds when the rest of the lifecycle can keep pace. It shrinks when it cannot, and the bottlenecks move downstream instead.

Enterprise readiness as table stakes

Something notable in how Omdia structured this year's assessment: enterprise controls and guardrails are no longer a bonus category. Compliance certifications, deployment flexibility, and privacy architecture appeared as baseline expectations for Leader-tier platforms, not as distinguishing features. Organizations in regulated industries and those with data sovereignty requirements are now weighing these factors as entry criteria.

GitLab's posture on these dimensions highlight its unique differentiation in the market: SOC 2 and ISO 27001 certified platform, privacy-first design with no training on private customer data for its agentic AI capabilities, self-managed deployment support across cloud and on-premises (including air-gapped environments), and support for self-hosted AI models. Its consumption as a single-tenant SaaS application via GitLab Dedicated, with FedRAMP Moderate Authorized via GitLab Dedicated for Government, extends its leadership in deployment flexibility.

The Omdia report recognized these not as a feature list but as evidence of the platform's readiness for the organizations where the compliance bar is highest: financial services, government, healthcare, and other regulated sectors that cannot compromise on data residency or auditability.

Benchmark your maturity in software development

For teams actively evaluating where their AI development strategy stands, Omdia's recommendation is clear: GitLab belongs on the top of the list.

The deeper question for most engineering leaders right now is not which AI tool generates the best code. It is whether the code being generated can be put to production with the highest level of quality, security, and performance. It must be understood, governed, and maintained by the software teams responsible for it. With GitLab, coding speed translates to innovation velocity.

If you want to benchmark your organization’s maturity in software development best practices and evolution, you can get a personalized score and concrete next steps to take in these assessments for AI Modernization, DevOps Modernization, and Security Modernization.

Download the full Omdia Universe report.

GitLab's pipeline execution model was designed for that complexity. Parent-child pipelines, DAG execution, dynamic pipeline generation, multi-project triggers, merge request pipelines with merged results, and CI/CD Components each solve a distinct class of problems. Because they compose, understanding the full model unlocks something more than a faster pipeline. In this article, you'll learn about the five patterns where that model stands out, each mapped to a real engineering scenario with the configuration to match.

The configs below are illustrative. The scripts use echo commands to keep the signal-to-noise ratio low. Swap them out for your actual build, test, and deploy steps and they are ready to use.

1. Monorepos: Parent-child pipelines + DAG execution

The problem: Your monorepo has a frontend, a backend, and a docs site. Every commit triggers a full rebuild of everything, even when only a README changed.

GitLab solves this with two complementary features: parent-child pipelines (which let a top-level pipeline spawn isolated sub-pipelines) and DAG execution via needs (which breaks rigid stage-by-stage ordering and lets jobs start the moment their dependencies finish).

A parent pipeline detects what changed and triggers only the relevant child pipelines:

# .gitlab-ci.yml
stages:
  - trigger

trigger-services:
  stage: trigger
  trigger:
    include:
      - local: '.gitlab/ci/api-service.yml'
      - local: '.gitlab/ci/web-service.yml'
      - local: '.gitlab/ci/worker-service.yml'
    strategy: depend

Each child pipeline is a fully independent pipeline with its own stages, jobs, and artifacts. The parent waits for all of them via strategy: depend so you get a single green/red signal at the top level, with full drill-down into each service's pipeline. This organizational separation is the bigger win for large teams: each service owns its pipeline config, changes in one cannot break another, and the complexity stays manageable as the repo grows.

One thing worth knowing: when you pass multiple files to a single trigger: include:, GitLab merges them into a single child pipeline configuration. This means jobs defined across those files share the same pipeline context and can reference each other with needs:, which is what makes the DAG optimization possible. If you split them into separate trigger jobs instead, each would be its own isolated pipeline and cross-file needs: references would not work.

Combine this with needs: inside each child pipeline and you get DAG execution. Your integration tests can start the moment the build finishes, without waiting for other jobs in the same stage.

# .gitlab/ci/api-service.yml
stages:
  - build
  - test

build-api:
  stage: build
  script:
    - echo "Building API service"

test-api:
  stage: test
  needs: [build-api]
  script:
    - echo "Running API tests"

Why it matters: Teams with large monorepos typically report significant reductions in pipeline runtime after switching to DAG execution, since jobs no longer wait on unrelated work in the same stage. Parent-child pipelines add the organizational layer that keeps the configuration maintainable as the repo and team grow.

2. Microservices: Cross-repo, multi-project pipelines

The problem: Your frontend lives in one repo, your backend in another. When the frontend team ships a change, they have no visibility into whether it broke the backend integration and vice versa.

GitLab's multi-project pipelines let one project trigger a pipeline in a completely separate project and wait for the result. The triggering project gets a linked downstream pipeline right in its own pipeline view.

The frontend pipeline builds an API contract artifact and publishes it, then triggers the backend pipeline. The backend fetches that artifact directly using the Jobs API and validates it before allowing anything to proceed. If a breaking change is detected, the backend pipeline fails and the frontend pipeline fails with it.

# frontend repo: .gitlab-ci.yml
stages:
  - build
  - test
  - trigger-backend

build-frontend:
  stage: build
  script:
    - echo "Building frontend and generating API contract..."
    - mkdir -p dist
    - |
      echo '{
        "api_version": "v2",
        "breaking_changes": false
      }' > dist/api-contract.json
    - cat dist/api-contract.json
  artifacts:
    paths:
      - dist/api-contract.json
    expire_in: 1 hour

test-frontend:
  stage: test
  script:
    - echo "All frontend tests passed!"

trigger-backend-pipeline:
  stage: trigger-backend
  trigger:
    project: my-org/backend-service
    branch: main
    strategy: depend
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

# backend repo: .gitlab-ci.yml
stages:
  - build
  - test

build-backend:
  stage: build
  script:
    - echo "All backend tests passed!"

integration-test:
  stage: test
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
  script:
    - echo "Fetching API contract from frontend..."
    - |
      curl --silent --fail \
        --header "JOB-TOKEN: $CI_JOB_TOKEN" \
        --output api-contract.json \
        "${CI_API_V4_URL}/projects/${FRONTEND_PROJECT_ID}/jobs/artifacts/main/raw/dist/api-contract.json?job=build-frontend"
    - cat api-contract.json
    - |
      if grep -q '"breaking_changes": true' api-contract.json; then
        echo "FAIL: Breaking API changes detected - backend integration blocked!"
        exit 1
      fi
      echo "PASS: API contract is compatible!"

A few things worth noting in this config. The integration-test job uses $CI_PIPELINE_SOURCE == "pipeline" to ensure it only runs when triggered by an upstream pipeline, not on a standalone push to the backend repo. The frontend project ID is referenced via $FRONTEND_PROJECT_ID, which should be set as a CI/CD variable in the backend project settings to avoid hardcoding it.

Why it matters: Cross-service breakage that previously surfaced in production gets caught in the pipeline instead. The dependency between services stops being invisible and becomes something teams can see, track, and act on.

3. Multi-tenant / matrix deployments: Dynamic child pipelines

The problem: You deploy the same application to 15 customer environments, or three cloud regions, or dev/staging/prod. Updating a deploy stage across all of them one by one is the kind of work that leads to configuration drift. Writing a separate pipeline for each environment is unmaintainable from day one.

GitLab's dynamic child pipelines let you generate a pipeline at runtime. A job runs a script that produces a YAML file, and that YAML becomes the pipeline for the next stage. The pipeline structure itself becomes data.

# .gitlab-ci.yml
stages:
  - generate
  - trigger-environments

generate-config:
  stage: generate
  script:
    - |
      # ENVIRONMENTS can be passed as a CI variable or read from a config file.
      # Default to dev, staging, prod if not set.
      ENVIRONMENTS=${ENVIRONMENTS:-"dev staging prod"}
      for ENV in $ENVIRONMENTS; do
        cat > ${ENV}-pipeline.yml << EOF
      stages:
        - deploy
        - verify
      deploy-${ENV}:
        stage: deploy
        script:
          - echo "Deploying to ${ENV} environment"
      verify-${ENV}:
        stage: verify
        script:
          - echo "Running smoke tests on ${ENV}"
      EOF
      done
  artifacts:
    paths:
      - "*.yml"
    exclude:
      - ".gitlab-ci.yml"

.trigger-template:
  stage: trigger-environments
  trigger:
    strategy: depend

trigger-dev:
  extends: .trigger-template
  trigger:
    include:
      - artifact: dev-pipeline.yml
        job: generate-config

trigger-staging:
  extends: .trigger-template
  needs: [trigger-dev]
  trigger:
    include:
      - artifact: staging-pipeline.yml
        job: generate-config

trigger-prod:
  extends: .trigger-template
  needs: [trigger-staging]
  trigger:
    include:
      - artifact: prod-pipeline.yml
        job: generate-config
  when: manual

The generation script loops over an ENVIRONMENTS variable rather than hardcoding each environment separately. Pass in a different list via a CI variable or read it from a config file and the pipeline adapts without touching the YAML. The trigger jobs use extends: to inherit shared configuration from .trigger-template, so strategy: depend is defined once rather than repeated on every trigger job. Add a new environment by updating the variable, not by duplicating pipeline config. Add when: manual to the production trigger and you get a promotion gate baked right into the pipeline graph.

Why it matters: SaaS companies and platform teams use this pattern to manage dozens of environments without duplicating pipeline logic. The pipeline structure itself stays lean as the deployment matrix grows.

4. MR-first delivery: Merge request pipelines, merged results, and workflow routing

The problem: Your pipeline runs on every push to every branch. Expensive tests run on feature branches that will never merge. Meanwhile, you have no guarantee that what you tested is actually what will land on main after a merge.

GitLab has three interlocking features that solve this together:

• Merge request pipelines run only when a merge request exists, not on every branch push. This alone eliminates a significant amount of wasted compute.
• Merged results pipelines go further. GitLab creates a temporary merge commit (your branch plus the current target branch) and runs the pipeline against that. You are testing what will actually exist after the merge, not just your branch in isolation.
• Workflow rules let you define exactly which pipeline type runs under which conditions and suppress everything else. The $CI_OPEN_MERGE_REQUESTS guard below prevents duplicate pipelines firing for both a branch and its open MR simultaneously.

With those three working together, here is what a tiered pipeline looks like:

# .gitlab-ci.yml
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH
    - if: $CI_PIPELINE_SOURCE == "schedule"

stages:
  - fast-checks
  - expensive-tests
  - deploy

lint-code:
  stage: fast-checks
  script:
    - echo "Running linter"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

unit-tests:
  stage: fast-checks
  script:
    - echo "Running unit tests"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

integration-tests:
  stage: expensive-tests
  script:
    - echo "Running integration tests (15 min)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

e2e-tests:
  stage: expensive-tests
  script:
    - echo "Running E2E tests (30 min)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

nightly-comprehensive-scan:
  stage: expensive-tests
  script:
    - echo "Running full nightly suite (2 hours)"
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

deploy-production:
  stage: deploy
  script:
    - echo "Deploying to production"
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual

With this setup, the pipeline behaves differently depending on context. A push to a feature branch with no open MR runs lint and unit tests only. Once an MR is opened, the workflow rules switch from a branch pipeline to an MR pipeline, and the full integration and E2E suite runs against the merged result. Merging to main queues a manual production deployment. A nightly schedule runs the comprehensive scan once, not on every commit.

Why it matters: Teams routinely cut CI costs significantly with this pattern, not by running fewer tests, but by running the right tests at the right time. Merged results pipelines catch the class of bugs that only appear after a merge, before they ever reach main.

5. Governed pipelines: CI/CD Components

The problem: Your platform team has defined the right way to build, test, and deploy. But every team has their own .gitlab-ci.yml with subtle variations. Security scanning gets skipped. Deployment standards drift. Audits are painful.

GitLab CI/CD Components let platform teams publish versioned, reusable pipeline building blocks. Application teams consume them with a single include: line and optional inputs — no copy-paste, no drift. Components are discoverable through the CI/CD Catalog, which means teams can find and adopt approved building blocks without needing to go through the platform team directly.

Here is a component definition from a shared library:

# templates/deploy.yml
spec:
  inputs:
    stage:
      default: deploy
    environment:
      default: production
---
deploy-job:
  stage: $[[ inputs.stage ]]
  script:
    - echo "Deploying $APP_NAME to $[[ inputs.environment ]]"
    - echo "Deploy URL: $DEPLOY_URL"
  environment:
    name: $[[ inputs.environment ]]

And here is how an application team consumes it:

# Application repo: .gitlab-ci.yml
variables:
  APP_NAME: "my-awesome-app"
  DEPLOY_URL: "https://api.example.com"

include:
  - component: gitlab.com/my-org/component-library/build@v1.0.6
  - component: gitlab.com/my-org/component-library/test@v1.0.6
  - component: gitlab.com/my-org/component-library/deploy@v1.0.6
    inputs:
      environment: staging

stages:
  - build
  - test
  - deploy

Three lines of include: replace hundreds of lines of duplicated YAML. The platform team can push a security fix to v1.0.7 and teams opt in on their own schedule — or the platform team can pin everyone to a minimum version. Either way, one change propagates everywhere instead of needing to be applied repo by repo.

Pair this with resource groups to prevent concurrent deployments to the same environment, and protected environments to enforce approval gates - and you have a governed delivery platform where compliance is the default, not the exception.

Why it matters: This is the pattern that makes GitLab CI/CD scale across hundreds of teams. Platform engineering teams enforce compliance without becoming a bottleneck. Application teams get a fast path to a working pipeline without reinventing the wheel.

Putting it all together

None of these features exist in isolation. The reason GitLab's pipeline model is worth understanding deeply is that these primitives compose:

• A monorepo uses parent-child pipelines, and each child uses DAG execution
• A microservices platform uses multi-project pipelines, and each project uses MR pipelines with merged results
• A governed platform uses CI/CD components to standardize the patterns above across every team

Most teams discover one of these features when they hit a specific pain point. The ones who invest in understanding the full model end up with a delivery system that actually reflects how their engineering organization works, not a pipeline that fights it.

Other patterns worth exploring

The five patterns above cover the most common structural pain points, but GitLab's pipeline model goes further. A few others worth looking into as your needs grow:

• Review apps with dynamic environments let you spin up a live preview for every feature branch and tear it down automatically when the MR closes. Useful for teams doing frontend work or API changes that need stakeholder sign-off before merging.
• Caching and artifact strategies are often the fastest way to cut pipeline runtime after the structural work is done. Structuring cache: keys around dependency lockfiles and being deliberate about what gets passed between jobs with artifacts: can make a significant difference without changing your pipeline shape at all.
• Scheduled and API-triggered pipelines are worth knowing about because not everything should run on a code push. Nightly security scans, compliance reports, and release automation are better modeled as scheduled or API-triggered pipelines with $CI_PIPELINE_SOURCE routing the right jobs for each context.

How to get started

Modern software delivery is complex. Teams are managing monorepos with dozens of services, coordinating across multiple repositories, deploying to many environments at once, and trying to keep standards consistent as organizations grow. GitLab's pipeline model was built with all of that in mind.

What makes it worth investing time in is how well the pieces fit together. Parent-child pipelines bring structure to large codebases. Multi-project pipelines make cross-team dependencies visible and testable. Dynamic pipelines turn environment management into something that scales gracefully. MR-first delivery with merged results ensures confidence at every step of the review process. And CI/CD Components give platform teams a way to share best practices across an entire organization without becoming a bottleneck.

Each of these features is powerful on its own, and even more so when combined. GitLab gives you the building blocks to design a delivery system that fits how your team actually works, and grows with you as your needs evolve.

Start a free trial of GitLab Ultimate to use pipeline logic today.

Read more

• Variable and artifact sharing in GitLab parent-child pipelines
• CI/CD inputs: Secure and preferred method to pass parameters to a pipeline
• Tutorial: How to set up your first GitLab CI/CD component
• How to include file references in your CI/CD components
• FAQ: GitLab CI/CD Catalog
• Building a GitLab CI/CD pipeline for a monorepo the easy way
• A CI/CD component builder's journey
• CI/CD Catalog goes GA: No more building pipelines from scratch