GitLab 18.11 release notes

We’ve made an update to improve your Agentic Chat experience in GitLab. The default model for Agentic Chat was upgraded from Claude Haiku 4.5 to Claude Sonnet 4.6, hosted on Vertex AI. Claude Sonnet 4.6 offers improved reasoning and response quality but uses a higher GitLab Credit multiplier than Haiku 4.5.

You can select an alternative model, including Haiku, using the model selection setting. If you’ve already selected a specific model, your choice is preserved. This update only affects the default and will not override any existing selections. For information about credit multipliers by model, see the GitLab Credits documentation.

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.

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.

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.

You can now perform incremental scans that analyze only changed parts of the codebase with GitLab Advanced SAST, significantly reducing scan times compared to full repository scans. This feature is a further iteration of diff-based scanning, because it produces full results for codebases.

By scanning just the code that has changed rather than the entire codebase, your teams can integrate security testing more seamlessly into their development workflow without sacrificing speed or adding friction.

Advanced SAST can now surface unverified vulnerabilities (findings that cannot be fully traced from source to sink) directly in the vulnerability report. Enable this feature if you have a higher tolerance for false positives over false negatives.

This feature is in beta status. Provide feedback in issue 596512.

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.

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.

Epics now support weights, making it easier to estimate and prioritize large-scale initiatives during planning.

Before breaking down an epic into child issues, you can assign a preliminary weight to represent your initial estimate. As you decompose the epic, the weight automatically updates to reflect the rolled-up total from all child issues. This is consistent with how weight rollup works for issues and tasks.

On the epic detail page, you can see both the preliminary weight and the rolled-up weight from child issues, giving you the insight needed to refine estimates over time.

Previously, merge request (MR) approval policies could block MRs based on vulnerability severity, but not all vulnerabilities carry the same risk. CVSS severity alone doesn’t tell you whether a CVE is being exploited or how likely exploitation is. This leads to noisy approval policies and wasted time for developers and security teams.

You can now configure MR approval policies using Known Exploited Vulnerability (KEV) and Exploit Prediction Scoring System (EPSS) data. Block or require approval when a finding is in the KEV catalog (actively exploited in the wild), or when its EPSS score is above a threshold. Policy violations in the MR include KEV and EPSS context so developers understand why the security gate was triggered.

This gives security teams precise control over which findings block or warn, reduces alert fatigue, and keeps enforcement aligned with the current threat landscape.

Previously, you had to select the row description to navigate to a vulnerability details page from the vulnerability report.

You can now select anywhere in the row to go directly to its details. Link styling for the vulnerability description and file location only appears when you hover over each link, and keyboard navigation has been improved.

These changes make the vulnerability report more intuitive and accessible.

In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile. In GitLab 18.11, profiles now extend to SAST with the Static Application Security Testing (SAST) - Default profile, giving you a unified control surface to apply standardized static analysis coverage across all your projects without touching a single CI/CD configuration file.

The profile activates two scan triggers:

• Merge Request Pipelines: Automatically runs a SAST scan each time new commits are pushed to a branch with an open merge request. Results only include new vulnerabilities introduced by the merge request.
• Branch Pipelines (default only): Runs automatically when changes are merged or pushed to the default branch, providing a complete view of your default branch’s SAST posture.

You can now filter the results in a group security dashboard based on the security attributes that you have applied to the projects in that group.

The available security attributes include the following:

• Business impact
• Application
• Business unit
• Internet exposure
• Location

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.

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_ID not 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.