Bundle URI takes significant load off of Gitaly servers during clones by allowing Git to pre-download a bundled repository from object storage before calling the Gitaly servers to fetch the remaining objects.

Here is a graph that shows the difference between clones without and with bundle URI.

This graph shows the results of a small test we ran on an isolated GitLab installation, with Gitaly running on a machine with 2 CPUs. We wanted to test bundle URI with a large repository, so we pushed the GitLab repository to the instance. We also generated a bundle beforehand.

The big CPU spike is from when we performed a single clone of the GitLab repository with bundle URI disabled. It's quite noticeable. A little later, we turned on bundle URI and launched three concurrent clones of the GitLab repository. Sure enough, turning on bundle URI provides massive performance gain. We can't even distinguish the CPU usage of the three clones from normal usage.

Configure Gitaly to use bundle URI

To enable bundle URI on your GitLab installation, there are a couple of things you need to configure.

Create a cloud bucket

Bundles need to be stored somewhere. The ideal place is in a cloud storage bucket. Gitaly uses the gocloud.dev library to read and write from cloud storage. Any cloud storage solution supported by this library can be used. Once you have a cloud bucket URL, you can add it in the Gitaly configuration here:

[bundle_uri]
go_cloud_url = "<bucket-uri>"

It must be noted that Gitaly does not manage the lifecycle of the bundles stored in the bucket. To avoid cost issues, object lifecycle policies must be enabled on the bucket in order to delete unused or old objects.

Enable the feature flags

There are two feature flags to enable:

• gitaly_bundle_generation enables auto-generation of bundles.

• gitaly_bundle_uri makes Gitaly advertise bundle URIs when they are available (either manually created or auto-generated) and allows the user to manually generate bundles.

These feature flags can be enabled at-large on a GitLab installation, or per repository. See the documentation on how to enable a GitLab feature behind a feature flag.

How to generate bundles

Gitaly offers two ways for users to use bundle URI: a manual way and an auto-generated way.

Manual

It is possible to create a bundle manually by connecting over SSH with the Gitaly node that stores the repository you want to create a bundle for, and run the following command:

sudo -u git -- /opt/gitlab/embedded/bin/gitaly bundle-uri 
--config=<config-file>
--storage=<storage-name>
--repository=<relative-path>

This command will create a bundle for the given repository and store it into the bucket configured above. When a subsequent git clone request will reach Gitaly for the same repository, the bundle URI mechanism described above will come into play.

Auto-generated

Gitaly can also generate bundles automatically, using a heuristic to determine if it is currently handling frequent clones for the same repository.

The current heuristic keeps track of the number of times a git fetch request is issued for each repository. If the number of requests reaches a certain threshold in a given time interval, a bundle is automatically generated. Gitaly also keeps track of the last time it generated a bundle for a repository. When a new bundle should be regenerated, based on the threshold and interval, Gitaly looks at the last time a bundle was generated for the given repository. It will only generate a new bundle if the existing bundle is older than some maxBundleAge configuration. The old bundle is overwritten. There can only be one bundle per repository in cloud storage.

Using bundle URI

When a bundle exists for a repository, it can be used by the git clone command.

Cloning from your terminal

To clone a repository from your terminal, make sure your Git configuration enables bundle URI. The configuration can be set like so:

git config --global transfer.bundleuri true

To verify that bundle URI is used during a clone, you can run the git clone command with GIT_TRACE=1 and see if your bundle is being downloaded:

➜  GIT_TRACE=1 git clone https://gitlab.com/gitlab-org/gitaly
...
14:31:42.374912 run-command.c:667       trace: run_command: git-remote-https '<bundle-uri>'
...

Cloning during CI/CD pipelines

One scenario where using bundle URI would be beneficial is during a CI/CD pipeline, where each job needs a copy of the repository in order to run. Cloning a repository during a CI/CD pipeline is the same as cloning a repository from your terminal, except that the Git client in this case is the GitLab Runner. Thus, we need to configure the GitLab Runner in such a way that it can use bundle URI.

1. Update the helper-image

The first thing to do to configure the GitLab Runner is to overwrite the helper-image that your GitLab Runner instances use. The helper-image is the image that is used to run the process of cloning a repository before the job starts. To use bundle URI, the image needs the following:

• Git Version 2.49.0 or later

• GitLab Runner helper Version 18.1.0 or later

The helper-images can be found here. Select an image that corresponds to the OS distribution and the architecture you use for your GitLab Runner instances, and verify that the image satisfies the requirements.

At the time of writing, the alpine-edge-<arch>-v18.1.0* tag meets all requirements.

You can validate the image meets all requirements with:

docker run -it <image:tag>
$ git version ## must be 2.49.0 or newer
$ gitlab-runner-helper -v ## must be 18.0 or newer

If you do not find an image that meets the requirements, you can also use the helper-image as a base image and install the requirements yourself in a custom-built image that you can host on GitLab Container Registry.

Once you have found the image you need, you must configure your GitLab Runner instances to use it by updating your config.toml file:

[[runners]]
 (...)
 executor = "docker"
 [runners.docker]
    (...)
    helper_image = "image:tag" ## <-- put the image name and tag here

Once the configuration is changed, you must restart the runners for the new configuration to take effect.

2. Turn on the feature flag

Next, you must enable the FF_USE_GIT_NATIVE_CLONE GitLab Runner feature flags in your .gitlab-ci.yml file. To do that, simply add it as a variable and set to true :

variables:
  FF_USE_GIT_NATIVE_CLONE: "true"

The GIT_STRATEGY must also be set to clone, as Git bundle URI only works with clone commands.

How bundle URI works

When a user clones a repository with the git clone command, a process called git-receive-pack is launched on the client's machine. This process communicates with the remote repository's server (it can be over HTTP/S, SSH, etc.) and asks to start a git-upload-pack process. Those two processes then exchange information using the Git protocol (it must be noted that bundle URI is only supported with Git protocol v2). The capabilities both processes support and the references and objects the client needs are among the information exchanged. Once the Git server has determined which objects to send to the client, it must package them into a packfile, which, depending on the size of the data it must process, can consume a good amount of resources.

Where does bundle URI fit into this interaction? If bundle URI is advertised as a capability from the upload-pack process and the client supports bundle URI, the Git client will ask the server if it knows about any bundle URIs. The server sends those URIs back and the client downloads those bundles.

Here is a diagram that shows those interactions:

sequenceDiagram


    participant receive as Client


    participant upload as Server


    participant cloud as File server


    receive ->> upload: issue git-upload-pack


    upload -->> receive: list of server capabilities


    opt if bundle URI is advertised as a capability


    receive ->> upload: request bundle URI


    upload -->> receive: bundle URI


    receive ->> cloud: download bundle at URI


    cloud -->> receive: bundle file


    receive ->> receive: clone from bundle


    end


    receive ->> upload: requests missing references and objects


    upload -->> receive: packfile data

As such, Git bundle URI is a mechanism by which, during a git clone, a Git server can advertise the URI of a bundle for the repository being cloned by the Git client. When that is the case, the Git client can clone the repository from the bundle and request from the Git server only the missing references or objects that were not part of the bundle. This mechanism really helps to alleviate pressure from the Git server.

Alternatives

GitLab also has a feature Pack-objects cache. This feature works slightly differently than bundle URI. When the server packs objects together into a so-called packfile, this feature will keep that file in the cache. When another client needs the same set of objects, it doesn't need to repack them, but it can just send the same packfile again.

The feature is only beneficial when many clients request the exact same set of objects. In a repository that is quick-changing, this feature might not give any improvements. With bundle URI, it doesn't matter if the bundle is slightly out-of-date because the client can request missing objects after downloading the bundle and apply those changes on top. Also bundle URI in Gitaly stores the bundles on external storage, which the Pack-objects Cache stores them on the Gitaly node, so using the latter doesn't reduce network and I/O load on the Gitaly server.

Try bundle URI today

You can try the bundle URI feature in one of the following ways:

• Download a free, 60-day trial version of GitLab Ultimate.

• If you already run a self-hosted GitLab installation, upgrade to 18.1.

• If you can't upgrade to 18.1 at this time, download GitLab to a local machine.

Challenges of today's mainframe development

Enterprise organizations that use IBM Z systems for mission-critical workloads face challenges that conventional DevSecOps tools aren’t equipped to address. Cloud-native teams benefit from modern CI/CD pipelines, collaborative development, and automated testing. In contrast, mainframe teams are often left behind — stuck with outdated tools that lead to costly inefficiencies and operational silos.

Teams often resort to workarounds, such as SSH connections and manual file transfers, which create security vulnerabilities and audit difficulties. When compliance requirements are stringent, these improvised solutions become unacceptable risks. Meanwhile, organizations maintain expensive parallel toolchains, with legacy mainframe development tools carrying premium licensing costs while delivering limited functionality compared to modern alternatives.

This fragmentation creates two problems: slower delivery cycles and difficulty attracting developers who expect modern development experiences.

"GitLab Ultimate for IBM Z represents an important step in addressing a long-standing industry challenge. IDC research shows that mainframe developers often work with legacy tooling that contributes to delivery inefficiencies and makes it harder to attract new talent. With this offering, modern DevSecOps capabilities and unified workflows are brought directly to the mainframe. This empowers developers to work more collaboratively and efficiently, while helping organizations accelerate innovation and integrate mainframe development into broader digital transformation strategies." - Katie Norton, Research Manager, DevSecOps and Software Supply Chain Security at IDC

Unified development environments

True modernization means more than just updating mainframe development. It means creating a unified platform where mainframe, cloud-native, web, and mobile development teams collaborate seamlessly.

GitLab Ultimate for IBM Z enables developers to use consistent workflows whether they're deploying to z/OS, cloud, or on-premises infrastructure — knowledge transfers between teams instead of staying siloed. Organizations can modernize incrementally without business disruption, as legacy systems continue operating while teams adopt modern practices at their own pace.

As organizations pursue hybrid cloud strategies, GitLab provides the foundation for applications that span mainframe and cloud-native environments.

What is GitLab Ultimate for IBM Z?

GitLab Ultimate for IBM Z delivers native z/OS Runner support, enabling seamless CI/CD pipeline execution directly on your mainframe infrastructure. This GitLab-certified solution helps eliminate the need for complex workarounds while maintaining the security and reliability your enterprise applications demand.

The combination of GitLab's comprehensive DevSecOps platform with IBM's deep mainframe expertise creates something unique in the market: a certified solution that provides a true bridge between enterprise legacy systems and cloud-native innovation.

GitLab Ultimate for IBM Z capabilities

GitLab Ultimate for IBM Z provides enterprise teams with the tools they need to modernize mainframe development while preserving critical business systems.

Native z/OS Runner support helps eliminate security risks and scalability bottlenecks associated with remote connections, while accelerating delivery through CI/CD pipelines that execute directly where your mainframe code resides.

Unified Source Code Management modernizes your toolchain by replacing expensive legacy library managers with GitLab's searchable, version-controlled repository system, helping reduce licensing costs and maintenance overhead.

Seamless integration with IBM Developer for z/OS Enterprise Edition (IDzEE) delivers faster software releases through dependency-based builds, automated code scanning, and comprehensive debugging tools within familiar developer environments, enhancing both quality and security.

End-to-end visibility across mainframe and distributed environments provides comprehensive project management from planning to production, enabling automated DevOps workflows that help retain talent through modern, next-generation development tools.

Modernize your mainframe development environment today

GitLab Ultimate for IBM Z is available now for organizations ready to transform their mainframe development experience. To learn more, visit the GitLab and IBM partnership page.

To help our customers scale effectively, we developed the RBAC Accelerator — a modular, outcome-driven enablement program that supports large organizations in defining, enforcing, and scaling access policies across GitLab.

This foundation enables broader transformation. For example, the Secure SDLC Accelerator, built on top of the RBAC Accelerator, empowers customers to integrate compliance, security, and DevSecOps best practices into their workflows.

GitLab customer Lely, a major Dutch manufacturer of agricultural machines and robots, used this approach to migrate to GitLab Dedicated. Lely automated user provisioning via Azure AD using OpenID Connect (OIDC), enforced least-privilege policies, and created a scalable, reusable access model to support their future development initiatives.

In this guide, we’ll take you through a hands-on implementation example of GitLab + Keycloak + OIDC, covering everything from running the setup in a Docker environment to automating role mapping, designing a scalable group hierarchy, and aligning GitLab access controls with organizational structure and compliance goals.

This is a local demo setup intended for proof-of-concept purposes only.

Whether you’re just starting out or optimizing at scale, this modular foundation ensures you’re not just securing access — you’re enabling everything that comes next.

Getting started with access control planning

Before implementing any tooling, it’s essential to understand your access landscape.

Consider:

• What GitLab resources need protection (projects, groups, environments)?
• Who are your personas (Developers, Maintainers, Guests, etc.)?
• What organizational units (departments, cost centers) should govern access?
• How does your IdP structure (Keycloak) define users and roles?

Use this stage to draft your:

• Access control matrix
• GitLab group hierarchy (team- or product-based)
• Least privilege policy assumptions

Sample group hierarchy

graph TD
    Root["Root (Root Group)"]
    FirmwareTeam["Firmware-Team"]
    FirmwareDevelopers["Developers (GitLab Developer Role)"]
    FirmwareMaintainers["Maintainers (GitLab Maintainer Role)"]
    FirmwareReporters["Reporters (GitLab Reporter Role)"]
    HardwareTeam["Hardware-Team"]
    HardwareDevelopers["Developers"]
    SoftwareTeam["Software-Team"]
    SoftwareDevelopers["Developers"]
    SoftwareMaintainers["Maintainers"]
    SoftwareReporters["Reporters"]
    
    Enterprise --> FirmwareTeam
    Enterprise --> HardwareTeam
    Enterprise --> SoftwareTeam
    
    FirmwareTeam --> FirmwareDevelopers
    FirmwareTeam --> FirmwareMaintainers
    FirmwareTeam --> FirmwareReporters
    
    HardwareTeam --> HardwareDevelopers
    
    SoftwareTeam --> SoftwareDevelopers
    SoftwareTeam --> SoftwareMaintainers
    SoftwareTeam --> SoftwareReporters

Demo system setup: GitLab + Keycloak in a local Docker environment

Prerequisites

• Docker, Docker Compose, OpenSSL
• GitLab Version 17.7.3 and Keycloak Version 23.0.7 container images
• Self-signed certificates

.env configuration

The demo setup is using the following GitLab and Keycloak versions, ports and secrets.

GitLab configuration

GITLAB_VERSION=17.7.3-ee.0
GITLAB_EXTERNAL_URL=http://localhost:8081
GITLAB_SSH_PORT=8222

Keycloak configuration

KEYCLOAK_VERSION=latest
KEYCLOAK_ADMIN=<your-admin-username>
KEYCLOAK_ADMIN_PASSWORD=<your-admin-password>
KEYCLOAK_HTTPS_PORT=8443
KEYCLOAK_CLIENT_SECRET=<your-client-secret>  # Get this from Keycloak after setup

Generate SSL certificates

To establish trust between GitLab and Keycloak, especially in a self-hosted Docker environment, we’ll need to generate self-signed SSL certificates. These certificates will enable encrypted HTTPS communication and ensure GitLab can securely talk to Keycloak during the OIDC authentication process.

For production environments, we recommend using certificates from a trusted Certificate Authority (CA), but for local testing and development, self-signed certificates are sufficient.

Follow these step-by-step instructions:

1. Create a folder for the certificates.

mkdir -p certs

2. Generate a self-signed certificate with OpenSSL.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout certs/tls.key \
  -out certs/tls.crt \
  -subj "/CN=keycloak" \
  -addext "subjectAltName=DNS:keycloak,DNS:localhost"

3. Create a PKCS12 keystore for Keycloak.

openssl pkcs12 -export \
  -in certs/tls.crt \
  -inkey certs/tls.key \
  -out certs/keystore.p12 \
  -name keycloak \
  -password pass:password

Start the service using Docker compose

Now that we have our certificates, we can stand up our local GitLab + Keycloak environment using Docker Compose:

version: '3.8'
services:
  gitlab:
    image: gitlab/gitlab-ee:${GITLAB_VERSION}
    container_name: gitlab
    restart: unless-stopped
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url '${GITLAB_EXTERNAL_URL:-http://localhost:8081}'
        gitlab_rails['gitlab_shell_ssh_port'] = ${GITLAB_SSH_PORT:-8222}
        gitlab_rails['display_initial_root_password'] = true

        # OAuth Configuration
        gitlab_rails['omniauth_enabled'] = true
        gitlab_rails['omniauth_allow_single_sign_on'] = ['openid_connect']
        gitlab_rails['omniauth_block_auto_created_users'] = false
        gitlab_rails['omniauth_providers'] = [
            {
                'name' => 'openid_connect',
                'label' => 'Keycloak',
                'args' => {
                    'name' => 'openid_connect',
                    'scope' => ['openid', 'profile', 'email'],
                    'response_type' => 'code',
                    'issuer' => 'https://localhost:8443/realms/GitLab',
                    'client_auth_method' => 'query',
                    'discovery' => false,
                    'uid_field' => 'preferred_username',
                    'pkce' => true,
                    'client_options' => {
                        'identifier' => 'gitlab',
                        'secret' => '${KEYCLOAK_CLIENT_SECRET}',
                        'redirect_uri' => '${GITLAB_EXTERNAL_URL:-http://localhost:8081}/users/auth/openid_connect/callback',
                        'authorization_endpoint' => 'https://localhost:8443/realms/GitLab/protocol/openid-connect/auth',
                        'token_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/token',
                        'userinfo_endpoint' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/userinfo',
                        'jwks_uri' => 'https://keycloak:8443/realms/GitLab/protocol/openid-connect/certs'
                    }
                }
            }
        ]
    volumes:
      - gl-config:/etc/gitlab
      - gl-data:/var/opt/gitlab
      - ./certs/tls.crt:/etc/gitlab/trusted-certs/keycloak.crt
    ports:
      - '${GITLAB_EXTERNAL_PORT:-8081}:8081'
      - '${GITLAB_SSH_PORT:-8222}:22'
    shm_size: '256m'

  keycloak:
    image: quay.io/keycloak/keycloak:${KEYCLOAK_VERSION}
    container_name: keycloak-server
    restart: unless-stopped
    command: [
      "start-dev",
      "--import-realm",
      "--https-port=${KEYCLOAK_HTTPS_PORT}",
      "--https-key-store-file=/etc/x509/https/keystore.p12",
      "--https-key-store-password=password"
    ]
    volumes:
      - ./data:/opt/keycloak/data/import
      - ./certs:/etc/x509/https
    environment:
      KEYCLOAK_ADMIN: ${KEYCLOAK_ADMIN}
      KEYCLOAK_ADMIN_PASSWORD: ${KEYCLOAK_ADMIN_PASSWORD}
    ports:
      - "${KEYCLOAK_HTTPS_PORT}:8443"

volumes:
  gl-config:
  gl-data:

Run the docker-compose up -d command and your GitLab + Keycloak environment will be up in minutes.

docker-compose up -d

Keycloak realm configuration

Your Keycloak realm is automatically configured on startup as it's defined in the docker-compose file.

The realm configuration will include:

• Pre-configured GitLab client
• Default client secret

You can access Keycloak admin console at https://localhost:8443 with:

• Username: admin
• Password: from your .env file
• To verify the setup:
  • Log into Keycloak admin console
  • Select the GitLab realm
  • Check Clients > gitlab

Verify the client configuration matches your environment.

To showcase the automated RBAC mechanism, you will need to follow these steps:

• Map realm roles to GitLab roles
• Create group structure with mapping roles, matching the Group, Sub-group, Project pattern in GitLab.

Before provisioning your first users to the user groups, it’s recommended to log into your GitLab instance to retrieve your instance root password:

1. Access GitLab at http://localhost:8081.

2. Get the root password:

docker exec gitlab grep 'Password:' `/etc/gitlab/initial_root_password`

3. Log in as root with the retrieved password.

Putting it all together

To demonstrate the power of this integrated RBAC model, start by walking through a real-world user journey — from identity to access.

Begin in Keycloak by showcasing a user assigned to specific realm roles (e.g., developer, maintainer) and groups (e.g., /engineering/platform). These roles have been mapped to GitLab access levels via OIDC claims, while group affiliations align with GitLab’s structured hierarchy of root groups, sub-groups, and projects.

Upon login through GitLab’s SSO Keycloak endpoint, the user is automatically provisioned into the correct group and assigned the appropriate role — with no manual intervention.

Within GitLab, you can see that the user can interact with the assigned project: For example, a developer might push code and open a merge request, but not merge to protected branches — validating the least-privilege model.

Finally, you can showcase access across multiple teams or products that are managed centrally in Keycloak, yet enforced precisely in GitLab through group sync and permissions inheritance. This demo illustrates not just role assignment, but how GitLab and Keycloak together deliver real-time, automated access governance at scale — ready for secure, compliant, enterprise-grade software development.

Why GitLab?

GitLab’s comprehensive, intelligent DevSecOps platform is the ideal foundation for secure, scalable access management. With native OIDC support, granular role enforcement, SCIM-based user provisioning, and built-in audit logging, GitLab allows organizations to centralize control without compromising agility. Its flexible group hierarchy mirrors enterprise structure, making it easy to manage access across teams.

Integrating with identity providers like Keycloak automates onboarding, ensures least-privilege access, and creates a seamless identity-to-permission pipeline that supports regulatory and security goals. As a core component of GitLab’s security capabilities, RBAC ties directly into CI/CD, policy enforcement, and vulnerability management workflows.

Summary

RBAC is just the beginning. With GitLab and Keycloak, you’re not just securing access — you’re enabling structured, automated governance that scales. As you expand into policy enforcement, Secure SDLC, and DevSecOps automation, this foundation becomes a launchpad for sustainable, enterprise-grade software delivery.

Get started with RBAC in GitLab today with a free, 60-day trial of GitLab Ultimate. Sign up today!

New git-diff-pairs(1) command

Diffs are at the heart of every code review and show all the changes made between two revisions. GitLab shows diffs in various places, but the most common place is a merge request's "Changes" tab. Behind the scenes, diff generation is powered by git-diff(1). For example:

$ git diff HEAD~1 HEAD

This command returns the full diff for all changed files. This might pose a scalability challenge because the number of files changed between a set of revisions could be very large and cause the command to reach self-imposed timeouts for the GitLab backend. For large change sets, it would be better if there were a way to break diff computation into smaller, more digestible chunks.

One way this can be achieved is by using git-diff-tree(1) to retrieve info about all the changed files:

$ git diff-tree -r -M --abbrev HEAD~ HEAD
:100644 100644 c9adfed339 99acf81487 M      Documentation/RelNotes/2.50.0.adoc
:100755 100755 1047b8d11d 208e91a17f M      GIT-VERSION-GEN

Git refers to this output as the "raw" format. In short, each line of output lists filepairs and the accompanying metadata about what has changed between the start and end revisions. Compared to generating the "patch" output for large changes, this process is relatively quick and provides a summary of everything that changed. This command can optionally perform rename detection by appending the -M flag to check if identified changes were due to a file rename.

With this information, we could use git-diff(1) to compute each of the filepair diffs individually. For example, we can provide the blob IDs directly:

$ git diff 1047b8d11de767d290170979a9a20de1f5692e26 208e91a17f04558ca66bc19d73457ca64d5385f

We can repeat this process for each of the filepairs, but spinning up a separate Git process for each individual file diff is not very efficient. Furthermore, when using blob IDs, the diff loses some contextual information such as the change status, and file modes which are stored in with the parent tree object. What we really want is a mechanism to feed "raw" filepair info and generate the corresponding patch output.

With the 2.50 release, Git has a new built-in command named git-diff-pairs(1). This command accepts "raw" formatted filepair info as input on stdin to determine exactly which patches to output. The following example showcases how this command could be used:

$ git diff-tree -r -z -M HEAD~ HEAD | git diff-pairs -z

When used in this manner, the resulting output is identical to using git-diff(1). By having a separate command to generate patch output, the "raw" output from git-diff-tree(1) can be broken up into smaller batches of filepairs and fed to separate git-diff-pairs(1) processes. This solves the previously mentioned scalability concern because diffs no longer have to be computed all at once. Future GitLab releases could build upon this mechanism to improve diff generation performance, especially in cases where large change sets are concerned. For more information on this change, check out the corresponding mailing-list thread.

This project was led by Justin Tobler.

Batched reference updates

Git provides the git-update-ref(1) command to perform reference updates. When used with the --stdin flag, multiple reference updates can be batched together in a single transaction by specifying instructions for each reference update to be performed on stdin. Bulk updating references in this manner also provides atomic behavior whereby a single reference update failure results in an aborted transaction and no references being updated. Here is an example showcasing this behavior:

# Create repository with three empty commits and branch named "foo"
$ git init
$ git commit --allow-empty -m 1
$ git commit --allow-empty -m 2
$ git commit --allow-empty -m 3
$ git branch foo

# Print out the commit IDs
$ git rev-list HEAD
cf469bdf5436ea1ded57670b5f5a0797f72f1afc
5a74cd330f04b96ce0666af89682d4d7580c354c
5a6b339a8ebffde8c0590553045403dbda831518

# Attempt to create a new reference and update existing reference in transaction.
# Update is expected to fail because the specified old object ID doesn’t match.
$ git update-ref --stdin <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
fatal: cannot lock ref 'refs/heads/foo': is at cf469bdf5436ea1ded57670b5f5a0797f72f1afc but expected 5a74cd330f04b96ce0666af89682d4d7580c354c

# The "bar" reference was not created.
$ git switch bar
fatal: invalid reference: bar

Compared to updating many references individually, updating in bulk is also much more efficient. While this works well, there might be certain circumstances where it is okay for a subset of the requested reference updates to fail, but we still want to take advantage of the efficiency gains of bulk updates.

With this release, git-update-ref(1) has the new --batch-updates option, which allows the updates to proceed even when one or more reference updates fails. In this mode, individual failures are reported in the following format:

rejected SP (<old-oid> | <old-target>) SP (<new-oid> | <new-target>) SP <rejection-reason> LF

This allows successful reference updates to proceed while providing context to which updates were rejected and for what reason. Using the same example repository from the previous example:

# Attempt to create a new reference and update existing reference in transaction.
$ git update-ref --stdin --batch-updates <<EOF
> create refs/heads/bar cf469bdf5436ea1ded57670b5f5a0797f72f1afc
> update refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c
> EOF
rejected refs/heads/foo 5a6b339a8ebffde8c0590553045403dbda831518 5a74cd330f04b96ce0666af89682d4d7580c354c incorrect old value provided

# The "bar" reference was created even though the update to "foo" was rejected.
$ git switch bar
Switched to branch 'bar'

This time, with the --batch-updates option, the reference creation succeeded even though the update didn't work. This patch series lays the groundwork for future performance improvements in git-fetch(1) and git-receive-pack(1) when references are updated in bulk. For more information, check the mailing-list thread

This project was led by Karthik Nayak.

New filter option for git-cat-file(1)

With git-cat-file(1), it is possible to print info for all objects contained in the repository via the --batch–all-objects option. For example:

# Setup simple repository.
$ git init
$ echo foo >foo
$ git add foo
$ git commit -m init

# Create an unreachable object.
$ git commit --amend --no-edit

# Use git-cat-file(1) to print info about all objects including unreachable objects.
$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
tree 205f6b799e7d5c2524468ca006a0131aa57ecce7
blob 257cc5642cb1a054f08cc83f2d943e56fd3ebe99
commit c999f781fd7214b3caab82f560ffd079ddad0115

In some situations, a user might want to search through all objects in the repository, but only output a subset based on some specified attribute. For example, if we wanted to see only the objects that are commits, we could use grep(1):

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' | grep ^commit
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

While this works, one downside with filtering the output is that git-cat-file(1) still has to traverse all the objects in the repository, even the ones that the user is not interested in. This can be rather inefficient.

With this release, git-cat-file(1) now has the --filter option, which only shows objects matching the specified criteria. This is similar to the option of the same name for git-rev-list(1), but with only a subset of the filters supported. The supported filters are blob:none, blob:limit=, as well as object:type=. Similar to the previous example, objects can be filtered by type with Git directly:

$ git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectname)' --filter='object:type=commit'
commit 0b07e71d14897f218f23d9a6e39605b466454ece
commit c999f781fd7214b3caab82f560ffd079ddad0115

Not only is it convenient for Git to handle the processing, for large repositories with many objects, it is also potentially more efficient. If a repository has bitmap indices, it becomes possible for Git to efficiently lookup objects of a specific type, and thus avoid scanning through the packfile, which leads to a significant speedup. Benchmarks conducted on the Chromium repository show significant improvements:

Benchmark 1: git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter
   Time (mean ± σ):     82.806 s ±  6.363 s    [User: 30.956 s, System: 8.264 s]
   Range (min … max):   73.936 s … 89.690 s    10 runs

Benchmark 2: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag
   Time (mean ± σ):      20.8 ms ±   1.3 ms    [User: 6.1 ms, System: 14.5 ms]
   Range (min … max):    18.2 ms …  23.6 ms    127 runs

Benchmark 3: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit
   Time (mean ± σ):      1.551 s ±  0.008 s    [User: 1.401 s, System: 0.147 s]
   Range (min … max):    1.541 s …  1.566 s    10 runs

Benchmark 4: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree
   Time (mean ± σ):     11.169 s ±  0.046 s    [User: 10.076 s, System: 1.063 s]
   Range (min … max):   11.114 s … 11.245 s    10 runs

Benchmark 5: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob
   Time (mean ± σ):     67.342 s ±  3.368 s    [User: 20.318 s, System: 7.787 s]
   Range (min … max):   62.836 s … 73.618 s    10 runs

Benchmark 6: git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none
   Time (mean ± σ):     13.032 s ±  0.072 s    [User: 11.638 s, System: 1.368 s]
   Range (min … max):   12.960 s … 13.199 s    10 runs

Summary
   git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tag
    74.75 ± 4.61 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=commit
   538.17 ± 33.17 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=tree
   627.98 ± 38.77 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=blob:none
  3244.93 ± 257.23 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --filter=object:type=blob
  3990.07 ± 392.72 times faster than git cat-file --batch-check --batch-all-objects --unordered --buffer --no-filter

Interestingly, these results indicate that the computation time now scales with the number of objects for a given type instead of the number of total objects in the packfile. The original mailing-list thread can be found here.

This project was led by Patrick Steinhardt.

Improved performance when generating bundles

Git provides a means to generate an archive of a repository which contains a specified set of references and accompanying reachable objects via the git-bundle(1) command. This operation is used by GitLab to generate repository backups and also as part of the bundle-URI mechanism.

For large repositories containing millions of references, this operation can take hours or even days. For example, with the main GitLab repository (gitlab-org/gitlab), backup times were around 48 hours. Investigation revealed there was a performance bottleneck due to how Git was performing a check to avoid duplicated references being included in the bundle. The implementation used a nested for loop to iterate and compare all listed references, leading to O(N^2) time complexity. This scales very poorly as the number of references in a repository increases.

In this release, this issue was addressed by replacing the nested loops with a map data structure leading to a significant speedup. The following benchmark the performance improvement for creating a bundle with a repository containing 100,000 references:

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ):     14.653 s ±  0.203 s    [User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s    10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):      2.394 s ±  0.023 s    [User: 1.684 s, System: 0.798 s]
  Range (min … max):    2.364 s …  2.425 s    10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
    6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

To learn more, check out our blog post How we decreased GitLab repo backup times from 48 hours to 41 minutes. You can also find the original mailing list thread here.

This project was led by Karthik Nayak.

Better bundle URI unbundling

Through the bundle URI mechanism in Git, locations to fetch bundles from can be provided to clients with the goal to help speed up clones and fetches. When a client downloads a bundle, references under refs/heads/* are copied from the bundle into the repository along with their accompanying objects. A bundle might contain additional references outside of refs/heads/* such as refs/tags/*, which are simply ignored when using bundle URI on clone.

In Git 2.50, this restriction is lifted, and all references matching refs/* contained in the downloaded bundle are copied. Scott Chacon, who contributed this functionality, demonstrates the difference when cloning gitlab-org/gitlab-foss:

$ git-v2.49 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.49
Cloning into 'gl2.49'...
remote: Enumerating objects: 1092703, done.
remote: Counting objects: 100% (973405/973405), done.
remote: Compressing objects: 100% (385827/385827), done.
remote: Total 959773 (delta 710976), reused 766809 (delta 554276), pack-reused 0 (from 0)
Receiving objects: 100% (959773/959773), 366.94 MiB | 20.87 MiB/s, done.
Resolving deltas: 100% (710976/710976), completed with 9081 local objects.
Checking objects: 100% (4194304/4194304), done.
Checking connectivity: 959668, done.
Updating files: 100% (59972/59972), done.

$ git-v2.50 clone --bundle-uri=gitlab-base.bundle https://gitlab.com/gitlab-org/gitlab-foss.git gl-2.50
Cloning into 'gl-2.50'...
remote: Enumerating objects: 65538, done.
remote: Counting objects: 100% (56054/56054), done.
remote: Compressing objects: 100% (28950/28950), done.
remote: Total 43877 (delta 27401), reused 25170 (delta 13546), pack-reused 0 (from 0)
Receiving objects: 100% (43877/43877), 40.42 MiB | 22.27 MiB/s, done.
Resolving deltas: 100% (27401/27401), completed with 8564 local objects.
Updating files: 100% (59972/59972), done.

Comparing these results, we see that Git 2.50 fetches 43,887 objects (40.42 MiB) after the bundle was extracted whereas Git 2.49 fetches a total of 959,773 objects (366.94 MiB). Git 2.50 fetches roughly 95% fewer objects and 90% less data, which benefits both the client and the server. The server needs to process a lot less data to the client and the client needs to download and extract less data. In the example provided by Scott this led to a speedup of 25%.

To learn more, check out the corresponding mailing-list thread.

This patch series was contributed by Scott Chacon.

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.

GitLab's comprehensive, intelligent DevSecOps platform delivers value that extends far beyond fundamental version control. Built on an open source foundation with enterprise-grade features, GitLab Premium helps prevent costly security incidents involving student data, provides cloud-based development environments for distributed teams, and offers the professional support that educational institutions need for mission-critical systems. And now Premium includes GitLab Duo AI essentials Code Suggestions and Chat at no additional cost.

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Premium with Duo Core"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

The unique development environment in higher education

Universities and colleges operate in a distinctly challenging technical environment. Development teams must support multidisciplinary collaboration across technical and non-technical departments while managing vast amounts of sensitive data – from student records and financial information to research findings and faculty evaluations.

Most institutions face these challenges with limited IT resources, yet must support thousands of concurrent users across numerous projects and research initiatives. Research integrity requirements add another layer of complexity, as development work often needs to maintain traceability and reproducibility standards.

Premium solutions for educational institutions

GitLab Premium with Duo has the functionality that higher education needs.

Enhanced collaboration and workflow capabilities

Cross-departmental projects are common in educational settings – from multi-department research initiatives to custom module development for systems like Ellucian Banner, an enterprise resource planning application used by higher education. These complex projects require sophisticated workflow management that goes beyond basic version control.

GitLab Premium addresses these challenges with powerful collaboration and project visualization features, including epics, roadmaps, and advanced Kanban boards for Agile development workflows. When you assign multiple approvers to certain merge requests and protected branches, you ensure higher code quality and accountability across teams. These tools allow institutions to coordinate work across departments while aligning with institution-wide objectives – essential for managing multiphase campus technology initiatives.

In Australia, Deakin University’s enablement team uses GitLab to build standardized processes and reusable templates — such as custom merge request templates, templated build pipelines, and a security and compliance framework — that can be shared with the broader university community and citizen developers, driving innovation and collaboration both inside the university and with key partners. “We were trying to bring in a community of practice and help it thrive for quite some time, but we were never successful until we had this tool,” said Aaron Whitehand, director of Digital Enablement at Deakin University.

Read more about how Deakin University uses GitLab to drive improvements in collaboration and productivity, including a 60% reduction in manual tasks.

Advanced data protection and governance

Educational institutions generate and manage vast amounts of data, ranging from student records and financial information to research findings and faculty evaluations. The security stakes are particularly high. The 2023 MOVEit breach, which spanned three months and compromised approximately 900 educational institutions, exposed the sensitive information of more than 62 million people. This demonstrates the critical need for proactive security measures integrated directly into higher education development workflows.

Vulnerability scanning stops code releases that contain security risks, enabling institutions to establish and enforce governance protocols that protect sensitive information. These capabilities help universities implement proper access controls and permission structures for research databases, creating a secure framework where authorized researchers maintain appropriate access – effectively balancing robust protection with necessary collaboration.

GitLab is built from the ground up to secure your source code. Scalable Git-based repositories, granular access controls, and built-in compliance features eliminate bottlenecks in your workflow while meeting security requirements. GitLab Premium provides audit tracking and compliance capabilities essential for educational environments. Complete audit trails capture detailed logs of all code changes, access attempts, and system modifications with timestamps and user attribution. Full change management documentation ensures traceability of who made what changes, when, and why – critical for research integrity – while access control auditing monitors repository access and permissions changes.

Cloud-based development environments and remote collaboration

Modern educational institutions require flexible development environments that support distributed teams, remote learning scenarios, and diverse technical requirements. GitLab Premium provides:

• GitLab Workspaces: Cloud-based development environments accessible from any device
• Web IDE integration: Browser-based coding with full GitLab feature integration
• Container-based development: Consistent, reproducible development environments across different projects and user groups

These capabilities are particularly valuable for supporting remote and hybrid learning models, enabling students and researchers to access standardized development environments regardless of their physical location or local hardware constraints.

Professional support for critical systems

Small IT teams in educational settings often support large, complex infrastructure with minimal resources. Reaching out to user forums for answers doesn't always mean you'll get an accurate reply and isn't efficient for large teams. GitLab Premium includes dedicated professional support, providing faster issue resolution and upgrade assistance during critical periods like class enrollment or research deadlines.

This minimizes downtime for critical services and ensures continuity of operations during peak usage periods, giving stretched IT departments the enterprise-grade reliability they need for essential academic systems.

Built on open source with enterprise capabilities

Open source software is developed collaboratively in a public manner, with source code freely available for anyone to view, modify, and distribute. This development model fosters innovation through community contributions and ensures transparency in how software functions. GitLab's open source foundation resonates strongly with educational institutions' values around collaboration, transparency, and community contribution. GitLab Premium features extend this foundation with enterprise-grade capabilities while maintaining the ability to contribute back to the open source ecosystem.

Key open source advantages include:

• Transparency: Complete visibility into platform capabilities and security measures – you can examine exactly how the software works
• Community contribution: Ability to contribute improvements back to the broader community and benefit from global developer expertise
• Vendor independence: Reduced lock-in risk with open source alternatives and the freedom to modify code as needed
• Co-creation opportunities: Collaborative development with the broader community, including other educational institutions, to build shared solutions

AI assistant for software development tasks

GitLab Premium with Duo brings powerful AI-native capabilities directly into the development workflow, including:

• Code Suggestions, which provides real-time code completion and suggestions, helping developers write code faster and more efficiently
• Chat, which allows team members to get instant answers to questions, troubleshoot issues, and access documentation directly within the GitLab environment

These AI tools significantly enhance productivity, reduce errors, and streamline collaboration, making GitLab Premium an even more valuable asset for software development teams in higher education.

Transparency at the core

Higher education institutions handle incredibly sensitive data — from student records and research findings to proprietary academic work and federal grant information.

The GitLab AI Transparency Center demonstrates our commitment to transparency, accountability, and protection of customer data and intellectual property, providing the privacy guarantees that educational institutions require.

GitLab launched the AI Transparency Center to help customers, community, and team members better understand how GitLab upholds ethics and transparency in our AI-powered features.

Our publicly available documentation highlights the comprehensive measures we take to protect your institution's data and intellectual property. GitLab's AI Ethics Principles for Product Development guide us as we continue to build and evolve our AI functionality, helping higher education organizations harness the promise of AI while maintaining complete control and oversight of their most valuable information assets.

Get started with GitLab Premium today

For educational institutions, GitLab Premium with Duo represents a strategic technical investment that combines the benefits of open source development with enterprise-grade, AI-native capabilities. By providing professional-grade tools ready for the challenges familiar to the complex technical environment of higher education, GitLab Premium with Duo helps institutions address security vulnerabilities, streamline development workflows, and maintain the reliable infrastructure that academic and research operations depend on.

Learn more about GitLab for Public Sector or speak to our sales team today.

Read more

• Unlocking AI for every GitLab Premium and Ultimate customer
• GitLab Duo Code Suggestions
• GitLab Duo Chat

What if you could have an AI assistant that understands code review feedback and automatically implements the changes for you? That's exactly what GitLab Duo with Amazon Q brings to your development workflow. This seamless integration combines GitLab's comprehensive DevSecOps platform with Amazon Q's advanced AI capabilities, creating an intelligent assistant that can read reviewer comments and converts them directly into code changes. Instead of manually addressing each piece of feedback, you can let AI handle the implementation while you focus on the bigger picture.

How GitLab Duo with Amazon Q works

When you're viewing a merge request with reviewer comments, you'll see feedback scattered throughout your code. Let's take the examples from earlier in this article: maybe you've received a request to update a form label here, a suggestion to display fields side-by-side there, or a note about making certain text bold. Each comment represents a task that normally you'd need to handle manually.

With GitLab Duo with Amazon Q, you can simply enter the /q dev quick action in a comment. This prompts Amazon Q to analyze all the feedback and start modifying your code automatically. The AI agent understands the context of each comment and implements the requested changes directly in your codebase.

Once Amazon Q processes the feedback, you can view all the updates in the "Changes" tab of your merge request. Every modification is clearly visible, so you can verify that the AI agent correctly interpreted and implemented each piece of feedback. You can then run your updated application to confirm that all the changes work as expected — that form label is updated, the fields are displayed side-by-side, the text is bold, and yes, that button is now blue.

Watch the code review feedback process in action:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/31E9X9BrK5s?si=ThFywR34V3Bfj1Z-" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Processing code review feedback is a necessary but time-intensive part of software development. GitLab Duo with Amazon Q evolves this manual process into an automated workflow, dramatically reducing the time between receiving feedback and implementing changes. By letting AI handle these routine modifications, you're free to focus on what really matters — building innovative features and solving complex problems.

With GitLab Duo with Amazon Q, you can:

• Eliminate hours of manual feedback implementation
• Accelerate your code review cycles
• Maintain consistency in how feedback is addressed
• Reduce context switching between reviewing comments and writing code
• Ship features faster with streamlined deployment times

To learn more about GitLab Duo with Amazon Q visit us at an upcoming AWS Summit in a city near you or reach out to your GitLab representative.

GitLab Duo with Amazon Q resources

• GitLab Duo with Amazon Q: Agentic AI optimized for AWS generally available
• GitLab and AWS partner page
• GitLab Duo with Amazon Q documentation
• What is agentic AI?
• Agentic AI guides and resources

Meeting the security goals

Let’s explore the additions and improvements we've made to further enhance security across the development lifecycle.

Multi-factor authentication (MFA)

Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the use of multi-factor authentication across the manufacturer’s products.

GitLab currently offers multiple MFA options for users to secure their accounts. We also offer SSO functionality to enable GitLab.com, Self-Managed, and GitLab Dedicated customers to streamline their authentication processes and their internal MFA requirements.

To further enhance the platform’s resilience, and to create a more secure foundation for our customers, GitLab is executing a phased MFA by Default rollout.

In the coming months, we will deploy changes requiring all customers to enable MFA on their accounts.

For customers who already have MFA enabled or authenticate to GitLab via their organization’s single sign-on (SSO) method, there will be no necessary changes. For customers who do not already have MFA enabled and are not authenticating to GitLab via their organization’s SSO method, they will be required to enable MFA and enroll in one or more of the available MFA methods.

The MFA rollout will occur in stages to ensure a smooth and consistent adoption across all customers. More details on GitLab’s MFA by Default rollout will be shared in the near future.

Default passwords

Goal: Within one year of signing the pledge, demonstrate measurable progress towards reducing default passwords across the manufacturers’ products.

To reduce the use of default passwords, GitLab uses randomly generated root passwords for its multiple installation methods. GitLab’s multi-method installation instructions also include guidance on how to change the randomly generated root password for each installation.

For some install methods, such as installing GitLab in a Docker container, the password file with the initial root password is deleted in the first container restart after 24 hours to help further harden the GitLab instance.

Reducing entire classes of vulnerabilities

Goal: Within one year of signing the pledge, demonstrate actions taken towards enabling a significant measurable reduction in the prevalence of one or more vulnerability classes across the manufacturer’s products.

GitLab has published secure coding guidelines to its documentation site that contains descriptions and guidelines for addressing security vulnerabilities commonly identified in the GitLab codebase.

The guidelines are “intended to help developers identify potential security vulnerabilities early, with the goal of reducing the number of vulnerabilities released over time.”

GitLab continues to improve its SAST rule coverage to address broader sets of security vulnerabilities for itself and its customers.

Security patches

Goal: Within one year of signing the pledge, demonstrate actions taken to measurably increase the installation of security patches by customers.

GitLab handles all updates related to its GitLab.com and GitLab Dedicated service offerings. Additionally, GitLab publishes a maintenance policy, which outlines its approach to releasing updates, backporting, upgrade recommendations and supporting documentation, etc.

GitLab’s documentation has comprehensive guidance on how to upgrade self-managed instances based on their deployment model. This includes Omnibus, Helm chart, Docker and self-compiled GitLab installations.

GitLab also provides a detailed upgrade plan to ensure proper testing and troubleshooting can be performed as well as rollback plans if necessary.

Depending on the version upgrade, specific changes (example for GitLab 17) for each version are highlighted to ensure a smooth upgrade process and limit unavailability of services.

Vulnerability disclosure policy

Goal: Within one year of signing the pledge, publish a vulnerability disclosure policy (VDP).

GitLab maintains a strong bug bounty program through HackerOne, a security.txt file highlighting GitLab’s preferred and additional disclosure processes, and release posts highlighting security fixes.

Customers and the general public can subscribe to receive GitLab’s release posts directly in their email inbox.

Common vulnerability enumerations

Goal: Within one year of signing the pledge, demonstrate transparency in vulnerability reporting

GitLab includes the Common Weakness Enumeration (CWE) field in all Common vulnerability enumerations (CVE) records it publishes. Over the past year, GitLab has iterated to also include the Common Platform Enumeration (CPE) field in CVE records.

The GitLab CVE assignments project stores a copy of all CVE identifiers assigned and published by GitLab in its role as a CVE Numbering Authority.

Check out GitLab’s CVE submission template.

Evidence of intrusions

Goal: Within one year of signing the pledge, demonstrate a measurable increase in the ability for customers to gather evidence of cybersecurity intrusions affecting the manufacturer’s products.

GitLab has published an incident response guide to help customers respond to incidents involving GitLab instances. Additionally, GitLab has open sourced versions of its GUARD detection-as-code and TLDR threat detection frameworks. The repositories for those open source frameworks can be found on GitLab’s Open Source Security Center.

In a similar manner, GitLab is adding functionality to its GitLab.com service offering to detect compromised passwords for all logins using GitLab’s native username and password authentication method.

What's next

GitLab’s Security Division’s mission is to enable everyone to innovate and succeed on a safe, secure, and trusted DevSecOps platform.

GitLab's security enhancements over the past year have allowed us to demonstrate our commitment to CISA’s Secure by Design Pledge, and they have strengthened our platform and given customers a more reliable and secure foundation to build on.

Our commitment to iteration means we're already focused on the next set of innovations that will drive us forward.

To learn more about GitLab’s security enhancements, bookmark our security page on the GitLab Blog.

Read more

• Secure by Design principles meet DevSecOps innovation in GitLab 17
• Happy birthday, Secure by Design!
• Strengthen your cybersecurity strategy with Secure by Design

Traditional embedded development approaches cannot effectively handle the software challenges of modern machines. This shortcoming slows engineers down, in part, by exacerbating challenges such as:

• Hardware testing bottlenecks
• Inconsistent build environments
• Siloed development practices
• Manual functional safety compliance processes

Embedded developers need a new approach to deal with the rapid increase in code. In this article, we’ll explain four ways you can use the GitLab AI-native DevSecOps platform to shorten feedback loops, work collaboratively and iteratively, and streamline compliance.

Challenge 1: Hardware testing bottlenecks

Unlike enterprise software that can run on virtually any cloud server, embedded automotive software must be tested on specialized hardware that precisely matches production environments. Traditional hardware-in-the-loop (HIL) testing processes often follow this pattern:

1. Developers write code for an embedded system (e.g., an electronic control unit)
2. They request access to limited, expensive hardware test benches (costing $500,000-$10M each)
3. They wait days or weeks for their scheduled access window
4. They manually deploy and test their code on physical hardware at their desks
5. They document results, pass the hardware to the next developer, and go to the back of the hardware testing queue

This process is extremely inefficient. Embedded developers may finish writing their code today and wait weeks to test it on a hardware target. By then, they've moved on to other tasks. This context switching drains productivity. Not only that, developers may wait weeks to learn they had a simple math error in their code.

Solution: Automated hardware allocation and continuous integration

You can streamline hardware testing through automation using the GitLab On-Premises Device Cloud, a CI/CD component. This lets you automate the orchestration of scarce hardware resources, turning a manual, time-intensive process into a streamlined, continuous workflow.

The On-Premises Device Cloud:

1. Creates pools of shared hardware resources
2. Automatically — and exclusively — allocates hardware to a developer’s hardware testing pipeline tasks based on availability
3. Deploys and executes tests without manual intervention
4. Collects and reports results through integrated pipelines
5. Automatically deallocates hardware back into the “available” pool

After submitting code, you’ll receive results in hours instead of days, often without ever physically touching the test hardware.

What this video for an introduction to the GitLab On-Premises Device Cloud CI/CD Component to orchestrate the remote allocation of shared hardware for HIL:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/ltr2CIM9Zag?si=NOij3t1YYz4zKajC" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

You can also adopt multi-pronged testing strategies that balance speed and quality. Bring the following embedded test patterns and environments into automated GitLab CI pipelines:

• Software-in-the-loop (SIL): Testing on virtual hardware simulators for quicker initial feedback
• Processor-in-the-loop (PIL): Testing on representative processor hardware for faster feedback at a lower cost
• Hardware-in-the-loop (HIL): Testing on full production-equivalent hardware and test benches for late-stage verification

By automating the orchestration of these tests within CI pipelines, you’ll be able to identify issues earlier, iterate faster, and accelerate time to market.

Challenge 2: Inconsistent build environments

Another significant challenge in embedded development is build environment inconsistency. Embedded developers often manually execute builds on their local machines with varying configurations, compiler versions, and dependencies. Then they’ll paste the binaries from their local build to a shared codebase.

This approach creates several problems:

• Inconsistent outputs: Builds for the same source code produce different results on different machines
• "Works on my machine" syndrome: Code that builds locally fails in shared environments
• Poor traceability: Limited audit trail of who built what and when
• Knowledge silos: Build expertise becomes concentrated in a few individuals

This approach can lead to errors, bottlenecks, and costly delays.

Solution: Standardized build automation

You can address these challenges by implementing standardized build automation within CI/CD pipelines in GitLab. This approach creates consistent, repeatable, container-based build environments that eliminate machine-specific variations. Through the use of special Embedded Gateway Runner provisioning scripts, containers can interface with hardware for flashing and port monitoring for automated testing.

Key elements of this solution include:

• Lifecycle managed environments: Define complex embedded simulation environments as code; automatically deploy environments for testing and destroy them afterward
• Containerization: Use Docker containers to ensure identical build environments
• Automated dependency management: Control and version all dependencies
• Central build execution: Run builds on shared infrastructure rather than local machines

Follow this tutorial to learn how to automate embedded software builds within a GitLab CI pipeline.

By standardizing and automating the build process, you can ensure that every build follows the same steps with the same dependencies, producing consistent outputs regardless of who initiated it. This not only improves quality but also democratizes the build process, enabling more team members to participate without specialized knowledge.

Challenge 3: Siloed development practices

Enterprise development teams have widely adopted collaborative practices such as DevOps, underpinned by shared source code management (SCM) and continuous integration/continuous delivery (CI/CD) systems. Embedded developers, on the other hand, have historically worked alone at their desks. There are valid technical reasons for this.

For example, consider hardware virtualization, which is a key enabler of DevOps automation. The industry has been slower to virtualize the massive range of specialized processors and boards used in embedded systems. This is due in large part to the difficulties of virtualizing production real-time systems and the associated lack of economic incentives. Compare that to cloud virtualization which has been commoditized and benefited enterprise SaaS development for over a decade.

Many providers are now embracing virtualization-first for the sake of speeding up embedded development. If teams fail to adopt virtual testing options, however, their silos will remain and negatively impact the business through:

• Knowledge fragmentation: Critical insights remain scattered across individuals and teams
• Redundant development: Multiple teams solve identical problems, creating inconsistencies
• Late-stage discovery during big-bang integrations: Problems are found late in the process when multiple developers integrate their code at once, when errors are more costly to fix
• Stifled innovation: Solutions from one domain rarely influence others, hampering the development of new product ideas

Solution: Collaborative engineering through a unified platform

An important step in breaking down these silos is to standardize embedded development around GitLab’s unified DevSecOps platform. In this regard, GitLab is aligned with the shift of embedded systems toward more consolidated, shared platforms on embedded devices. GitLab enables:

• Shared visibility: Make all code, Issues, and documentation visible across teams
• Collaborative workflows: Enable peer review and knowledge sharing through merge requests
• Centralized knowledge: Maintain a single source of truth for all development artifacts
• Asynchronous collaboration: Allow teams to work together across different locations and time zones

Human-AI agent collaboration is a fundamental ingredient to fueling the customer-facing innovations that digital natives and established embedded brands desire. GitLab enables human-AI collaboration as well. By creating transparency across the development lifecycle, GitLab changes embedded development from an isolated activity to a collaborative practice. Engineers can see each other's work in progress, learn from collective experiences, and build upon shared solutions.

Watch this presentation from Embedded World Germany 2025, which explains the power of embedded developers collaborating and sharing “work in progress”. The demo portion from 24:42 to 36:51 shows how to integrate HIL into a GitLab CI pipeline and enable collaborative development.

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/F_rlOyq0hzc?si=eF4alDY6HK98uZPj" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Perhaps most importantly, by achieving greater collaboration through DevSecOps, teams can unlock embedded systems innovations that would otherwise remain hidden. Indeed, collaboration fuels innovation. One study, for example, found that group brainstorming, when properly structured, can lead to more innovative and creative outcomes than individuals working alone. Collaborative development is crucial in the race to develop software-defined products.

Challenge 4: Manual functional safety compliance processes

Embedded systems in the automotive and aerospace industries must comply with rigorous functional safety standards, including ISO 26262, MISRA C/C++, DO-178C, and DO-254. Traditional compliance approaches involve manual reviews, extensive documentation, and separate verification activities that occur late in the development cycle. This often creates security review bottlenecks. When specialized embedded security and code quality scanners detect vulnerabilities in a developer’s code, the scan issue gets added to a pile of other issues that haven’t been resolved. Developers can’t integrate their code, and security personnel need to wade through a backlog of code violations. This creates delays and makes compliance more difficult.

Some of the challenges can best be summed up as:

• Late-stage compliance issues: Problems discovered after development is complete
• Documentation burden: Extensive manual effort to create and maintain compliance evidence
• Process bottlenecks: Serial compliance activities that block development progress
• Expertise dependence: Reliance on limited specialists for compliance activities

As a result, teams often need to choose between velocity and compliance — a precarious trade-off in safety-critical systems.

Solution: Automated functional safety compliance workflow building blocks

Rather than treating security and compliance as post-development verification activities, you can codify compliance requirements and enforce them automatically through customizable frameworks in GitLab. To do this for functional safety standards, in particular, you can integrate GitLab with specialized embedded tools, which provide the depth of firmware scanning required by functional safety standards. Meanwhile, GitLab provides automated compliance checks, full audit trails, and merge request gating — all features needed to support a robust continuous compliance program.

This integrated approach includes:

• Compliance-as-code: Define compliance requirements as automated checks
• Integrated specialized tools: Connect tools like CodeSonar into the DevSecOps platform for automotive-specific compliance
• Continuous compliance verification: Verify requirements throughout development
• Automated evidence collection: Gather compliance artifacts as a by-product of development

Watch this video to learn how to use Custom Compliance Frameworks in GitLab to create your own compliance policies. You can create compliance policies related to any standard (e.g., ISO 26262) and automatically enforce those policies in GitLab.

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/S-FQjzSyVJw?si=0UdtGNuugLPG0SLL" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

By shifting compliance left and embedding it within normal development workflows, you can maintain safety standards without sacrificing velocity. Automated checks catch issues early when they're easier and less expensive to fix, while continuous evidence collection reduces the documentation burden.

Realizing the power of embedded DevOps

Embedded development is changing fast. Teams that remain stuck in manual processes and isolated workflows will find themselves increasingly left behind, while those that embrace automated, collaborative practices will define the future of software-defined smart systems.

Explore our Embedded DevOps Workshop to start automating embedded development workflows with GitLab, or watch this presentation from GitLab's Field Chief Cloud Architect to learn how leading organizations are bringing hardware-in-the-loop testing into continuous integration workflows to accelerate embedded development.

Learn more

• Why GitLab Premium with Duo for embedded systems development?
• Why GitLab Ultimate with Duo for embedded systems development?
• More embedded development systems presentations from GitLab

Ultimately, we traced the issue to a 15-year-old Git function with O(N²) complexity and fixed it with an algorithmic change, reducing backup times exponentially. The result: lower costs, reduced risk, and backup strategies that actually scale with your codebase.

This turned out to be a Git scalability issue that affects anyone with large repositories. Here's how we tracked it down and fixed it.

Backup at scale

First, let's look at the problem. As organizations scale their repositories and backups grow more complex, here are some of the challenges they can face:

• Time-prohibitive backups: For very large repositories, creating a repository backup could take several hours, which can hinder the ability to schedule regular backups.
• Resource intensity: Extended backup processes can consume substantial server resources, potentially impacting other operations.
• Backup windows: Finding adequate maintenance windows for such lengthy processes can be difficult for teams running 24/7 operations.
• Increased failure risk: Long-running processes are more susceptible to interruptions from network issues, server restarts, and system errors, which can force teams to restart the entire very long backup process from scratch.
• Race conditions: Because it takes a long time to create a backup, the repository might have changed a lot during the process, potentially creating an invalid backup or interrupting the backup because objects are no longer available.

These challenges can lead to compromising on backup frequency or completeness – an unacceptable trade-off when it comes to data protection. Extended backup windows can force customers into workarounds. Some might adopt external tooling, while others might reduce backup frequency, resulting in potential inconsistent data protection strategies across organizations.

Now, let's dig into how we identified a performance bottleneck, found a resolution, and deployed it to help cut backup times.

The technical challenge

GitLab's repository backup functionality relies on the git bundle create command, which captures a complete snapshot of a repository, including all objects and references like branches and tags. This bundle serves as a restoration point for recreating the repository in its exact state.

However, the implementation of the command suffered from poor scalability related to reference count, creating a performance bottleneck. As repositories accumulated more references, processing time increased exponentially. In our largest repositories containing millions of references, backup operations could extend beyond 48 hours.

Root cause analysis

To identify the root cause of this performance bottleneck, we analyzed a flame graph of the command during execution.

A flame graph displays the execution path of a command through its stack trace. Each bar corresponds to a function in the code, with the bar's width indicating how much time the command spent executing within that particular function.

When examining the flame graph of git bundle create running on a repository with 10,000 references, approximately 80% of the execution time is consumed by the object_array_remove_duplicates() function. This function was introduced to Git in the commit b2a6d1c686 (bundle: allow the same ref to be given more than once, 2009-01-17).

To understand this change, it's important to know that git bundle create allows users to specify which references to include in the bundle. For complete repository bundles, the --all flag packages all references.

The commit addressed a problem where users providing duplicate references through the command line – such as git bundle create main.bundle main main - would create a bundle without properly handling the duplicated main reference. Unbundling this bundle in a Git repository would break, because it tries to write the same ref twice. The code to avoid duplication uses nested for loops that iterate through all references to identify duplicates. This O(N²) algorithm becomes a significant performance bottleneck in repositories with large reference counts, consuming substantial processing time.

The fix: From O(N²) to efficient mapping

To resolve this performance issue, we contributed an upstream fix to Git that replaces the nested loops with a map data structure. Each reference is added to the map, which automatically ensures only a single copy of each reference is retained for processing.

This change dramatically enhances the performance of git bundle create and enables much better scalability in repositories with large reference counts. Benchmark testing on a repository with 10,000 references demonstrates a 6x performance improvement.

Benchmark 1: bundle (refcount = 100000, revision = master)
  Time (mean ± σ): 	14.653 s ±  0.203 s	[User: 13.940 s, System: 0.762 s]
  Range (min … max):   14.237 s … 14.920 s	10 runs

Benchmark 2: bundle (refcount = 100000, revision = HEAD)
  Time (mean ± σ):  	2.394 s ±  0.023 s	[User: 1.684 s, System: 0.798 s]
  Range (min … max):	2.364 s …  2.425 s	10 runs

Summary
  bundle (refcount = 100000, revision = HEAD) ran
	6.12 ± 0.10 times faster than bundle (refcount = 100000, revision = master)

The patch was accepted and merged into upstream Git. At GitLab, we backported this fix to ensure our customers could benefit immediately, without waiting for the next Git release.

The result: Dramatically decreased backup times

The performance gains from this improvement have been nothing short of transformative:

• From 48 hours to 41 minutes: Creating a backup of our largest repository (gitlab-org/gitlab) now takes just 1.4% of the original time.
• Consistent performance: The improvement scales reliably across repository sizes.
• Resource efficiency: We significantly reduced server load during backup operations.
• Broader applicability: While backup creation sees the most dramatic improvement, all bundle-based operations that operate on many references benefit.

What this means for GitLab customers

For GitLab customers, this enhancement delivers immediate and tangible benefits on how organizations approach repository backup and disaster recovery planning:

• Transformed backup strategies
  • Enterprise teams can establish comprehensive nightly schedules without impacting development workflows or requiring extensive backup windows.
  • Backups can now run seamlessly in the background during nightly schedules, instead of needing to be dedicated and lengthy.
• Enhanced business continuity
  • With backup times reduced from days to minutes, organizations significantly minimize their recovery point objectives (RPO). This translates to reduced business risk – in a disaster scenario, you're potentially recovering hours of work instead of days.
• Reduced operational overhead
  • Less server resource consumption and shorter maintenance windows.
  • Shorter backup windows mean reduced compute costs, especially in cloud environments, where extended processing time translates directly to higher bills.
• Future-proofed infrastructure
  • Growing repositories no longer force difficult choices between backup frequency and system performance.
  • As your codebase expands, your backup strategy can scale seamlessly alongside it

Organizations can now implement more robust backup strategies without compromising on performance or completeness. What was once a challenging trade-off has become a straightforward operational practice.

Starting with the GitLab 18.0 release, all GitLab customers regardless of their license tier can already fully take advantage of these improvements for their backup strategy and execution. There is no further change in configuration required.

What's next

This breakthrough is part of our ongoing commitment to scalable, enterprise-grade Git infrastructure. While the improvement of 48 hours to 41 minutes for backup creation time represents a significant milestone, we continue to identify and address performance bottlenecks throughout our stack.

We're particularly proud that this enhancement was contributed upstream to the Git project, benefiting not just GitLab users but the broader Git community. This collaborative approach to development ensures that improvements are thoroughly reviewed, widely tested, and available to all.

Deep infrastructure work like this is how we approach performance at GitLab. Join the GitLab 18 virtual launch event to see what other fundamental improvements we're shipping. Register today!

Here's where GitLab Duo with Amazon Q, our new offering that delivers agentic AI throughout the software development lifecycle for AWS customers, comes in to transform your review process. This intelligent, AI-powered solution can perform comprehensive code reviews for you in a fraction of the time it would take your human colleagues. By leveraging advanced agentic AI capabilities, GitLab Duo with Amazon Q streamlines your entire review workflow without sacrificing the quality and thoroughness you need. Think of it as having an always-available, highly skilled reviewer who can instantly analyze your code and provide actionable feedback.

How it works: Launching a code review

So how does GitLab Duo with Amazon Q actually work? Let's say you've just finished working on a feature and created a merge request with multiple code updates. Instead of pinging your teammates and waiting for their availability, you simply enter a quick command in the comment section: "/q review". That's it – just those two words trigger the AI to spring into action.

Once you've entered the command, Amazon Q Service immediately begins analyzing your code changes. You'll see a confirmation that the review is underway, and within moments, the AI is examining every line of your updates, checking for potential issues across multiple dimensions. When the review completes, you receive comprehensive feedback that covers all the bases: bug detection, readability improvements, syntax errors, and adherence to your team's coding standards. The AI doesn't just point out problems, it provides context and suggestions for fixing them, making it easy for you to understand what needs attention and why.

The beauty of this agentic AI approach is that it handles the heavy lifting of code review while you focus on what matters most: building great software. You get the benefits of thorough code reviews — better bug detection, consistent coding standards, and improved code quality — without the time sink. Your deployment times shrink dramatically because you're no longer waiting in review queues, and your entire team becomes more productive.

Why use GitLab Duo with Amazon Q?

GitLab Duo with Amazon Q transforms your development workflow in the following ways:

• Lightning-fast code reviews that don't compromise on quality
• Consistent application of coding standards across your entire codebase
• Immediate feedback that helps you fix issues before they reach production
• Reduced deployment times that let you ship features faster
• More time for your team to focus on creative problem-solving instead of repetitive reviews

Ready to see this game-changing feature in action? Watch how GitLab Duo with Amazon Q can revolutionize your code review process:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/4gFIgyFc02Q?si=GXVz--AIrWiwzf-I" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

To learn more about GitLab Duo with Amazon Q visit us at an upcoming AWS Summit in a city near you or reach out to your GitLab representative.

And make sure to join the GitLab 18 virtual launch event to learn about our agentic AI plans and more. Register today!

"GitLab is the most all-in-one of the all-in-one solutions and suits enterprises looking to standardize with a single purchase.” - Forrester Wave™: DevOps Platforms, Q2 2025

For us, this recognition reflects what we've been hearing from customers: They need to deliver secure software faster, but existing solutions force them to compromise on speed, security, or simplicity. GitLab delivers all three. And with our GitLab 18.0 release in May, we’ve taken this a step further by including AI-native GitLab Duo capabilities — such as test generation, code suggestions, and code refactoring — directly in GitLab Premium and GitLab Ultimate at no additional cost.

Access the report today!

Staying at the forefront of AI transformation, with enterprise control

DevSecOps is rapidly evolving, with AI at the forefront of that change. Unfortunately, many AI tools force a choice: cutting-edge capabilities or enterprise security.

Forrester scored GitLab a 5 – the highest on their scale – for both the AI infusion and AI risk mitigation criteria. We’re pleased to see our focus on building innovative AI capabilities that maintain security is being noticed by more than just our customers.

This dual strength shows up across our GitLab Duo AI offerings, including:

• Duo Workflow (private beta): Autonomous AI agents that handle complex tasks across development, security, and operations — with enterprise-grade guardrails and audit trails.
• Agentic Chat: Contextual, conversational AI assistance for everything from code explanations to test creation — with IP protection and privacy controls built in.
• Code Suggestions: AI assistance that can predictively complete code blocks, define function logic, generate tests, and propose common code like regex patterns.
• AI-native Vulnerability Resolution: Find and fix vulnerabilities with auto explanation and auto-generated merge requests, ensuring a streamlined development process.

Doing more with less

We’ve heard loud and clear that DevSecOps teams don’t need more tools and integrations that help them with part of their software delivery lifecycle. They need a seamless, integrated developer experience that covers the entire SDLC.

We believe GitLab’s scores in the following criteria are validation of our customer-focused strategy:

• Day zero experience: Forrester cited our “strong day zero experience,” noting that “everything is ready to run out-of-the-box,” supported by extensive migration tools and tutorials.
• Developer tooling: Forrester pointed to GitLab Duo with Amazon Q, our agentic AI offering for AWS customers, as well as our cloud development environment, integrated developer platform, and wikis for documentation as examples.
• Project planning and alignment: Forrester noted our "strong compliance center," and that we have tools to drive alignment top-down and bottom-up.
• Pipeline security: Forrester gave us the highest score possible in the pipeline security criterion.
• Build automation and CI: Forrester cited our build automation and CI with multistage build pipelines and strong self-hosted support.

Read the report

For us, being named a Leader in The Forrester Wave™: DevOps Platforms, Q2 2025 speaks to the breadth and depth of our platform’s capabilities, providing a single source of truth for the entire software development lifecycle. No more juggling multiple tools and integrations – GitLab provides a seamless, integrated experience that boosts productivity and reduces friction. We believe this placement reflects the hard work of our team, the many contributions from GitLab’s open source community, the invaluable feedback from our customers, and our dedication to shaping the future of software development.

Access the report today!

Forrester does not endorse any company, product, brand, or service included in its research publications and does not advise any person to select the products or services of any company or brand based on the ratings included in such publications. Information is based on the best available resources. Opinions reflect judgment at the time and are subject to change. For more information, read about Forrester’s objectivity here.

<center><i>How complex it can be to integrate multiple tools into a DevSecOps process</i></center>

<br></br>

The good news is that a solution exists: A comprehensive DevSecOps platform offering a unified approach to software development.

These platforms are built for organizations operating in cloud-based and DevSecOps environments, consolidating all software development stages — from code management, CI/CD processes, task management, and security to AI-driven automation — into a single platform. Centralizing all software development workflows in a unified interface enables development and operations teams to work more efficiently, streamline communication, and minimize operational complexities and disruptions.

Furthermore, the developer experience significantly improves — engineers are much happier working with a product designed specifically for modern development needs.

In the sections below, we’ll explore how GitLab helps teams overcome common challenges — whether it’s managing projects and tasks, ensuring security and compliance, or adopting AI-powered development tools – all within a single, unified platform.

Integrated Agile project management

GitLab provides a holistic solution in which project and task management are fully integrated across all stages of the software development lifecycle, such as CI/CD, enabling real-time tracking of development progress. Issues and epics directly link to automation processes, allowing a seamless flow from planning to production deployment. This approach enhances transparency across teams, reduces delays, and ensures that all stakeholders have a clear view of the development status in real-time.

Built-in security

GitLab strongly emphasizes integrating security capabilities end-to-end (security first). The platform integrates a wide range of automated security scanners, including:

• Dependency Scanning
• Static Application Security Testing (SAST)
• Dynamic Application Security Testing (DAST)
• Secret Detection
• Container Scanning

<center><i>Security scanning capabilities integrated into the CI/CD process at various development stages</i></center>

<br></br>

These security checks are built directly into every phase of the software development lifecycle, including the CI/CD pipeline, to provide developers with immediate feedback on potential security issues early in the development cycle.

Compliance and regulatory requirements

Beyond efficiency and user experience, many organizations — especially those in regulated industries such as financial institutions or large enterprises — must ensure their processes comply with strict security and compliance standards. They need the ability to enforce policies for different projects, such as mandating a security scanner every time a CI/CD pipeline runs on specific code branches (e.g., main or protected branches) or requiring specific approvals before merging code into the main branch.

With GitLab, this becomes easier through Compliance Frameworks, a feature that allows organizations to define and enforce structured policies for selected projects. This ensures compliance with automatic regulatory and security requirements while maintaining a seamless and efficient developer workflow.

AI-powered development

GitLab Duo provides AI-driven assistance across all development stages, eliminating the need to switch to external tools. Every AI-powered request is processed within the full context of the project and codebase, enabling smarter and more efficient work.

AI can perform example tasks such as:

• automatic task description generation
• smart summarization of issue discussions, saving developers valuable time
• advanced code review capabilities
• code improvement and optimization suggestions
• automated test generation
• security vulnerability detection and remediation
• troubleshooting root cause analysis for CI pipeline failures
• privacy and Data Security

Understanding the needs of regulated organizations, particularly in the public and financial sectors, GitLab offers a unique solution for running AI models in a secure environment. GitLab Duo Self-Hosted enables organizations to maintain full control over data privacy, security, and the deployment of large language models (LLMs) in their own infrastructure, ensuring:

• data privacy protection
• compliance with regulatory requirements
• maximum security
• AI benefits without external network dependencies or risks

Summary

Organizations need a comprehensive DevSecOps platform to streamline processes, enhance security, and accelerate innovation. GitLab delivers precisely that — a single application consolidating all essential development, security, and operational tools with built-in security integration and AI-powered automation.

Ready to see GitLab in action? Explore interactive demos of:

• GitLab Premium and Ultimate with Duo – experience AI-powered development assistance

• Adding security to the CI/CD pipeline – see how integrated security scanning protects your software

• Compliance frameworks – discover how GitLab enforces policies across projects for better governance

Join the GitLab 18 virtual launch event to learn about the future of the DevSecOps platform, including the role of agentic AI. Register today!

Meet the next generation of GitLab Duo Chat – GitLab Duo Agentic Chat, a significant evolution in AI-native development assistance and the newest addition to our platform, now in experimental release. GitLab Duo Agentic Chat is currently available as an experimental feature in VS Code to all users on GitLab.com that have any one of these add-ons: Duo Core, Duo Pro, or Duo Enterprise.

Agentic Chat transforms chat from traditional conversational AI to a chat experience that takes action on your behalf, breaking down complex problems into discrete tasks that it can complete. Instead of simply responding to questions with the context you provide, Agentic Chat can:

• Autonomously determine what information it needs to answer your questions
• Execute a sequence of operations to gather that information from multiple sources
• Formulate comprehensive responses by combining insights from across your project
• Create and modify files to help you implement solutions

And all of this is done while keeping the human developer within the loop.

Agentic Chat is built on the Duo Workflow architecture, which is currently in private beta. The architecture comprises agents and tools that take on specific tasks like finding the right context for a given question or editing files.

Use cases for GitLab Duo Agentic Chat

Here are some real-world and common use cases for Agentic Chat:

• Onboard to new projects faster by having AI help you familiarize yourself with a new codebase.

• Jump into assigned work immediately, even when issue descriptions are unclear, because Agentic Chat can help you connect the dots between requirements and existing implementations.

• When it's time to make changes, Agentic Chat can handle the implementation work by creating and editing multiple files across your project.

• At release time, Agentic Chat can help you verify that your solution actually addresses the original requirements by analyzing your merge requests against the initial issue or task.

<center><i>Agentic Chat making code edits</i></center>

From learning to shipping: A complete workflow demonstration in four steps

To show how Agentic Chat transforms the development experience, let's walk through a real scenario from our engineering teams. Imagine you're a new team member who's been assigned an issue but knows nothing about the codebase. You can follow along with this video demonstration:

<!-- blank line --> <figure class="video_container"> <iframe src="https://www.youtube.com/embed/uG9-QLAJrrg?si=kaOhYylMIaWkIuG8j" frameborder="0" allowfullscreen="true"> </iframe> </figure> <!-- blank line -->

Step 1: Understand the project

Instead of manually exploring files and documentation, you can prompt Agentic Chat:

I am new to this project. Could you read the project structure and explain it to me?

Agentic Chat provides a comprehensive project overview by:

• Exploring the directory structure
• Reading README files and documentation
• Identifying key components and applications

Step 2: Understand your assigned task

Next, you need to understand your specific assignment, so you can enter this prompt:

I have been assigned Issue 1119. Could you help me understand this task, specifically where do I need to apply the refactoring?

Agentic Chat explains the task and proposes a refactoring approach by:

• Retrieving and analyzing the issue details from the remote GitLab server
• Examining relevant project files
• Identifying the specific locations requiring changes

Step 3: Implement the solution

Rather than doing the work manually, you can request:

Could you make the edits for me? Please start with steps one, two, three.

Agentic Chat then:

• Creates new directories and files as needed
• Extracts and refactors code across multiple locations
• Ensures consistency across all modified files
• Provides a summary of all changes made

Step 4: Verify completion

Finally, after creating your merge request, you can verify your work:

Does my MR fully address Issue 1119? 

Agentic Chat confirms whether all requirements have been met by analyzing both your merge request and the original issue.

Try it today and share your feedback

GitLab Duo Agentic Chat is currently available as an experimental feature in VS Code to all users on GitLab.com that have any one of these add-ons: Duo Core, Duo Pro, or Duo Enterprise. See our setup documentation for prerequisites and configuration steps.

As an experimental feature, Agentic Chat has some known limitations we're actively addressing, including slower response times due to multiple API calls, keyword-based rather than semantic search, and limited support for new local folders or non-GitLab projects. Your feedback is crucial in helping us prioritize improvements and bring Agentic Chat to general availability so please share your experience in this issue.

What's next?

We are fully focused on improving Agentic Chat, including bringing it to general availability. In the meantime, we are aiming to improve response times and are adding capabilities that GitLab Duo Chat currently has, such as using self-hosted models or supporting JetBrains and Visual Studio in addition to VS Code. Once we have switched Duo Chat to this new architecture we plan to also bring Agentic Chat to the chat in the GitLab web application. We also plan to add a lot more functionality, such as editing GitLab artifacts, supporting context from custom Model Context Protocol, or MCP, servers, and offering commands to run in the terminal.

Ready to experience autonomous development assistance but not yet a GitLab customer? Try Agentic Chat today as part of a free, 60-day trial of GitLab Ultimate with Duo Enterprise and help shape the future of AI-powered development. Follow these setup steps for VS Code.

And make sure to join the GitLab 18 virtual launch event to learn about our agentic AI plans and more. Register today!

Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab.

Learn more

• GitLab Duo Workflow: Enterprise visibility and control for agentic AI
• What is agentic AI?
• Agentic AI guides and resources

In this article, you will learn how LLMs work, their practical applications, and the main challenges to overcome in order to fully harness their potential.

What is an LLM?

LLMs are artificial intelligence (AI) systems that can process and generate text autonomously. They are trained by analyzing vast amounts of data from a variety of sources, enabling them to master the linguistic structures, contextual relationships, and nuances of language.

LLMs are a major breakthrough in the field of AI. Their ability to process, generate, and interpret text relies on sophisticated machine learning and natural language processing (NLP) techniques. These systems do not just process individual words; they analyze complex sequences to capture the overall meaning, subtle contexts, and linguistic nuances.

How do LLMs work?

To better understand how they work, let's explore some of the key features of large language models.

Supervised and unsupervised learning

LLMs are trained using two complementary approaches: supervised learning and unsupervised learning. These two approaches to machine learning maximize their ability to analyze and generate text.

• Supervised learning relies on labeled data, where each input is associated with an expected output. The model learns to associate these inputs with the correct outputs by adjusting its internal parameters to reduce prediction errors. Through this approach, the model acquires precise knowledge about specific tasks, such as text classification or named entity recognition.

• Unsupervised learning (or machine learning), on the other hand, does not require labeled data. The model explores large volumes of text to discover hidden structures and identify semantic relationships. The model is therefore able to learn recurring patterns, implicit grammatical rules in the text, and contextualization of sentences and concepts. This method allows LLMs to be trained on large corpora of data, greatly accelerating their progress without direct human action.

By combining these two approaches, large language models gain the advantages of both precise, human-guided learning and unlimited autonomous exploration. This complementarity allows them to develop rapidly, while continuously improving their ability to understand and generate text coherently and contextually.

Learning based on a large volume of data

LLMs are trained on billions of sentences from a variety of sources, such as news articles, online forums, technical documentation, scientific studies, and more. This variety of sources allows them to acquire a broad and nuanced understanding of natural language, ranging from everyday expressions to specialized terminology.

The richness of the data used is a key factor in LLMs' performance. Each source brings different writing styles, cultural contexts, and levels of technicality.

For example:

• News articles to master informative and factual language
• Online forums to understand specialized communities' informal conversations and technical language
• Technical documentation and scientific studies to assimilate complex concepts and specific terminology, particularly in areas such as DevOps and DevSecOps

This diversity of content allows LLMs to recognize complex linguistic structures, interpret sentences in different contexts, and adapt to highly technical domains. In DevSecOps, this means understanding commands, configurations, security protocols, and even concepts related to the development and maintenance of computer systems.

With this large-scale training, LLMs can accurately answer complex questions, write technical documentation, or identify vulnerabilities in computer systems.

Neural network architecture and "deep learning"

LLMs are based on advanced neural network architectures. These networks are specially designed to process large sequences of text while maintaining an accurate understanding of the context. This deep learning-based training is a major asset in the field of NLP.

The best-known of these structures is the architecture of sequence-to-sequence models (transformers). This architecture has revolutionized NLP with its ability to simultaneously analyze all parts of a text, unlike sequential approaches that process words one by one.

Sequence-to-sequence models excel at processing long texts. For example, in a conversation or a detailed technical document, they are able to link distant information in the text to produce precise and well-reasoned answers. This context management is essential in a DevSecOps approach, where instructions can be complex and spread over multiple lines of code or configuration steps.

Predictive text generation

When the user submits a text, query, or question, an LLM uses its predictive ability to generate the most likely sequence, based on the context provided.

The model analyzes each word, studies grammatical and semantic relationships, and then selects the most suitable terms to produce a coherent and informative text. This approach makes it possible to generate precise, detailed responses adapted to the expected tone.

In DevSecOps environments, this capability becomes particularly useful for:

• Coding assistance: generation of code blocks or scripts adapted to specific configurations
• Technical problem solving: proposing solutions based on descriptions of bugs or errors
• Drafting technical documentation: automatic creation of guides, manuals, or instructions

Predictive text generation thus makes it possible to automate many repetitive tasks and speed up technical teams' work.

Applications of large language models in a DevSecOps approach

With the rise of automation, LLMs have become indispensable allies for technical teams. Their ability to understand and generate text contextually enables them to effectively operate in complex environments such as DevSecOps.

With their analytical power and ability to adapt to specific needs, these models offer tailored solutions to streamline processes and lighten technical teams' workload.

Development teams can leverage LLMs to automatically transform functional specifications into source code.

With this capability, they can perform the following actions:

• generate complex automation scripts
• create CI/CD pipelines tailored to specific business processes
• produce customized security patches
• generate code explanation and create documentation
• refactor code by improving code structure and readability without changing functionality
• generate tests

By relying on LLMs, teams are able to accelerate the development of their software while reducing the risk of human error.

Improved documentation and knowledge sharing

These powerful tools make it easy to create customized user manuals, API descriptions, and tutorials that are perfectly tailored to each user's level of expertise. By leveraging existing knowledge bases, LLMs create contextual answers to frequently asked questions. This enhances knowledge sharing within teams, speeds up onboarding of new members, and helps centralize best practices.

Incident management and troubleshooting

During an incident, LLMs play a crucial role in analyzing logs and trace files in real time. Thanks to their ability to cross-reference information from multiple sources, they identify anomalies and propose solutions based on similar past incidents. This approach significantly reduces diagnosis time. In addition, LLMs can automate the creation of detailed incident reports and recommend specific corrective actions.

Creating and improving CI/CD pipelines

LLMs are revolutionizing the configuration of CI/CD pipelines. They can not only help create pipelines, but also automate this process and suggest optimal configurations based on industry standards. By adapting workflows to your specific needs, they ensure perfect consistency between different development environments. Automated testing is enhanced by relevant suggestions, limiting the risk of failure. LLMs also continuously monitor the efficiency of pipelines and adjust processes to ensure smooth and uninterrupted rollout.

Security and compliance

In a DevSecOps environment, large language models become valuable allies for security and compliance. They parse the source code for potential vulnerabilities and generate detailed patch recommendations. LLMs can also monitor the application of security standards in real time, produce comprehensive compliance reports, and automate the application of security patches as soon as a vulnerability is identified. This automation enhances overall security and ensures consistent compliance with legal and industry requirements.

What are the benefits of large language models?

LLMs are radically reshaping DevOps and DevSecOps approaches, bringing substantial improvements in productivity, security, and software quality. By integrating with existing workflows, LLMs are disrupting traditional approaches by automating complex tasks and providing innovative solutions.

Improved productivity and efficiency

LLMs play a central role in improving technical teams' productivity and efficiency. By automating a wide range of repetitive tasks, they free development teams from routine operations, allowing them to focus on strategic activities with higher added value.

In addition, LLMs act as intelligent technical assistants capable of instantly providing relevant code snippets, tailored to the specific context of each project. In this way, they significantly reduce research time by offering ready-to-use solutions to assist teams in their work. This targeted assistance speeds up problem solving and reduces disruptions in workflows. As a result, productivity increases and projects move forward more quickly. Technical teams can take on more tasks without compromising the quality of deliverables.

Improved code quality and security

The use of large language models in software development is a major lever for improving both code quality and application security. With their advanced analytical capabilities, LLMs can scan source code line by line and instantly detect syntax errors, logical inconsistencies, and potential vulnerabilities. Their ability to recognize defective code allows them to recommend appropriate fixes that comply with industry best practices.

LLMs also play a key preventive role. They excel at identifying complex security flaws that are often difficult for humans to detect. By analyzing dependencies, they can flag obsolete or vulnerable libraries and recommend more secure, up-to-date versions. This approach contributes to maintaining a secure environment that complies with current security standards.

Beyond fixing existing errors, LLMs offer improvements by suggesting optimized coding practices and project structures. They can generate code that meets the most advanced security standards from the earliest stages of development.

Accelerating development lifecycles

Large language models play a key role in accelerating software development lifecycles by automating key tasks that would otherwise tie up valuable human resources. Complex and repetitive tasks, such as writing functions, creating unit tests, or implementing standard components, are automated in a matter of moments.

LLMs also speed up the validation phase with their ability to suggest complete and appropriate test cases. They ensure broader test coverage in less time, reducing the risk of errors and enabling early detection of anomalies. This preventive approach shortens the correction cycle and limits delays related to code quality issues.

By simplifying technical tasks and providing fast and tailored solutions, large language models enable businesses to respond to market demands in a more agile way. This acceleration of the development lifecycle results in more frequent updates, faster iterations, and a better ability to adapt products to users' changing needs.

Development lifecycles are becoming shorter, providing a critical strategic advantage in an increasingly demanding technology landscape.

What are the challenges of using LLMs?

Despite their many benefits, large language models have certain limitations that require careful management. Their effectiveness depends heavily on the quality of the data used during their training and regular updates to their knowledge bases. In addition, issues related to algorithmic bias, data security, and privacy can arise, exposing companies to operational and legal risks. Rigorous human oversight remains essential in order to ensure the reliability of results, maintain regulatory compliance, and prevent critical errors.

Data privacy and security

Training LLMs relies on large volumes of data, often from diverse sources, raising questions about the protection of confidential information. Sensitive data shared with cloud platforms can therefore be exposed to potential breaches. This is of particular concern to companies operating in regulated sectors.

In Europe, where strict regulations like GDPR govern data management, many companies are reluctant to transfer their information to external services. Regulatory requirements, coupled with the fear of unauthorized exploitation of sensitive data, have led some companies to opt for self-hosted solutions to maintain complete control over their systems.

Providers like GitLab have put in place robust security guarantees, such as intentional non-retention of personal data and end-to-end encryption. However, this may not be enough for the most demanding customers, who prefer complete control of their environments. Implementing hybrid or on-premises solutions then becomes a strategic necessity to meet the security requirements of certain companies.

Learn more about GitLab Duo Self-Hosted by clicking on the image below to access our product tour.

Accuracy and reliability

Although large language models are capable of producing impressive results, their performance is not infallible. They can produce incorrect, incomplete, or inconsistent answers. This inaccuracy becomes particularly problematic in the context of critical tasks such as generating security code or analyzing sensitive data.

In addition, LLMs operate on the basis of probabilistic models, which means that they do not truly "understand" the content they process, but produce predictions based on statistical probabilities. This can lead to technically incorrect or even dangerous recommendations when used without human validation.

To avoid these pitfalls, it is essential to maintain constant oversight and establish rigorous validation processes. The results provided by LLMs must always be reviewed by humans before being integrated into critical systems.

A strategy of regular model updates, combined with proactive human oversight, can reduce errors and gradually improve the reliability of results.

How GitLab uses LLMs for GitLab Duo features

GitLab Duo harnesses the power of large language models to transform DevSecOps processes by integrating AI-powered capabilities throughout the software development lifecycle. This approach aims to improve productivity, strengthen security, and automate complex tasks so that development teams can focus on high added-value tasks.

AI-assisted software development

GitLab Duo provides continuous support throughout the software development lifecycle with real-time recommendations. Development teams can automatically generate unit tests, get detailed explanations of complex code segments, and benefit from suggestions to improve the quality of their code.

Proactive CI/CD failure analysis

One of the key features of GitLab Duo is its assistance in analyzing CI/CD job failures. With LLM and AI, teams are able to quickly identify sources of errors in their continuous integration and deployment pipelines.

Enhanced code security

GitLab Duo incorporates AI-based security features. The system detects vulnerabilities in the source code and proposes detailed patches to reduce the risks. Teams receive clear explanations of the nature of the vulnerabilities identified and can apply automated patches via merge requests generated directly by GitLab Duo. This feature helps secure development without slowing down development lifecycles.

Learn more about GitLab Duo Vulnerability Explanation and Resolution by clicking on the image below to access our product tour.

Key features of GitLab Duo

• GitLab Duo Chat: This conversational feature processes and generates text and code intuitively. It allows users to quickly search for relevant information in large volumes of text, including in tickets, epics, source code, and GitLab documentation.

• GitLab Duo Self-Hosted: GitLab Duo Self-Hosted allows companies with strict data privacy requirements to benefit from GitLab Duo's AI capabilities with flexibility in choosing deployment and LLMs from a list of supported options.

• GitLab Duo Code Suggestions: Development teams benefit from automated code suggestions, allowing them to write secure code faster. Repetitive and routine coding tasks are automated, significantly speeding up software development lifecycles.

GitLab Duo is not limited to these features. It offers a wide range of features designed to simplify and optimize software development. Whether it's automating testing, improving collaboration between teams, or strengthening project security, GitLab Duo is a complete solution for smart and efficient DevSecOps processes.

Learn more about GitLab Duo Enterprise by clicking on the image below to access our product tour.

In an earlier article, we explored GitLab CI/CD. Now, let's dive deeper into the world of CI/CD variables and unlock their full potential.

What are CI/CD variables?

CI/CD variables are dynamic key-value pairs that you can define at different levels within your GitLab environment (e.g., project, group, or instance). These variables act as placeholders for values that you can use in your .gitlab-ci.yml file to customize your pipelines, securely store sensitive information, and make your CI/CD configuration more maintainable.

Why are CI/CD variables important?

CI/CD variables offer numerous benefits:

• Flexibility - Easily adapt your pipelines to different environments, configurations, or deployment targets without modifying your core CI/CD script.
• Security - Securely store sensitive information like API keys, passwords, and tokens, preventing them from being exposed directly in your code.
• Maintainability - Keep your CI/CD configuration clean and organized by centralizing values in variables, making updates and modifications easier.
• Reusability - Define variables once and reuse them across multiple projects, promoting consistency and reducing duplication.

Scopes of CI/CD variables: Project, group, and instance

GitLab allows you to define CI/CD variables with different scopes, controlling their visibility and accessibility:

• Project-level variables - These variables are specific to a single project and are ideal for storing project-specific settings, such as:

  • Deployment URLs: Define different URLs for staging and production environments.
  • Database credentials: Store database connection details for testing or deployment.
  • Feature flags: Enable or disable features during different stages of your pipeline.
  • Example: You have a project called "MyWebApp" and want to store the production deployment URL. You create a project-level variable named DPROD_DEPLOY_URL with the value https://mywebapp.com.

• Group-level variables - These variables are shared across all projects within a GitLab group. They are useful for settings that are common to multiple projects, such as:

  • API keys for shared services: Store API keys for services like AWS, Google Cloud, or Docker Hub that are used by multiple projects within the group.
  • Global configuration settings: Define common configuration parameters that apply to all projects in the group.
  • Example: You have a group called "Web Apps" and want to store an API key for Docker Hub. You create a group-level variable named DOCKER_HUB_API_KEY with the corresponding API key value.

• Instance-level variables - These variables are available to all projects on a GitLab instance. They are typically used for global settings that apply across an entire organization such as:

  • Default runner registration token: Provide a default token for registering new runners.
  • License information: Store license keys for GitLab features or third-party tools.
  • Global environment settings: Define environment variables that should be available to all projects.
  • Example: You want to set a default Docker image for all projects on your GitLab instance. You create an instance-level variable named DEFAULT_DOCKER_IMAGE with the value ubuntu:latest.

Defining CI/CD variables

To define a CI/CD variable:

1. Click on the Settings > CI/CD buttons for your project, group, or instance.
2. Go to the Variables section.
3. Click Add variable.
4. Enter the key (e.g., API_KEY) and value.
5. Optionally, check the Protect variable box for sensitive information. This ensures that the variable is only available to pipelines running on protected branches or tags.
6. Optionally, check the Mask variable box to hide the variable's value from job logs, preventing accidental exposure.
7. Click Save variable.

Using CI/CD variables

To use a CI/CD variable in your .gitlab-ci.yml file, simply prefix the variable name with $:

deploy_job:
  script:
    - echo "Deploying to production..."
    - curl -H "Authorization: Bearer $API_KEY" https://api.example.com/deploy

Predefined CI/CD variables

GitLab provides a set of predefined CI/CD variables that you can use in your pipelines. These variables provide information about the current pipeline, job, project, and more.

Some commonly used predefined variables include:

• $CI_COMMIT_SHA: The commit SHA of the current pipeline.
• $CI_PROJECT_DIR: The directory where the project is cloned.
• $CI_PIPELINE_ID: The ID of the current pipeline.
• $CI_ENVIRONMENT_NAME: The name of the environment being deployed to (if applicable).

Best practices

• Securely manage sensitive variables: Use protected and masked variables for API keys, passwords, and other sensitive information.
• Avoid hardcoding values: Use variables to store configuration values, making your pipelines more flexible and maintainable.
• Organize your variables: Use descriptive names and group related variables together for better organization.
• Use the appropriate scope: Choose the correct scope (project, group, or instance) for your variables based on their intended use and visibility.

Unlock the power of variables

CI/CD variables are a powerful tool for customizing and securing your GitLab pipelines. By mastering variables and understanding their different scopes, you can create more flexible, maintainable, and efficient workflows.

We hope you found it helpful and are now well-equipped to leverage the power of GitLab for your development projects.

Get started with CI/CD variables today with a free, 60-day trial of GitLab Ultimate with Duo Enterprise.

"Getting Started with GitLab" series

Read more articles in our "Getting Started with GitLab" series:

• How to manage users
• How to import your projects to GitLab
• Mastering project management
• Automating Agile workflows with the gitlab-triage gem
• Understanding CI/CD

GitLab.com stores your password securely, salted and hashed with bcrypt. Your password goes through a one-way hashing transformation before storage, securing your password and ensuring it is not possible to extract the original password from storage. The representation is also unique: Even if two users shared the same password, the results of the one-way transformations would be completely different. However, these safeguards intentionally make it impractical to identify all users with a compromised or otherwise weak password.

Starting on June 19, 2025, GitLab will be introduce compromised password detection during sign-in for all GitLab.com users. This works by securely comparing the password you log in with against a database of known compromised credentials during authentication. If the password is correct but matches known compromised credentials, you will be alerted with a banner on GitLab.com and you will be sent an email notification until you change your password.

Note: Compromised password detection is only for logins using GitLab’s native username and password and does not apply to credentials used through SSO.

Example compromised password warning banner:

We’re excited to introduce this additional countermeasure to help ensure your account is secure. We also encourage users to take these additional preventive actions to maintain the security of your account(s):

1. Use a strong password unique to your GitLab.com account. GitLab disallows weak passwords that are considered compromised or that contain part of your name, email address, or predictable words. We strongly recommend using a password manager like 1Password, Google Password Manager, or Apple Passwords, as well.
2. Set up two-factor authentication for your GitLab.com account. GitLab supports time-based, one-time password applications, like Google Authenticator and WebAuthn, with a PIN/fingerprint or a hardware security key.
3. Prevent yourself from getting locked out of your account. Change your primary email address if you no longer have access, and ensure you have recovery codes in case your two-factor authentication device is lost or stolen. Also, consider setting up an alternative method for two-factor authentication.
4. Stay aware of new risks. Register with a service like haveibeenpwned.com to receive an email notification if your email address appears in a newly disclosed breach. This service is free to use and requires only your email address at registration.

To learn more about trust and security measures on GitLab.com, visit the GitLab security page, highlighting the GitLab Trust Center, compliance certifications, and security measures that keep users and customers safe on our platform.

This video walks through visually what you'll read below:

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1085078036?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="Refactor JavaScript to TypeScript with GitLab Duo Workflow"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

The challenge: Refactor JS to TS

We decided to migrate Duo Workflow client-related logic to TypeScript for better type safety and auto-complete. A JavaScript-to-TypeScript migration involves more than just changing file extensions. It requires:

1. Analyzing existing code patterns to determine appropriate types
2. Handling edge cases where type inference is ambiguous
3. Ensuring consistency across the codebase
4. Managing dependencies and third-party libraries
5. Validating that runtime behavior remains unchanged

Doing all of this work manually can be very time consuming and not much fun. Thankfully, managing your projects is easier and more efficient with Duo Workflow – even when the project is Duo Workflow.

How it works

If you've used AI coding assistants before, you're likely familiar with their chat-based interfaces (like GitLab Duo Chat). These chats can provide code snippets, suggested directory structures, and more. GitLab Duo Workflow fundamentally differs from these in several key ways:

1. It's contextually aware of your entire codebase, not just open files or highlighted text. You can also add context from relevant GitLab issues or merge requests.
2. It develops and executes a multi-stage plan, allowing for more complete solutions.
3. It keeps a human in the loop, ensuring you understand and approve of what is happening at each step of the way.
4. It stages changes to your repository, giving you control over what to accept.

Duo Workflow uses an agentic AI approach, powered by Claude 3.5 Sonnet, to understand code semantics while maintaining a deep integration with GitLab's DevOps platform.

Let's walk through a real-world example of refactoring a JavaScript file using GitLab Duo Workflow. In our case, we started with the prompt:

I need to refactor a JavaScript file packages/webview_duo_workflow/src/app/stores/workflow.js to TypeScript. Please analyze the code, identify any issues, and convert it to TypeScript with appropriate type definitions.

Analysis

After prompting, Duo Workflow first analyzed the codebase structure:

• Identified that workflow.js is a Pinia store implementation
• Noted it uses imports from various modules including constants.ts (which was already in TypeScript)
• Recognized GraphQL queries import exists but the file wasn't accessible

Based on this analysis, Duo Workflow identified specific typing needs:

Type definitions needed for:

• Store State interface with precise types:
  • areWorkflowsLoading: boolean
  • isLoadingWorkflow: boolean
  • isLoadingRecentWorkflows: boolean
  • recentWorkflows: array
  • workflows: array
  • workflowsPageInfo: object
  • initialState: object
  • activeWorkflow: object with specific shape

Interface definitions required:

• Workflow interface with properties:
  • id: string
  • goal: string
  • status: string
  • checkpoint: object
  • type: string

Parameter types needed for:

• GraphQL response types for workflows data
• Event handler parameter types
• Function parameter types for actions like getWorkflowById, runWorkflow, etc.

Duo Workflow identified several complex patterns requiring special handling:

• Uses optional chaining extensively
• Has nested object destructuring
• Contains GraphQL integration
• Uses Pinia store patterns with state, getters, and actions
• Implements an events mapping system

The system recognized external type dependencies:

• Pinia store types
• GraphQL query response types
• Functions from an internal Bridge module were also properly recognized (for sendRequest, sendGraphqlRequest)

The final analysis concluded: "The file will need to be renamed from .js to .ts and appropriate type definitions added while maintaining the existing functionality."

Planning

Based on this thorough analysis, Duo Workflow created a structured plan consisting of specific tasks:

1. Create a new TypeScript file workflow.ts in the same directory as the original JS file.

2. Create TypeScript interfaces for the store state and workflow types at the top of the new file, including:

   • WorkflowState interface for store state
   • Workflow interface for workflow object structure
   • WorkflowPageInfo interface for pagination info
   • WorkflowCheckpoint interface for checkpoint data

3. Copy and add type annotations to the store implementation from workflow.js, including:

   • State return type
   • Getter return types
   • Action parameter types
   • Action return types

4. Update all imports in workflow.ts to:

   • Add type imports from Pinia
   • Update local imports to use .ts extensions where applicable
   • Import any required type definitions

Execution

After the plan is complete, we were prompted to “Approve plan.” Before clicking approve, we reviewed each step and ensured we were comfortable with the plan. After approval, Duo Workflow showed its progress through each step with visual indicators and explanations of what API operations were supporting each task (like "Supported by: create_file_with_contents" or "Supported by: edit_file"). When the work was done, we reviewed the changes before committing.

What we learned

This JavaScript-to-TypeScript migration example showcases a significant evolution in AI-assisted development. What makes GitLab Duo Workflow particularly interesting is its approach to:

Task-oriented programming vs. suggestion-only assistance

Unlike many AI assistants that simply offer code snippets or suggestions, Duo Workflow understands and executes complete tasks. The difference is significant — rather than saying "here's some TypeScript code you might use," it says "I'll convert this file for you, here's my plan, and here are the changes I'm making."

Contextual understanding of the entire codebase

The tool demonstrates awareness of project structure, related files (like constants.ts and GraphQL queries), and the relationships between components. This contextual understanding allows for more sophisticated conversions than localized transformations.

Step-by-step execution with visibility

The plan-based approach, with clear steps and progress indicators, provides transparency into what would otherwise be a black-box process. This allows developers to understand what the AI is doing and how it's approaching the problem.

GitLab Duo Workflow is currently available in private beta for GitLab Ultimate customers. Sign up for the waitlist today!

Learn more

• Agentic AI guides and resources
• GitLab Duo Workflow
• What is agentic AI?

Securing your Maven repository: A comprehensive approach

Securing your software supply chain is more critical than ever so let's dive into strategies to fortify your Maven packages in GitLab.

Implement strong authentication

Personal access tokens: Use PATs for fine-grained access control.

For example:

mvn deploy -s settings.xml

Where settings.xml contains:

<settings>
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>${env.GITLAB_PERSONAL_TOKEN}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Deploy tokens: Ideal for CI/CD pipelines. Generate these in your GitLab project settings and use them in your .gitlab-ci.yml.

deploy:
  script:
    - 'mvn deploy -s ci_settings.xml'
  variables:
    MAVEN_CLI_OPTS: "-s ci_settings.xml --batch-mode"
    MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
  only:
    - main

The corresponding ci_settings.xml file:

<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Deploy-Token</name>
            <value>${env.CI_DEPLOY_PASSWORD}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

In this setup:

• The CI_DEPLOY_PASSWORD should be set as a CI/CD variable in your GitLab project settings containing the deploy token.
• The <id> should match the repository ID in your project's pom.xml file.

Token rotation: Implement a token rotation policy using GitLab's API. For example, you could create a scheduled pipeline that rotates tokens monthly:

rotate_tokens:
  script:
    - curl --request POST "https://gitlab.example.com/api/v4/projects/${CI_PROJECT_ID}/deploy_tokens" --header "PRIVATE-TOKEN: ${ADMIN_TOKEN}" --form "name=maven-deploy-${CI_PIPELINE_ID}" --form "scopes[]=read_registry" --form "scopes[]=write_registry"
  only:
    - schedules

Leverage GitLab's built-in security features

Dependency Scanning: Enable it in your .gitlab-ci.yml.

include:
  - template: Security/Dependency-Scanning.gitlab-ci.yml

variables:
  DS_JAVA_VERSION: 11

Container Scanning: If you're containerizing your Maven applications.

include:
  - template: Security/Container-Scanning.gitlab-ci.yml

variables:
  CS_IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

License Compliance: Ensure all dependencies comply with your project's licensing requirements.

include:
  - template: Security/License-Scanning.gitlab-ci.yml

Secure your CI/CD pipeline

• CI/CD variables: Store sensitive information securely.

  variables:
    MAVEN_REPO_USER: ${CI_DEPLOY_USER}
    MAVEN_REPO_PASS: ${CI_DEPLOY_PASSWORD}
  

• Masked variables: Prevent exposure in job logs. Set these in your GitLab CI/CD settings.

• Protected branches and tags: Configure these in your GitLab project settings to control who can trigger package publishing.

Implement package signing

• Use the Maven GPG plugin to sign your artifacts.

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>1.6</version>
    <executions>
      <execution>
        <id>sign-artifacts</id>
        <phase>verify</phase>
        <goals>
          <goal>sign</goal>
        </goals>
      </execution>
    </executions>
  </plugin>
  

• Store your GPG key securely using GitLab CI/CD variables.

Control package access

• Use GitLab's project and group-level package registry settings to restrict access.
• Implement IP allowlists for network-level access control in your GitLab instance settings.

Optimize performance: Streamline your Maven workflow

Efficiency is crucial when working with large projects or numerous dependencies. Here are advanced techniques to optimize your Maven package usage in GitLab.

Utilize dependency management

• Use the <dependencyManagement> section in your parent POM.

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-dependencies</artifactId>
        <version>${spring-boot.version}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
  

Leverage multi-module projects

• Structure your project with a parent POM and multiple modules:

  my-project/
  ├── pom.xml
  ├── module1/
  │   └── pom.xml
  ├── module2/
  │   └── pom.xml
  └── module3/
      └── pom.xml
  

• Use Maven's reactor to build modules in the optimal order:

  mvn clean install
  

Implement parallel builds

• Use Maven's parallel build feature:

  mvn -T 4C clean install
  

Optimize for CI/CD

• In .gitlab-ci.yml, use caching to speed up builds:

  cache:
    paths:
      - .m2/repository
  
  build:
    script:
      - mvn clean package -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository
  

• Implement incremental builds:

  build:
    script:
      - mvn clean install -Dmaven.repo.local=$CI_PROJECT_DIR/.m2/repository -am -amd -fae
  

Utilize build caching

• Use the Gradle Enterprise Maven Extension for build caching:

  <build>
    <plugins>
      <plugin>
        <groupId>com.gradle</groupId>
        <artifactId>gradle-enterprise-maven-plugin</artifactId>
        <version>1.9</version>
        <configuration>
          <gradleEnterprise>
            <server>https://ge.example.com</server>
            <allowUntrusted>false</allowUntrusted>
          </gradleEnterprise>
        </configuration>
      </plugin>
    </plugins>
  </build>
  

Introducing the Maven Virtual Registry beta program

I'm thrilled to announce the launch of our beta program for the upcoming Maven virtual registry feature. This addition to our package ecosystem will change how you manage Maven repositories in GitLab.

Key features of Maven Virtual Registry

1. Repository aggregation: Combine multiple Maven repositories (both internal and external) into a single virtual repository.
2. Smart proxy and caching: Improve build times by caching artifacts and intelligently routing requests.
3. Centralized Access Control: Enhance security by managing access to all repositories from a single point.

How it works

1. Configuration: Configure Maven authentication in your settings.xml:

<settings>
  <servers>
    <server>
      <id>gitlab-maven</id>
      <configuration>
        <httpHeaders>
          <property>
            <name>Private-Token</name>
            <value>${env.GITLAB_TOKEN}</value>
          </property>
        </httpHeaders>
      </configuration>
    </server>
  </servers>
</settings>

Authentication options:

• Personal access token: Use Private-Token as the name and ${env.GITLAB_TOKEN} as the value.

• Group deploy token: Use Deploy-Token as the name and ${env.GITLAB_DEPLOY_TOKEN} as the value.

• Group access token: Use Private-Token as the name and ${env.GITLAB_ACCESS_TOKEN} as the value.

• CI job token: Use Job-Token as the name and ${CI_JOB_TOKEN} as the value.

• Configure the virtual registry in your pom.xml.

Option 1: As an additional registry:

<repositories>
  <repository>
    <id>gitlab-maven</id>
    <url>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/<virtual registry id></url>
  </repository>
</repositories>

Option 2: As a replacement for Maven Central (in your settings.xml):

<mirrors>
  <mirror>
    <id>gitlab-maven</id>
    <name>GitLab virtual registry for Maven Central</name>
    <url>https://gitlab.example.com/api/v4/virtual_registries/packages/maven/<virtual registry id></url>
    <mirrorOf>central</mirrorOf>
  </mirror>
</mirrors>

2. Usage: Now all your Maven operations will use the virtual repository.

# For personal access tokens
export GITLAB_TOKEN=your_personal_access_token

# For group deploy tokens
export GITLAB_DEPLOY_TOKEN=your_deploy_token

# For group access tokens
export GITLAB_ACCESS_TOKEN=your_access_token

# Then run Maven commands normally
mvn package

3. Benefits

• Simplified dependency management
• Improved build times
• Enhanced security and compliance
• Better control over third-party dependencies

Join the beta program

We're actively seeking participants for our beta program. As a beta tester, you'll have the opportunity to:

• Get early access to the Maven Virtual Registry feature.
• Provide direct feedback to our development team.
• Shape the future of Maven package management in GitLab.
• Participate in exclusive webinars and Q&A sessions with our product team.

To join the beta program or learn more about the Maven Virtual Registry, please visit the GitLab Maven Virtual Registry Beta Program (Note: This is a placeholder link).

Summary

At GitLab, we're committed to providing cutting-edge tools for secure, efficient, and scalable software development. The Maven Virtual Registry is just one example of how we're continuously innovating to meet the evolving needs of developers and platform engineers.

Implementing the security measures and optimization techniques discussed in this post and leveraging upcoming features like the Maven Virtual Registry can improve your Maven workflow within GitLab.

We're excited about the future of package management in GitLab and can't wait to see how you'll use these features to take your development process to the next level. Stay tuned for more updates and happy coding!

The Federal Risk and Authorization Management Program (FedRAMP) is the gold standard for cloud security across US government agencies. As a mandatory security framework for federal cloud adoption since its 2011 launch, it provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services.

Meeting the growing demand for secure cloud solutions

As more public sector organizations move away from costly legacy systems and migrate their mission-critical workloads to the cloud, cloud-native development and multi-cloud adoption will grow significantly. At GitLab, we serve a wide variety of customers in the public sector – from federally-funded research and development centers, service providers, and contractors working on behalf of the government, to the largest government agencies across the globe. We understand that no single deployment model will serve the needs of all of our customers.

Our customers have told us they need a SaaS offering that provides additional deployment control and data residency to meet stringent compliance requirements. We see this need with large enterprises and companies in regulated industries that are coming under increased scrutiny, facing global internet policy fragmentation, and dealing with the expanding complexity of data governance. GitLab has consistently observed that security is a top priority for organizations and our 2024 Global DevSecOps Survey showed that this trend continued, with security remaining the primary investment area.

GitLab Dedicated for Government was specifically designed to address these needs – enabling organizations to accelerate their digital transformation initiatives with confidence.

Key benefits of GitLab Dedicated for Government

1. Toolchain consolidation

Toolchain management continues to be a significant challenge for DevSecOps teams. According to our 2024 Global DevSecOps Survey, 64% of respondents expressed the need to consolidate their toolchains, with security professionals particularly affected – 63% reported using six or more tools.

This proliferation of tools results in unnecessary expenditure and introduces complexities and vulnerabilities that increase the risk of cyber attacks. GitLab Dedicated for Government unites DevSecOps teams on a single platform with a unified workflow, eliminating the need to purchase or maintain multiple tools. Organizations can strengthen security, improve efficiency, and accelerate collaboration by consolidating their complex toolchains. Additionally, consolidation supports zero trust architecture implementation by centralizing access control, making it easier to enforce consistent security policies and authentication requirements across the entire development lifecycle. GitLab also enables flexibility by allowing you to utilize existing critical tools through our integration capabilities.

2. Data residency and protection

GitLab Dedicated for Government is built on FedRAMP-authorized infrastructure that meets U.S. data sovereignty requirements, including access restricted to U.S. citizens. To further enhance data protection, our solution supports secure, private connections between the customer's virtual private cloud network and GitLab, ensuring users, data, and services have secure access to isolated instances without direct internet exposure. All data is encrypted at rest and in transit using the latest encryption standards, with the option to use your own AWS Key Management Service encryption key for data at rest, giving you full control over stored data. GitLab Dedicated for Government also ensures CVEs are patched continuously. It is an ideal platform for teams to build a centralized DevSecOps platform while offboarding compliance burdens to GitLab.

3. Managed and hosted by GitLab

Our solution is single-tenant (providing physical isolation from other customers), U.S.-based, privately connected, and fully managed and hosted by GitLab. Organizations can quickly realize the value of a comprehensive DevSecOps platform with the advanced flexibility and customization of a self-managed instance – without requiring staff to build and manage infrastructure.

This approach delivers all the benefits of GitLab – shorter cycle times, lower costs, stronger security, and more productive developers – with a lower total cost of ownership and quicker time-to-value compared to self-hosting.

4. Comprehensive native security capabilities

Our 2024 Global DevSecOps Survey revealed that 60% of public sector security professionals report vulnerabilities are mostly discovered after code is merged into test environments, and only 51% consider their DevSecOps practices mature and well-ingrained. GitLab's comprehensive security scanning capabilities, built into the DevSecOps platform, provide superior control and protection throughout the entire software development lifecycle, helping public sector organizations address these issues. These features eliminate the need for third-party security tools that could potentially compromise compliance.

For example, organizations gain access to a complete suite of native security scanners including API Security, Container Scanning, Dynamic Application Security Testing, and Fuzz Testing. This integrated approach ensures federal security standards are met without disrupting development workflows.

With the GitLab DevSecOps unified platform, public sector organizations avoid the painful scenario of discovering security limitations mid-implementation and having to choose between compromising on security features or implementing non-compliant solutions.

How to get started with GitLab Dedicated for Government

GitLab Dedicated for Government provides the efficiencies of the cloud combined with infrastructure-level isolation and data residency controls. To learn more about how GitLab Dedicated for Government can help secure your software supply chain, reach out to our sales team. Whether you are a new customer or looking to migrate from your existing GitLab instance, we will ensure a smooth transition with comprehensive migration support tailored to your needs.

Note: GitLab has also achieved the Texas Risk and Authorization Management Program Certification (TX_RAMP), which allows us to work with Texas state agencies.

AI for every development team

Artificial intelligence is now at the center of the developer experience. AI enhances coding in many ways: It analyzes your codebase and provides real-time suggestions as you type, creates functions and methods based on your project's context, reduces repetitive tasks, and automates code reviews.

Over the past few years, we've built GitLab Duo to infuse generative and agentic AI capabilities like these into our platform. Because writing code is just the start of the software lifecycle – our global DevSecOps study found that developers spend 79% of their time on tasks other than code creation – we have adopted a strategy to integrate AI throughout the entire software development lifecycle.

Now, we’re excited to take the next step forward by including essential GitLab Duo capabilities in our GitLab Premium and Ultimate tiers, enabling developers to get the benefits of AI at no additional cost.

By including GitLab Duo Chat and Duo Code Suggestions in Premium and Ultimate, every software engineer can accelerate their workflow within the IDE — without requiring separate tooling, licensing, or governance. All existing Premium and Ultimate customers now have instant access to Duo Chat and Code Suggestions, once they upgrade to GitLab 18.0, and this enhancement becomes standard for all new customers.

"GitLab has already been instrumental in eliminating our reliance on a fragmented toolchain, which cut costs from disconnected solutions, and streamlined our workflow. Enhancing GitLab Premium with Duo will give us even greater efficiency and cost savings as our developers spend less time on routine coding tasks and more time tackling complex challenges that drive real business value.”

• Andrei Nita, Chief Technology Officer at McKenzie Intelligence Services

<div style="padding:56.25% 0 0 0;position:relative;"><iframe src="https://player.vimeo.com/video/1083723619?badge=0&autopause=0&player_id=0&app_id=58479" frameborder="0" allow="autoplay; fullscreen; picture-in-picture; clipboard-write; encrypted-media" style="position:absolute;top:0;left:0;width:100%;height:100%;" title="GitLab Premium with Duo Core"></iframe></div><script src="https://player.vimeo.com/api/player.js"></script>

<br></br> Premium and Ultimate customers now have these AI-native capabilities:

GitLab Duo Code Suggestions

• Generate complete functions and code blocks from comments
• Get intelligent code completions as you type
• Support for 20+ programming languages
• Available in most popular IDEs

Take this interactive tour to learn about GitLab Duo Code Suggestions (click on the image to start the tour).

<a href="https://gitlab.navattic.com/code-suggestions"><img src="//images.ctfassets.net/r9o86ar0p03f/4nclgZ2JUeQ0hR4wjOS30P/ba948ae1a0dce0cff4469ca06490efb1/Screenshot_2024-08-27_at_9.24.32_AM.png" alt="GitLab Duo Code Suggestions cover image"></a>

Learn more in our Duo Code Suggestions documentation.

GitLab Duo Chat

• Explain unfamiliar code to understand complex functionality
• Refactor existing code to improve quality and maintainability
• Generate comprehensive test cases to help catch bugs earlier
• Fix code issues directly in your workflow

Learn more in our Duo Chat documentation.

"For us, as GitLab users, Duo's intelligent code suggestions have become a daily asset for our developers. Combined with the chat feature, it allows for immediate feedback and iteration, resulting in faster development cycles and a more secure codebase. It's a seamless and powerful addition to our workflows."

• Felix Kortmann, Chief Technology Officer, Ignite by FORVIA HELLA

Duo Enterprise now available to GitLab Premium customers

Due to strong customer demand, we're also excited to share that GitLab Premium customers now can purchase Duo Enterprise, our full suite of AI offerings, without needing to upgrade to GitLab Ultimate. Premium customers can enjoy a rich AI experience seamlessly integrated across the software development lifecycle. This includes exciting GitLab Duo capabilities like:

• Root Cause Analysis helps resolve CI/CD pipeline failures quickly, ensuring your CI/CD pipelines remain green.
• Code Review enables faster merge request reviews by leveraging Duo as a code reviewer.
• Advanced Chat summarizes conversations, helps understand code changes, and provides advanced configuration assistance.
• Self-Hosted enables Duo to be leveraged within air-gapped and offline environments by hosting approved AI models for Duo to use.

In addition to Duo Enterprise availability, we continue to invest in the success of GitLab Premium customers. Since the launch of GitLab 17, we’ve shipped more than a hundred features and improvements, including:

• CI/CD Catalog enables developers to share, discover, and reuse
  pre-existing CI/CD components and configurations.
• Artifact registry gives developers secure access to artifacts and seamless integration with CI/CD pipelines.
• Remote development enables developers to work in on-demand,
  cloud-based development environments.

Learn more about GitLab Premium features.

GitLab Duo: AI that meets organizations where they are

GitLab customers have a comprehensive menu of Duo offerings, across our Pro and Enterprise solutions, to meet you where you are in the AI adoption cycle – the further along your teams are, the more capabilities you can use to build, test, and deploy secure software faster.

How current GitLab Ultimate and Premium customers can get started with Duo

Starting with GitLab 18.0, for existing Ultimate and Premium customers, Duo Code Suggestions and Chat features will be off by default but can easily be enabled – learn how below.

To start experiencing GitLab Premium and Ultimate with Duo:

1. Ensure you're on GitLab Premium or Ultimate. If not, you can start a free, 60-day trial.

2. Enable GitLab Duo in your organization settings.

3. If using a local IDE, install the appropriate GitLab Editor Extension.

4. Start using Code Suggestions and Chat in your preferred supported local IDE or the GitLab Web IDE.

Note: For new customers and trials, GitLab's AI capabilities will be enabled automatically.

AI-native development requires a DevSecOps platform

AI is fundamentally reshaping the developer experience. Organizations won't just have more people building software. They'll have more production-ready code generated by AI – making GitLab more essential than ever.

We built GitLab Premium and Ultimate with Duo specifically for this new reality, giving teams one secure foundation for all their code. As AI generates code across your organization, GitLab becomes your control center: no separate tools for security scanning, compliance checks, or managing pipelines. Just a single, unified platform that scales with your organization and helps ensure all code meets your standards before reaching production. As AI accelerates your development, GitLab enables you to maintain control, security, and quality from end to end.

To learn more about GitLab Duo and all the ways it can transform how your team works, visit our GitLab Premium page or if you are a GitLab customer, reach out to your GitLab representative to schedule a demo. Finally, we invite you to join us on June 24, 2025, for our GitLab 18 virtual launch event to learn about the future of AI-native software development.