GitLab 18.10 release notes

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.

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.

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 also 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 network_policy section of agent-config.yml. The agent-config.yml is protected by branch protection rules and MR approval workflows.

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.

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.

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.

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.

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.

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.

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".

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 and 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 fall back 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 in this feedback issue.

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.

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.

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 using 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.

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.

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.

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.

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.

What’s New:

• Allow k8s runner to define Pod Level Resources for build pod
• Add automation to update Go versions and packages for all Runner projects

Bug Fixes:

• S3 cache with RoleARN returns 403 instead of 404 for non-existent cache
• Using helper image gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2 results in init-permissions error
• MacOS: LaunchAgent - Service could not initialize on M1 architecture

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