New features are regularly released to GitLab SaaS (GitLab.com), with a packaged release available for GitLab Self-Managed every month. Read on to learn more about the new features available on GitLab.com. Note that it may take a few days for a feature to become fully available on GitLab.com, due to deployment schedule and potential
feature flags.
Additional information on
past
releases is available; be sure to check out the
release for other features we've launched recently. We also have information about
what's new
if you're interested in seeing what we are doing next.
Preview
Key improvements released in GitLab Preview
You can now connect custom agents in the AI Catalog to external data sources and tools through the Model Context Protocol (MCP) without leaving GitLab.
This feature is an experiment. Share your feedback in issue 593219.
Maintaining consistent merge request titles is important for teams that rely on structured
naming conventions. Whether that’s following the Conventional Commits format,
or linking to an internal tracking system. Teams previously needed external tooling or
custom CI/CD pipeline jobs to enforce these conventions, but this approach had a
critical gap. If someone changed the merge request title after the pipeline ran, there was no
re-validation, and the MR could still be merged with a non-compliant title.
You can now configure a required title regex for merge requests in your project settings.
When configured, GitLab evaluates the merge request title against the pattern as a
mergeability check — blocking the merge until the title is updated to comply, regardless
of when the title was last changed.
To set this up, go to your project’s Settings > Merge requests and enter a regex
pattern in the Merge request title must match regex field.
Your existing merge request workflows continue to work as before — this check only
applies to projects where you explicitly configure a title regex.
Free tier users on GitLab.com can now unlock the full power of GitLab Duo Agent Platform — no Premium or Ultimate subscription required. Choose your monthly credit amount, commit to an annual term, and get instant access to AI-powered development tools. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.
Key highlights:
Usage-based pricing: Purchase a monthly credit commitment without needing a base plan subscription.
Self-service purchasing: Buy credits through the GitLab purchase flow.
Seamless upgrade path: Your credit commitment transfers if you later upgrade to Premium or Ultimate.
Consumption tracking: Monitor your credit usage through the GitLab Credits dashboard.
This purchase option is currently only available for free GitLab.com top-level groups.
The GitLab planning experience is getting a significant upgrade with the work items list and saved views,
bringing together two long-requested capabilities:
The work items list combines epics, issues, and other work items into a single unified list,
eliminating the need to switch between separate pages for different work item types.
This makes it easier to understand relationships across your planning objects.
Saved views allow you to create and save customized list configurations, including filters,
sort order, and display options. This makes routine checks more efficient, and supports standardized
ways of viewing work across your team.
This is the next step in the GitLab work items journey, a unified architecture designed to deliver
consistency and unlock new capabilities across GitLab planning tools.
SAST false positive detection, which was first introduced as a beta in GitLab 18.7, is now generally available in GitLab 18.10.
When a security scan runs, Duo Agent Platform analyzes each critical and high severity SAST vulnerability and determines the likelihood that it’s a false positive.
The assessment appears directly in the vulnerability report, giving teams the context they need to triage with confidence rather than uncertainty.
Key capabilities include:
Automatic analysis: False positive detection runs automatically after each security scan with no manual intervention required.
Manual option: Users can manually run false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
Focus on high-impact findings: Limiting the analysis to critical and high severity SAST vulnerabilities cuts through the noise where it matters most.
Contextual AI reasoning: Each assessment explains why a finding may or may not be a false positive, factoring in code context, data flow, and vulnerability characteristics specific to static analysis.
Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information — no changes to existing workflows required.
This feature is available for Ultimate customers with Duo Agent Platform. The feature must be enabled in your group or project settings.
We welcome your feedback in issue 583697.
Security teams spend significant time investigating secret detection findings that turn out to be false positives, for example, test credentials, example values, and dummy tokens that are incorrectly flagged as actual secrets.
False positives creates alert fatigue, erodes trust in scan results, and diverts attention from genuine security risks.
GitLab 18.10 introduces AI-powered secret false positive detection (beta) to focus on the secrets that actually matter.
When a security scan runs, GitLab Duo automatically analyzes each Critical and High severity secret detection vulnerability to determine if it’s a false positive.
The AI assessment appears directly in the vulnerability report, giving security engineers immediate context to make faster and confident triage decisions.
Key capabilities include:
Automatic analysis: False positive detection runs automatically after each security scan without manual trigger.
Manual trigger option: You can manually trigger false positive detection for individual vulnerabilities on the vulnerability details page for on-demand analysis.
Focus on high-impact findings: Scoped for Critical and High severity vulnerabilities to maximize signal-to-noise improvement.
Contextual AI reasoning: Each assessment includes an explanation of why the finding may or may not be a true positive, based on code context and vulnerability characteristics.
Confidence scoring: Each detection includes a confidence score to helps teams to prioritize review based on the model’s certainty.
Seamless workflow integration: Results surface directly in the vulnerability report alongside existing severity, status, and remediation information.
This feature is available as a free beta for Ultimate customers and must be enabled in your group or project settings.
Share feedback in issue 592861.
GitLab now supports passkeys for passwordless sign-in and as a phishing-resistant two-factor authentication (2FA) method. Passkeys use public-key cryptography and biometric authentication (fingerprint, face recognition) or your device PIN to securely access your account.
Passkeys offer the following benefits:
Passwordless convenience: Sign in with your device’s biometrics or PIN instead of remembering a password.
Multi-device support: Use passkeys on desktop browsers, mobile devices (iOS 16+, Android 9+), and FIDO2/WebAuthn-compatible hardware security keys.
Phishing-resistant security: Your private key never leaves your device. GitLab only stores the public key, protecting your account even if GitLab servers are compromised.
Automatic 2FA integration: For accounts with 2FA enabled, passkeys become available as your default 2FA method.
To get started, add a passkey in your account settings. We welcome your questions, feedback in issue 366758.
Using CI/CD variables for dynamic job configuration can be challenging. Variables follow a complex override hierarchy that’s difficult to manage, and they can’t be used for a variety of use cases.
Now you can use inputs to define explicit, typed inputs at the job level. Use job inputs to define and control values a job accepts at runtime. With job inputs, you get:
Type safety (string, number, boolean, array)
Default values that can be static or reference existing variables.
The option to define a strict list of possible values to use.
Regex support for validating input values.
Job inputs can use the default values without any user interaction, but you can modify the values when retrying a job or running a manual job.
You can now use task item checkbox syntax directly in Markdown table cells. Previously, achieving this required a combination of raw HTML and Markdown, which was
cumbersome and difficult to maintain. This improvement makes it easier to track task completion directly within structured table layouts in issues, epics, and other content.
You can now create, test, and deploy applications for the newest
generations of Apple devices using macOS Tahoe 26 and Xcode 26.
With hosted runners on macOS,
your development teams can build and deploy macOS applications faster in a secure,
on-demand build environment integrated with GitLab CI/CD.
Try it out today by using the macos-26-xcode-26 image in your .gitlab-ci.yml file.
Teams using Helm to manage Kubernetes application deployments can now rely on the GitLab Helm Chart registry for production workloads. Previously in beta, the registry is now generally available following the resolution of key architectural and reliability concerns.
The path to GA included resolving a hard limit that prevented the index.yaml endpoint from returning more than 1,000 charts, fixing a background indexing bug that caused newly published chart versions to be missing from the index, completing a full AppSec security review, and adding Geo replication support for Helm metadata cache, ensuring high availability for self-managed customers running GitLab Geo.
Platform and DevOps teams can publish and install Helm charts directly from GitLab using standard Helm client workflows, with support for project-level endpoints and authentication via personal access tokens, deploy tokens, and CI/CD job tokens. Now you can keep charts alongside the source code, pipelines, and security scanning that depend on them.
GitLab dependency scanning by using SBOM now supports scanning Java build.gradle and build.gradle.kts build files.
Previously, dependency scanning for Java projects using Gradle required a lock file to be present.
Now, when a lock file is not available, the analyzer automatically falls back to scanning build.gradle and build.gradle.kts files, extracting and reporting only direct dependencies for vulnerability analysis.
This improvement makes it easier for Java projects using Gradle to enable dependency scanning without requiring a lock file.
To enable manifest fallback, set the DS_ENABLE_MANIFEST_FALLBACK CI/CD variable to “true”.
GitLab now supports license scanning for Dart and Flutter projects that use the pub package manager.
Previously, teams building with Dart or Flutter were unable to identify the licenses of their open source dependencies directly within GitLab, creating compliance blind spots for organizations with license policy requirements.
License data is sourced directly from pub.dev, the official Dart package repository, and results are surfaced alongside other supported ecosystems.
Dart/Flutter dependency scanning and vulnerability detection were already supported.
In GitLab 18.9, we introduced security configuration profiles with the Secret Detection - Default profile, starting with push protection. You use the profile to apply standardized secret scanning across hundreds of projects without touching a single CI/CD configuration file.
The Secret Detection - Default profile now also covers pipeline-based scanning, providing a unified control surface for secret detection across your entire development workflow.
The profile activates three scan triggers:
Push Protection: Scans all Git push events and blocks pushes where secrets are detected, preventing secrets from ever entering your codebase.
Merge Request Pipelines: Automatically runs a 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 secret detection posture.
Applying the profile requires no YAML configuration. The profile can be applied to a group to propagate coverage across all projects in the group, or to individual projects for more granular control.
Automatic reviews in Code Review Flow are now turned on by default for new GitLab Duo trial customers, so you can start getting AI-powered feedback on your merge requests from day one without any manual setup. With a new flat pricing model, you get immediate value from smarter, faster code reviews right out of the box. If needed, you can opt out in your group settings.
The GitLab Credits dashboard now links credit consumption directly to the GitLab Duo Agent Platform session that generated it. In the per-user drill-down view, the Action column for Agent Platform usage rows (such as Agentic Chat or Foundational Agents) is now a clickable hyperlink that navigates to the corresponding session details. This link provides a direct audit trail from billing to AI session behavior, so administrators can investigate credit usage, support escalations, and compliance reviews without manually correlating timestamps across separate systems.
You can now configure network access controls for flows using GitLab runners in projects. This provides secure external integrations, while maintaining control over network destinations. This gives project maintainers the flexibility to allow necessary API connections, MCP servers, and third-party services while enforcing security boundaries.
Configure network access controls in the agent-config.yml, in the network_policy section. The agent-config.yml is protected by branch protection rules and MR approval workflows.
You can now manage your CI/CD pipelines in a GitLab project with the new manage_pipeline tool.
This GitLab MCP server tool lets AI agents create, cancel, retry, delete, and update pipeline metadata in a single call.
With this tool, you no longer have to piece together multiple steps to automate your pipeline workflows.
If you want to see other GitLab MCP sever tools, let us know in the feedback issue.
Previously, enabling AI agents and flows from the AI Catalog required top-level group permissions. Now, when browsing the AI Catalog at the explore level or project level, project Maintainers can enable agents and flows directly in their projects.
GitLab Duo Agent Platform now supports the Agent Skills specification,
an emerging standard for giving AI agents new capabilities and expertise.
You can define Agent Skills at the workspace level for your project
to give agents specialized knowledge and workflows for specific tasks, like writing
tests in a specific framework. Agents automatically discover and load relevant skills
as they encounter matching tasks.
You can also trigger skills manually by name, file path, or custom slash commands.
Agent Skills are accessible for flows and Agentic Chat in your IDE, and for
flows run in CI/CD pipelines. They also work with any other AI tool that supports
the specification.
We’re also releasing GitLab Runner 18.10 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.
C and C++ development teams using Conan as their package manager have long requested registry support in GitLab. Previously, the Conan package registry was experimental and only supported Conan 1.x clients, limiting adoption for teams that have migrated to the modern Conan 2.0 toolchain.
The Conan package registry now supports Conan 2.0 and has been promoted from Experimental to Beta. This release includes full v2 API compatibility, recipe revision support, improved search capabilities, and proper handling of upload policies including the --force flag. Teams can publish and install Conan 2.0 packages directly from GitLab using standard Conan client workflows, reducing the need for external artifact management solutions like JFrog Artifactory.
With this update, platform engineering teams managing C and C++ dependencies can consolidate their package management within GitLab alongside their source code, CI/CD pipelines, and security scanning. The Conan registry supports both project-level and instance-level endpoints, and works with personal access tokens, deploy tokens, and CI/CD job tokens for authentication.
We welcome feedback as we work toward general availability. Please share your experience in the epic.
When the container virtual registry launched in beta last milestone, platform engineers could aggregate multiple upstream container registries — Docker Hub, Harbor, Quay, and others — behind a single pull endpoint. However, all configuration required direct API calls, meaning teams had to maintain scripts or manual curl commands to create and manage their registries, configure upstreams, and handle changes over time. This added operational overhead and made the feature inaccessible to users who weren’t comfortable working directly with the API.
Container virtual registries can now be created and managed directly from the GitLab UI. From the group-level container registry page, you can create new virtual registries, configure upstream sources with authentication credentials, edit existing configurations, and delete registries you no longer need — all without leaving GitLab or writing a single API call. The UI integrates seamlessly with the existing container registry experience, making virtual registries a first-class part of your group’s artifact management workflow.
This feature is in beta. To share feedback, please comment in the feedback issue.
In GitLab 18.10, we’re extending limited availability status to self-managed instances for the new SBOM-based dependency scanning feature.
This feature was initially released in GitLab 18.5 with limited availability for GitLab.com only, behind the feature flag dependency_scanning_sbom_scan_api disabled by default.
With additional improvements and fixes, we now have confidence to reliably use the new SBOM scanning internal API and enable this feature flag by default.
This internal API allows the dependency scanning analyzer to generate a dependency scanning report containing all component vulnerabilities.
Unlike the previous behavior (Beta) that processed SBOM reports after CI/CD pipeline completion, this improved process generates scan results immediately during the CI/CD job, giving users instant access to vulnerability data for custom workflows.
Self-managed customers who encounter issues can disable the dependency_scanning_sbom_scan_api feature flag. The analyzer will then fallback to the previous behavior.
To use this feature, import the v2 dependency scanning template Jobs/Dependency-Scanning.v2.gitlab-ci.yml.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, please reach out via this feedback issue.
Manage and visualize security scanner coverage across your organization. This release introduces security configuration profiles, starting with the secret detection profile.
Security teams now have a more powerful command center to secure your organization at scale.
Profile-based security configuration
Instead of manually editing YAML files for each project, you can now use preconfigured security configuration profiles that provide several advantages:
Standardized governance: Preconfigured profiles apply appropriate boundaries without interrupting productivity. You can apply standardized security best practices, without requiring custom role configurations.
Scalable management: Apply the same profile across hundreds or thousands of projects with a single action.
The secret detection profile is the first security configuration profile available. It provides the following advantages:
Actively identifies and blocks secrets from being committed to your repositories.
One profile manages secret detection across your entire development workflow. No need to manage separate configurations for different trigger types.
Enhanced security inventory
The security inventory has been upgraded to act as your primary dashboard to assess each group’s security posture:
Group and project hierarchies: Easily distinguish between subgroups and projects in the inventory with clear iconography.
Bulk actions: A new Bulk Action menu allows you to apply or disable security scanner profiles across all selected projects and subgroups simultaneously.
Visual coverage status: Quickly identify gaps with color-coded status bars (Enabled, Not Enabled, or Failed) with tooltips for details.
Profile status indicators: See which trigger types are available in the profile details.
Security attributes allow security teams to apply business context to their projects, including business impact, application, business unit, internet exposure, and location. You can also create custom attribute categories to match your organization’s taxonomy. By applying these attributes, you can filter and prioritize the items in your security inventory based on risk posture and organizational context.
Billing managers can now download credit usage data as a CSV file directly from the GitLab Credits dashboard in Customers Portal. The export provides a daily, per-action breakdown of credit consumption for the current billing month, including commitment, waiver, trial, on-demand, and included credits used. Finance and operations teams can use this data to perform cost allocation, chargeback reporting, and usage analysis in Excel, Google Sheets, or BI tools without manual data gathering or support requests.
Enterprise administrators can now sort the Usage by User table in the GitLab Credits dashboard by total credits used or by username. The default sort order is by total credits consumed (highest first), so the top consumers are immediately visible without scrolling. With this view, administrators managing thousands of GitLab Duo users can quickly identify high-usage individuals for cost allocation, chargeback reporting, and license utilization audits.
The gitlab_blob_search tool now enables GitLab AI agents to search your code:
Across all projects in a group.
Across all accessible projects on an instance.
Previously, blob search was limited to a single project, or required specifying explicit project IDs. This change makes it easier for AI-powered workflows to discover and reuse code that’s spread across multiple related projects.
We’ve streamlined the projects page in Explore to reduce clutter and remove redundant options that accumulated over time.
The simplified interface now focuses on two core views:
Active tab: Discover projects with recent activity and ongoing development.
Inactive tab: Access archived projects and those scheduled for deletion.
We’ve removed several redundant tabs:
Most starred projects can be found by sorting Active or Inactive tabs by star count.
All projects are available by viewing both Active and Inactive tabs.
Trending tab will be fully removed in GitLab 19.0 due to limited functionality and low usage.
The cleaner design aligns with other project lists for visual consistency. You can still access all the same content through more logical organization and flexible sorting options.
Vertex AI is now a supported LLM platform within GitLab Duo Agent Platform Self-Hosted. Customers can now configure Anthropic models hosted on Vertex AI for use with GitLab Duo Agent Platform features.
Maintainers and Owners can now enable agents and flows directly from their project or the explore page, without navigating away from their current context. Top-level group Owners can also select their group, and the specific projects where they want to activate agents and flows, streamlining their workflow setup.
You can now enforce custom policies on CI/CD jobs before runner assignment with runner controllers.
The runner controller connects to the job router and makes admit or reject decisions based on custom rules.
Use runner controllers for admission control, compliance enforcement, or cost and resource governance.
Controllers support instance runners and a dry-run mode for safe validation before enforcement.
