GitLab 18.0 released with GitLab Duo for Premium and Ultimate
Today, we are excited to announce the release of GitLab 18.0 with GitLab Premium and Ultimate with Duo, Automatic reviews with Duo Code Review, Improved Duo Code Review context, Repository X-Ray now available on Gitlab Duo Self-Hosted and much more!
These are just a few highlights from the 30+ improvements in this release. Read on to check out all of the great updates below.
To the wider GitLab community, thank you for the 328 contributions you provided to GitLab 18.0!
At GitLab, everyone can contribute and we couldn't have done it without you!
Come see what we’ve added in GitLab 18 to help you get the benefits of AI across the entire software delivery lifecycle and strengthen security without slowing developers down — all in one natively integrated DevSecOps platform. Register for the GitLab 18 virtual release event: The next step in intelligent DevSecOps.
Michael Hofer champions GitLab’s open source mission as both a top contributor and community leader.
With over 50 contributions this year,
his work strengthened GitLab’s Geo features and Secrets Manager, based on OpenBao.
He topped the April Hackathon while supporting fellow contributors and leading community projects.
“I truly appreciate that everyone can contribute to GitLab!” says Michael.
“The team is great to work with, it’s a lot of fun, and everyone is super helpful, especially when we team up across open source initiatives like OpenBao and SLSA.”
Michael is the CTO at Adfinis, an international IT service provider specializing in planning, building, and running mission critical open source workloads.
He is passionate about fostering collaboration and promoting open source solutions across organizations.
Recently, Adfinis participated in GitLab’s Co-Create program, which pairs organizations with GitLab’s product and engineering teams
to build GitLab together.
“We highly recommend Co-Create to all organizations,” Michael says. “It led to a number of cool contributions, including rootless Podman builds, Glimmer syntax highlighting, and other improvements.”
“The Geo Team really appreciates and enjoys working with Michael,” says Lucie Zhao, Engineering Manager at GitLab, who nominated Michael for the award.
“With his excellent contributions over the last few milestones, he has become the most well-known community contributor within our team.”
GitLab team members Lee Tickett, Chloe Fons, and Alex Scheel supported the nomination.
Alex adds, “Michael’s leadership in OpenBao has enabled us to effectively collaborate in bringing forward a secrets management solution for our customers, with the transparency that aligns with our GitLab values.”
Thanks to Michael and the Adfinis team for co-creating GitLab!
You can now use Repository X-Ray with Code Suggestions on GitLab Duo Self-Hosted. This feature is in beta for GitLab Duo Self-Hosted, and is generally available on GitLab Self-Managed instances.
Duo Code Review provides valuable insights during the review process, but currently requires you to manually request reviews on each merge request.
You can now configure GitLab Duo Code Review to run automatically on merge requests by updating your project’s merge request settings. When enabled, Duo Code Review automatically reviews merge requests unless:
The merge request is marked as draft.
The merge request contains no changes.
Automatic reviews ensure that all code in your project receives a review, consistently improving code quality across your codebase.
Code Suggestions now includes prompt caching. Prompt caching significantly improves code completion latency by avoiding the re-processing of cached prompt and input data. The cached data is never logged to any persistent storage, and you can optionally disable prompt caching in the GitLab Duo settings.
In GitLab 18.0, when you delete a top-level group, placeholder users associated with the group are deleted as well. If placeholder users are associated with other projects, they are only removed from the top-level group.
This way, unnecessary placeholder users are removed without disrupting the history or attributions of other projects.
The GitLab for Slack app now supports multiple workspaces for GitLab Self-Managed and GitLab Dedicated customers. Enabling multiple workspaces allows organizations with federated Slack environments to maintain seamless GitLab integrations across all their workspaces. To enable support for multiple workspaces, configure the GitLab for Slack app as an unlisted distributed app.
GitLab provides templates for popular static site generators. We’ve taken a deep dive into available templates using a scoring framework, and refined the list to include only the most popular templates.
Refining templates available for GitLab Pages streamlines the website creation process. Use templates to launch professional-looking sites with minimal technical expertise. Enhanced templates also provide modern, responsive designs, eliminating the need for custom development work.
You can now create GitLab workspaces in a shared Kubernetes namespace. This removes the need to create
a new namespace for every workspace and eliminates the requirement to give elevated ClusterRole
permission to the agent. With this feature, you can more easily adopt workspaces in secure or
restricted environments, offering a simpler path to scale.
To enable shared namespaces, set the shared_namespace field in your agent configuration file to
specify the Kubernetes namespace you want to use for all workspaces.
Thank you to the half dozen community contributors who helped build this feature through
GitLab’s Co-Create program!
We’re also releasing GitLab Runner 18.0 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.
You can use the dashboard for Kubernetes to monitor your deployed applications. Until now, pods with container errors like CrashLoopBackOff or ImagePullBackOff were displayed with a “Pending” or “Running” status, which makes it difficult to identify problematic deployments without using kubectl.
In GitLab 18.0, error states in the UI show a specific container’s status, similar to the kubectl output. Now, you can quickly identify and troubleshoot failing pods without leaving the GitLab interface.
In Stable templates, scan jobs ran in branch pipelines only. MR pipelines weren’t supported.
In Latest templates, scan jobs ran in MR pipelines when an MR was open, and ran in branch pipelines if there was no associated MR. You couldn’t control this behavior.
Now, a new option, AST_ENABLE_MR_PIPELINES, allows you to control whether to run jobs in MR pipelines.
The default behavior for both Stable and Latest templates remains the same. Specifically:
Stable templates continue to run scan jobs in branch pipelines by default, but you can set AST_ENABLE_MR_PIPELINES: "true" to use MR pipelines instead when an MR is open.
Latest templates continue to run scan jobs in MR pipelines by default when an MR is open, but you can set AST_ENABLE_MR_PIPELINES: "false" to use branch pipelines instead.
This improvement affects all security scanning templates except for API Discovery (API-Discovery.gitlab-ci.yml), which currently defaults to MR pipelines.
We also changed the API Discovery template to align with other Stable templates in GitLab 18.0 and use branch pipeline by default.
Previously, when a resolved vulnerability was redetected and changed status, the vulnerability details did not provide information to indicate when and why the status change occurred.
GitLab now adds a system note to the vulnerability history when resolved vulnerabilities change status because they appeared in a new scan. This additional information helps users understand why vulnerabilities have changed status.
In the compliance projects report, you can view the compliance frameworks applied to projects within a group or
subgroup.
However, the report lacked the ability to show whether a project is archived or not, which could be useful
information for managing compliance across active and archived projects.
As such, we’ve added an indicator to show whether a project is archived. This will provide you with better
visibility and context when reviewing compliance frameworks across both active and archived projects.
This feature includes:
An archived status badge for each project in the compliance projects report to show whether a project is
archived.
A filter that allows you to toggle between archived, non-archived, or all projects.
LDAP users can now authenticate requests with their GitLab username. Previously, if the GitLab username didn’t match their LDAP username, GitLab returned an authentication error. This change helps users maintain separate naming conventions in GitLab and LDAP systems without disrupting approval workflows.
You can create custom roles with the Manage protected environments permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Owner or Maintainer role.
Delayed project deletion is now available for projects in user namespaces (personal projects). Previously, this safeguard against accidental data loss was only available for group namespaces. When you delete a project in your user namespace, it will now enter a “pending deletion” state for the duration configured in your instance settings (7 days on GitLab.com), rather than being immediately deleted. This creates a recovery window during which you can restore the project if needed.
We hope this enhancement provides greater peace of mind when managing your personal projects in GitLab.
Breaking change: Support for PostgreSQL 14 and 15 has been removed. Make sure you are running PostgreSQL 16 before upgrading.
Breaking change: The bundled Prometheus chart was updated from 15.3 to 27.11. Along with the Prometheus chart upgrade, the Prometheus version was updated from 2.38 to 3.0. Manual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter, or Pushgateway enabled, you must also update your Helm values. For more information, see the migration guide.
Breaking change: The default NGINX controller image was updated from version 1.3.1 to 1.11.2. If you’re using the GitLab NGINX chart, and you have set your own NGINX RBAC rules, new RBAC rules must exist. For more information, see the upgrade guide for more information.
GitLab Dedicated customers with strict security requirements and compliance obligations require the highest level of protection for their development environments.
Today, we’re introducing Internal Releases, a new private release that allows us to remediate GitLab Dedicated instances for critical vulnerabilities before public disclosure, ensuring GitLab Dedicated customers are never exposed to them.
This new capability delivers immediate protection for critical vulnerabilities found in GitLab parallel to response for GitLab.com. This new process does not require customer action.
We’ve added a new active parameter to our Groups and Projects REST APIs that simplifies filtering groups based on their status. When set to true, only non-archived groups or projects not marked for deletion are returned. When set to false, only archived groups or projects marked for deletion are returned. If the parameter is undefined, no filtering is applied. This enhancement helps you efficiently manage your workflows by targeting specific statuses through simple API calls.
Thank you @dagaranupam for adding this parameter to the Projects API.
In this release we’ve improved the placeholder users mapping experience by
narrowing down the user selection dropdown to only Enterprise users
associated with the top-level group.
Previously, when reassigning users’ contributions after an import to GitLab.com, you would see in the dropdown list
all active users on the platform, making it difficult to identify the correct user, especially when SCIM provisioning
had modified usernames. Now, if your top-level group uses the Enterprise users feature, the dropdown list will display only
users claimed by your organization, significantly reducing the potential for errors during user reassignment.
The same scoping is also applied to CSV-based reassignment, preventing accidental assignment to users outside your organization.
You can now create a workspace directly from a merge request with the new Open in Workspace option. This feature automatically configures a workspace with the merge request’s branch and context, allowing you to:
Review code changes in a fully configured environment.
Run tests on the merge request branch to verify functionality.
Make additional modifications to the merge request without local setup.
Previously, when working on code files, you had no visibility into who else might be modifying
the same file in other branches. This lack of awareness led to merge conflicts, duplicated work,
and inefficient collaboration.
Now you can easily identify all open merge requests that modify the file you’re viewing in the
repository. This feature helps you:
Identify potential merge conflicts before they happen.
Avoid duplicating work that’s already in progress.
Improve collaboration by providing visibility into in-flight changes.
A badge displays the number of open merge requests modifying the file, and hovering over it
reveals a popover with the list of these merge requests.
The redesigned CI/CD analytics view transforms how your development teams analyze, monitor, and optimize pipeline performance
and reliability. Developers can access intuitive visualizations in the GitLab UI that reveal performance
trends and reliability metrics. Embedding these insights in your project repository eliminates context-switching
that disrupts developer flow. Teams can identify and address pipeline bottlenecks that drain productivity.
This enhancement leads to faster development cycles, improved collaboration, and data-driven confidence to optimize your
CI/CD workflows in GitLab.
In GitLab 18.0, we are enabling event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption. For detailed instructions on how to adjust data sharing settings, please refer to our documentation.
With this release you can now bulk add vulnerabilities to new or existing GitLab issues from the vulnerability report. You may now associate multiple issues and vulnerabilities together. Additionally, related vulnerabilities are now listed within the issue page.
In merge request approval policies, this new enhancement to license approval policies gives legal and compliance teams more control over which packages can use specific licenses. You can now create exceptions for pre-approved packages, even when they use licenses that would normally be blocked by your organization’s policies.
Previously, in license approval policies, if you blocked a license like AGPL-3.0, it was blocked for all packages across your organization. This created challenges when:
Your legal team pre-approved specific packages with otherwise restricted licenses.
You needed to use the same package across hundreds of projects.
Different teams required different license exceptions.
With this release, you can maintain strict license governance while allowing necessary exceptions, significantly reducing approval bottlenecks and manual reviews. For example, you can:
Define package-specific exceptions to your license approval rules using Package URL (PURL) format.
Allow specific packages (or package versions) to use otherwise restricted licenses.
Block specific packages (or package versions) from using generally allowed licenses.
To add exceptions, follow this workflow when you create or edit a license approval policy:
In your group, go to Security & Compliance > Policies
Create or edit a license approval policy.
Find the new package exception options in the visual editor or configure them in YAML mode.
Choose between allowlist or denylist mode for the licenses.
Add specific licenses to your policy.
For each license, define package exceptions in PURL format (for example, pkg:npm/@angular/[email protected]).
Specify whether to include or exclude these packages from the license rule.
The policy then enforces your license rules while respecting the defined exceptions, giving you granular control over license compliance across your organization.
You can now remove the ability to invite members to groups or projects.
On GitLab.com, this setting is configured by Owners of groups with enterprise users and applies to any sub-groups or projects within the top-level group. No user can send invites while this setting is enabled.
On GitLab Self-Managed, this setting is by administrators and applies to the entire instance. Administrators can still invite users directly.
This feature helps organizations maintain strict control over membership access.
Pipeline security just got more flexible. Job tokens are ephemeral credentials that provide access to resources in pipelines. Until now, these tokens inherited full permissions from the user, often resulting in unnecessarily broad access capabilities.
With our new fine-grained permissions for job tokens beta feature, you can now precisely control which specific resources a job token can access within a project. This allows you to implement the principle of least privilege in your CI/CD workflows, granting only the minimal access necessary for each job to complete its tasks.
We’re actively seeking community feedback on this feature. If you have questions, want to share your implementation experience, or would like to engage directly with our team about potential improvements, please visit our feedback issue.
Administrators can now choose if the maximum length of a user session is computed from the initial sign-in or from the last activity. Users are notified that the session is ending, but cannot prevent the session from expiring or extend the session. This feature is disabled by default.
GitLab now automatically detects and supports both SHA1 and SHA256 certificate fingerprints for Group SAML authentication. This maintains backward compatibility with existing SHA1 fingerprints while adding support for more secure SHA256 fingerprints. This upgrade is essential to prepare for the upcoming ruby-saml 2.x release that will make SHA256 the default.
Project and group delayed deletion is now available for all GitLab users, including those on our Free tier. This essential safety feature adds a grace period (7 days on GitLab.com) before deleted groups and projects are permanently removed. This feature allows recovery from accidental deletions without complex recovery operations.
By making data safety a core feature, GitLab can help better protect your work against data loss events.
We have added API rate limits for projects, groups, and users to improve platform stability and performance for all users. These changes are in response to increased API traffic that has been affecting our services.
The limits have been carefully set based on average usage patterns and should provide sufficient capacity for most use cases. If you exceed these limits, you’ll receive a “429 Too Many Requests” response.
For complete details about specific rate limits and implementation information, please read the related blog post.
When this experiment is turned on, trigger pipeline execution policies on a regular schedule with customized CI/CD jobs and scripts. You can enforce compliance scripts, GitLab or third-party security scans, or other custom CI/CD jobs in scheduled pipelines. Scheduled pipeline enforcement is another tool to ensure your security and compliance requirements are met by running jobs on a daily, weekly, or monthly schedule. Scheduled pipelines do not inject or enforce jobs in the project’s .gitlab-ci.yml file, impacting downstream project pipelines. Instead, you can use these pipelines to perform actions such as regularly targeting the default branch to check dependencies, project configurations, or other requirements.
To enable the experiment, create a policy.yml file or modify the existing policy.yml file in your security policy project and add the experiments attribute. Once enabled, you can configure a pipeline execution policy with a schedule that runs custom CI/CD jobs on all projects where the pipeline execution policy is enforced.
You can create multiple triggered pipeline execution policies, but you can configure only one scheduled pipeline execution policy per security policy project.
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 18.0.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback