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
upcoming releases
if you're interested in seeing what we are doing next.
Preview
Key improvements released in GitLab Preview
Easily choose your preferred AI model right in GitLab Duo Chat, now available in the VS Code and JetBrains IDEs. Use the dropdown list in the GitLab Duo Chat panel to select among Claude, GPT, and other supported models. Model availability is managed by your organization admins, ensuring you have access to the right models for your workflow.
With this release, exact code search is now in limited availability. You can use exact match and regular expression modes to search for code across an entire instance, in a group, or in a project. Exact code search is built on top of the open-source search engine Zoekt.
The GitLab Security Analyst Agent is now a foundational agent in GitLab Duo Agentic Chat. This means that users will no longer need to manually add the GitLab Security Analyst agent from the AI catalog, and this agent will be available by default for GitLab Self-Managed and GitLab Dedicated as well.
This specialized assistant provides AI-native vulnerability management and security analysis, helping you investigate findings, triage vulnerabilities, and navigate compliance requirements without any setup.
This feature is in beta, and we welcome your feedback in issue 576916.
Previously, CI/CD components couldn’t reference their own metadata, such as version numbers
or commit SHAs, within their configuration. This lack of information could cause you to use configuration with
hardcoded values or complex workarounds. Writing configuration this way can
lead to version mismatches when components build resources such as Docker images,
because there’s no way to automatically tag those resources with the component’s compatible version.
In this release, we’ve introduced the ability to access component context with the spec:component keyword.
You can now build and publish versioned resources like Docker images when you release a component version,
ensuring everything is in sync, eliminating manual version management, and preventing version mismatches.
parallel:matrix makes it possible
to easily run multiple jobs in parallel with different requirements, for example
to test code for multiple platforms at the same time. But if you wanted later jobs
to use needs:parallel:matrix to depend on specific parallel jobs, the configuration was complex
and inflexible.
Now, with the new $[[matrix.VARIABLE]] expression introduced as a Beta feature,
users can create dynamic 1-1 dependencies which makes complex parallel:matrix configurations
much easier to manage. This can help you create faster pipelines, with efficient artifact handling,
better scalability, and cleaner configuration. This feature is particularly valuable for multi-platform builds,
Terraform deployments across multiple environments, and any workflow requiring parallel processing across multiple dimensions.
Code ownership is critical for maintaining code quality and ensuring the right
people review changes to sensitive parts of your codebase. However, managing
Code Owners in organizations with complex group structures has been challenging.
Previously, to reference a group in your CODEOWNERS file, that group had to be
directly invited to each specific project, even if it was already a member of
a parent group.
Code Owners now supports groups with inherited memberships as eligible approvers:
Groups with inherited access through parent group membership are recognized
as valid code owners when Code Owners approvals are enabled.
No need to invite groups directly to every project.
Existing CODEOWNERS files continue to work without changes.
Same level of control over who can approve changes to critical code paths.
This change reduces administrative overhead while maintaining the security and
approval requirements that Code Owners provide.
On your homepage, draft merge requests can clutter your merge request view and
distract from work that’s ready for action. Previously, you could not filter them
out.
You can now hide draft merge requests from the Your merge requests section on
your homepage by using the display preferences. When you hide draft merge requests:
They are excluded from the active count.
A footer displays the number of filtered draft merge requests.
Your preference is saved automatically.
This change helps you focus on merge requests that need immediate attention.
Integrating GitLab with external systems through webhooks is critical for automated
workflows and keeping teams informed about merge request status changes. However, when
GitLab automatically resets approvals (such as when new commits are pushed to a merge
request with “Reset approvals on push” enabled), external systems could not distinguish
these system-initiated events from manual user actions.
GitLab now includes enhanced webhook payloads that clearly identify system-initiated approval
resets. When approvals are automatically reset, webhooks now include:
A system field set to true.
A system_action field that provides specific context about why the reset occurred,
such as approvals_reset_on_push or code_owner_approvals_reset_on_push.
This means your webhook integrations can now distinguish between manual approval changes and
automatic system resets, enabling more sophisticated automation workflows that respond
appropriately to the specific context of each approval change.
Organizations can now designate specific users, groups, roles, or custom roles that can bypass merge request approval policies in case critical situations occur. This capability provides flexibility for emergency responses, while maintaining comprehensive audit trails and governance controls.
Emergency bypass with accountability: Designated users can bypass approval requirements during critical incidents, security hotfixes, or urgent production issues. When emergencies strike, authorized personnel can merge or push changes immediately while the system captures detailed justification and audit information for compliance review.
Key capabilities include:
Documented bypass process: When authorized users invoke a policy bypass, they must provide detailed reasoning using an intuitive modal interface, ensuring every exception is properly documented with context.
Comprehensive audit integration: Every bypass generates detailed audit events including user identity, policy context, reasoning, and timestamps for complete visibility into exception usage patterns.
Flexible configuration: Define exception permissions for policies using YAML or UI configuration, supporting individual users, GitLab groups, standard roles, and custom roles.
Git-based push exceptions: Users with pre-approved policy excpetions may push directly when invoking the push bypass option security_policy.bypass_reason.
This feature eliminates the need to entirely disable security policies during emergencies, providing a controlled path for urgent changes while preserving organizational governance and audit requirements.
You can now designate an account beneficiary permission to manage your GitLab account if you are incapacitated or unavailable. To access your account, the beneficiary must provide appropriate legal documentation. This feature helps ensure the continuity of your work and projects while preventing unauthorized access.
We’ve introduced rate limiting for the /api/v4/projects/:id/members/all and /api/v4/groups/:id/members/all endpoints to improve API stability and ensure fair resource usage across all users.
The GET /api/v4/projects/:id/members/all and GET /api/v4/groups/:id/members/all endpoints now have a rate limit of 60 requests per minute per user.
This change helps protect GitLab instances from excessive API usage that could impact performance for all users.
The limit of 60 requests per minute provides ample capacity for normal usage patterns while preventing potential abuse or unintentional resource exhaustion.
If your integrations or scripts use this endpoint, ensure they handle rate limit responses appropriately (HTTP 429) and implement retry logic with backoff as needed.
Most users should not be affected by this change under normal usage patterns.
The GitLab CLI (glab) provides new features and improvements to enhance your
GitLab workflow from the command line:
Enhanced authentication: Auto-detect GitLab URLs from git remotes
during login, making it easier to authenticate against the correct
GitLab instance.
Flexible pipeline monitoring: View any pipeline by ID with the
ci-view command.
GPG key management: Manage GPG keys directly from the CLI with
new commands.
Project member management: Add, remove, and update project members
from the command line.
Improved Git integration: Enhanced git-credential plugin with
support for all token types.
Modern user interface: Updated prompt library for better confirmation
dialogs and consistent GitLab theme across UI components.
For a full list of changes and updatates, see CLI releases.
To get started with the GitLab CLI or update to the latest version,
see the installation guide.
Webhook integrations are critical for automating workflows and keeping
external systems synchronized with GitLab merge request activities.
However, when reviewers were re-requested for merge requests, webhook
consumers had no way to identify which specific reviewer was being
re-requested, making it difficult to trigger appropriate notifications
or automation.
Webhook payloads for merge requests now include a re_requested attribute
in reviewer data that clearly indicates which reviewer was re-requested:
Set to true for the specific reviewer being re-requested.
Set to false for all other reviewers.
This improvement enables more precise automation around the merge request
review process. Webhook consumers can send targeted notifications,
update external tracking systems, and trigger appropriate workflows when
reviews are re-requested.
GitLab’s Helm chart registry previously generated metadata responses on-the-fly, which created performance bottlenecks when repositories contained large numbers of charts. To maintain system stability, we enforced a hard limit of the 1,000 most recent charts. This limit caused frustrating 404 errors when platform teams tried to access older chart versions.
Platform engineers were forced to implement complex workarounds, like splitting charts across multiple repositories, manually managing chart retention policies, or maintaining separate chart storage solutions. These workarounds added operational overhead and fragmented deployment workflows, making it harder to maintain centralized chart governance.
In GitLab 18.7, we’ve eliminated the 1,000 chart limitation by pre-computing metadata responses and storing them in object storage. This architectural change delivers both unlimited chart access and improved performance, as metadata is generated once in background jobs rather than on every request.
Security teams can now apply business context to projects by leveraging security attributes.
Security attributes are organized by categories including business impact (with structured pre-defined selections), application, business unit, internet exposure, and location. Alternatively, you can create your own attribute categories and define labels within those categories.
By applying these attributes across your projects, you can much more quickly search, filter, and identify which projects within the security inventory that require action based on risk posture and organizational context. You may now:
Identify projects that are mission critical and requiring better scan coverage
Review scan coverage by application or business unit
Search and filter based on the attributes applied to your projects
Quickly locate projects that contribute to applications which are publicly accessible/exposed
Advanced search now returns matching results from both issue descriptions and comments. Previously, users had to search issue descriptions and comments separately. This improvement provides a more streamlined and comprehensive search workflow for GitLab issues.
The GitLab MCP server is available in beta. With the GitLab MCP server, you can use AI assistants like Claude Code, Cursor, and other MCP-compatible tools to interact with your GitLab projects, issues, merge requests, and pipelines, all without building custom integrations for each tool.
The GitLab MCP server provides key tools covering issues, merge requests, and pipelines, and we continue to refine it based on user feedback. This feature might have incomplete functionality or bugs. Try it out and share feedback in issue 561564.
