gitlab-org/gitlab-foss v18.11.0

on GitLab

The Data Analyst Agent is a specialized AI chat assistant that helps you query, visualize, and surface data across the GitLab platform.

Backed by the GitLab Query Language (GLQL), the Data Analyst can retrieve and analyze data about each of the supported data sources, and provide clear, actionable insights about your software development health and engineering efficiency.

These insights can be visualized directly in the agent output and embedded directly into issues and epics for further evaluation.

You can now deploy Gitaly on Kubernetes as a fully supported deployment method. This gives you greater flexibility in managing your GitLab infrastructure by using Kubernetes orchestration capabilities for scaling, high availability, and resource management. Previously, Kubernetes deployments required custom configurations and weren't officially supported, making it difficult to maintain reliable Gitaly clusters in containerized environments.

You can now configure tool options and parameter values directly in your custom flow definitions to supersede the LLM default values. This gives you more precise, consistent control over how tools behave within a custom flow, making it easier to enforce guardrails and specific parameter values across that flow.

For GitLab Self-Managed instances, we now have improved recommendations and configuration guidance for the GitLab ClickHouse integration. Customers have options to bring their own cluster, or use the ClickHouse Cloud (recommended) setup option. This integration powers multiple dashboards and unlocks access to various API endpoints within the analytics space.

This scalable, high-performance database is part of the larger architectural improvements planned for the GitLab analytics infrastructure.

The GitLab Query Language (GLQL) now has access to three new data sources: projects, pipelines, and jobs. These new data sources are also available as embedded views, letting teams surface pipeline results, job statuses, and project overviews directly in wikis, issue and merge request descriptions, and repository Markdown files.
GLQL also powers the Data Analyst Agent. With these new types, the agent can inspect CI/CD job results, debug failures, and provide detailed overviews of pipeline execution, as well as provide an accurate overview of projects in a namespace.

GitLab now fully supports Kubernetes version 1.35. If you want to deploy your applications to Kubernetes
and access all features, upgrade your connected clusters to the most recent version.
For more information, see supported Kubernetes versions for GitLab features.

In GitLab 19.0, the minimum-supported version of PostgreSQL will be version 17. To prepare for this change, on instances that don't use PostgreSQL Cluster, upgrades to GitLab 18.11 will attempt to automatically upgrade PostgreSQL to version 17.

If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 17 to be able to upgrade to GitLab 19.0.

The GitLab backup Rake task for Linux package installations and the backup-utility for Cloud Native (Helm) installations now support the container registry metadata database. You can now back up references to blobs, manifests, tags, and other data stored in the metadata database, enabling recovery in the event of malicious or accidental data corruption.

We're excited to announce improvements to the groups list in Explore, making it easier to discover groups across your GitLab instance.
The redesigned interface introduces a tabbed layout with two views:

• Active tab: Browse all accessible groups, helping you discover relevant communities and projects.
  
• Inactive tab: View archived groups and groups pending deletion for visibility into group lifecycle status.
  

These changes streamline group discovery and provide clearer visibility into which groups are available to join.

In previous versions of GitLab, transfers of large groups and projects could timeout. As we move groups and projects to use a unified state model for operations such as transfer, archive, and deletion, you get more consistent behavior, better visibility into state history and audit details, and fewer timeouts, specifically, for long running transfer operations through asynchronous processing.

The wiki sidebar toggle is now positioned on the left side, directly next to the sidebar
it controls.

When the sidebar is collapsed, the toggle remains visible as a floating
control so you can reopen it without scrolling back to the top of the page.

The action bar on wiki pages is now sticky, so it remains visible as you scroll
through a page. Previously, you had to scroll back to the top to access actions
like editing, viewing page history, or managing templates. Now the page title
and key actions, including Edit, New page, Templates, Page history, and more,
stay within reach no matter how far down the page you are.

The AI-powered CI Expert Agent is now available in beta. This agent helps teams get from GitLab code to a first working pipeline without starting from a blank .gitlab-ci.yml.

Using GitLab Duo Agent Platform, the agent inspects your repository, asks a few guided questions about your build and test process, and generates a ready-to-run pipeline you can review, edit, and commit.

This turns pipeline creation into a conversational, context-aware experience, while still letting you take full control of the YAML after you're ready to evolve and optimize your configuration.

A powerful aspect of CI/CD inputs is that you can manually run new pipelines with new values for runtime customization.
This was not available in merge request (MR) pipelines before, but in this release you can now customize inputs in MR pipelines too.

After you configure inputs for MR pipelines, you can optionally modify those inputs and change the pipeline behavior any time you run a new pipeline for a merge request.

We're also releasing GitLab Runner 18.11 today! GitLab Runner is the highly-scalable build agent that runs your CI/CD jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What's New:

• Create concrete helper image with bundled dependencies
  
• Read the job router feature flag from the runner configuration instead of an environment variable
  

Bug Fixes:

• Incorrect runner binary path after refactoring
  
• Pipeline hangs on cache operations
  
• The docker-machine binary in GitLab Runner 18.9.0 references CVE-2025-68121
  
• Runner silently falls back to job payload credentials when credential helper binary is missing from DOCKER_AUTH_CONFIG
  
• CONCURRENT_PROJECT_IDnot unique in different jobs, which causes a conflict in the builds directory
  
• Artifact upload fails with timeout awaiting response headers
  
• User-defined after_script executes after failed pre_build_script and bypasses post_build_script
  

The list of all changes is in the GitLab Runner CHANGELOG.

You can now set the container registry metadata database to prefer mode, a new configuration option alongside the existing true and false values. In prefer mode, the registry automatically detects whether it should use the metadata database or fall back to legacy storage based on the current state of your installation.

If your registry has existing filesystem metadata that has not been imported to the database, the registry continues to use legacy storage until you complete a metadata import. If the database is already in use, or on a fresh installation, the registry uses the database directly.

In a later release, prefer mode will become the default for new Linux package installations. Existing installations will not be affected. For more information, see issue 595480.

Teams publishing Terraform modules through the built-in GitLab Terraform module registry had
no way to restrict who could push new module versions. Package protection rules supported
several package formats but did not include terraform_module, leaving infrastructure
teams without a project-level push control.

You can now create package protection rules scoped to terraform_module, restricting push
access based on minimum role. Support is available in the UI package type dropdown, the
REST API, the GraphQL API, and the GitLab Terraform provider resource.

When creating a GitLab Release, packages published to the package registry were not
automatically associated with it. Teams had to manually construct package URLs and attach
them as release links through the API or pipeline scripts, adding friction and risk of
incomplete release records.

GitLab now automatically includes packages in release evidence when the package version
matches the release tag. This creates a verifiable, auditable link between your release and
its associated packages without any manual steps, keeping source code, artifacts, and
packages together in one complete release snapshot.

Teams can now create service accounts in subgroups and projects. Instead of broad, top-level group bots, you can attach a dedicated service account to a single subgroup or project and manage its access like any other member of that namespace. Group and subgroup service accounts can be invited to the group where they were created or to any descendant subgroups and projects. Project service accounts are limited to their own project.

Service accounts are now available on GitLab.com in all tiers. Previously limited to
Premium and Ultimate, service accounts let you perform automated actions, access data, or run
scheduled processes without tying credentials to individual team members. They're commonly used in
pipelines and third-party integrations where credentials must stay stable regardless of team
changes. On GitLab Free, you can create up to 100 service accounts per top-level group, including those
created in subgroups or projects.

Fine-grained personal access tokens (PATs) are now available in beta. Unlike legacy PATs, which grant access to every project and group you belong to, fine-grained PATs let you limit each token to specific resources and actions. This reduces the potential impact of a leaked or compromised token.

Your existing PATs continue to work as before, and you can still create legacy PATs without fine-grained permissions.

This beta release covers approximately 75% of the GitLab REST API. Full REST API coverage, GraphQL enforcement, and administrator policy controls are planned for the GA release.

To share feedback, see epic 18555.

The Security Manager role is now available as a beta feature, providing a new default set of permissions designed specifically for security professionals. Security teams no longer need Developer or Maintainer roles to access security features, eliminating over-privileging concerns while maintaining separation of duties.

Users with the Security Manager role have the following access:

• Vulnerability management: View, triage, and manage vulnerabilities across groups and projects, including vulnerability reports and security dashboards.
  
• Security inventory: View a group's security inventory to understand scanner coverage across all projects.
  
• Security configuration profiles: View security configuration profiles for a group.
  
• Compliance tools: View audit events, compliance center, compliance frameworks, and dependency lists for a group or project.
  
• Secret push protection: Enable secret push protection for a group.
  
• On-demand DAST: Create and run on-demand DAST scans for a group.
  

To get started, go to a group and select Manage > Members to invite and assign members to the Security Manager role.