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
We’re thrilled to announce the beta release of the GitLab Eclipse plugin, now available in the Eclipse Marketplace. This powerful new plugin extends GitLab’s Duo features directly into your Eclipse IDE, giving you seamless access to Duo Chat and AI-powered code suggestions.
As the plugin is currently in beta, we’re actively improving features, including expanding authentication options, and refining the final user experience. Your feedback is invaluable. Please share your thoughts to help us make the GitLab Eclipse plugin even better by adding your feedback in issue 162.
You can now use more GitLab Duo features with Gitlab Duo Self-Hosted in your GitLab Self-Managed instance. The following features are available in beta:
Previously, compliance frameworks in GitLab could be created as a label to identify that your project has certain
compliance requirements or needs additional oversight. This label could then be used as a scoping mechanism to
ensure that security policies could be enforced on all projects within a group.
In this release, we are introducing a new way for compliance managers to get more in-depth compliance monitoring
in GitLab through ‘requirements’.
With requirements, as part of a custom compliance framework, you can define specific requirements from a number of
different compliance standards, laws, and regulations that must be followed as an organization.
We are also expanding the number of compliance controls (previously known as compliance checks) that we offer from
five to over 50! These 50 out-of-the-box (OOTB) controls can be mapped to the compliance framework requirements.
These controls check particular project, security, and merge request settings across your GitLab instance to help
you meet requirements under a number of different compliance standards, laws, and regulations such as SOC2, NIST,
ISO 27001, and the GitLab CIS Benchmark.
Adherence to these controls are reflected in standard adherence report, which is redesigned to take into account
requirements and the mapping of controls to those requirements.
In addition to expanding our OOTB controls, we now allow users to map requirements to external controls, which can
be for items, programs, or systems that exist outside the GitLab platform. These mappings allow you to use the
GitLab compliance centre as the single source of truth when it comes to your compliance monitoring and audit
evidence needs.
We’re thrilled to announce the launch of the extension marketplace in the Web IDE for self-managed users. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience.
By default, the GitLab instance is configured to use the Open VSX extension registry. To activate this, follow the enable with default extension registry steps.
If you want to use your own or custom registry, you also have the option to connect a custom extension registry. This provides you with more flexibility to manage available extensions.
After enabling the extension marketplace, individual users must still opt in to use it. They can do this by going to the Integrations section in their Preferences settings.
It’s important to note that some extensions require a local runtime environment and are not compatible with the web-only version. Despite this, you can still choose from thousands of available extensions to boost your productivity and customize your workflow.
Container registries are critical infrastructure for modern DevSecOps teams. Until now, GitLab users with the Developer role or higher could push and delete any container tag in their projects, creating risks of accidental or unauthorized changes to production-critical container images.
With protected container tags, you now have fine-grained control over who can push or delete specific container tags. You can:
Create up to five protection rules per project.
Use RE2 regex patterns to protect tags like latest, semantic versions (for example, v1.0.0), or stable release tags (for example, main-stable).
Restrict push and delete operations to Maintainer, Owner, or Administrator roles.
Prevent protected tags from being removed by cleanup policies.
This feature requires the next-generation container registry, which is already enabled by default on GitLab.com. For GitLab Self-Managed instance, you’ll need to enable the metadata database to use protected container tags.
We’re thrilled to introduce support for protected Maven packages to enhance the security and stability of your GitLab package registry. Accidental modification of packages can disrupt the entire development process. With protected packages, you can safeguard your most important dependencies against unintended changes.
In GitLab 17.11, you can now protect Maven packages by creating protection rules. If a package matches a protection rule, only specified users can push new versions of the package. Package protection rules prevent accidental overwrites, improve compliance with regulatory requirements, and reduce the need for manual oversight.
Protected packages support for Maven and other package formats are all community contributions from gerardo-navarro and the Siemens crew. Thank you, Gerardo, and the rest of the crew from Siemens for their many contributions to GitLab! If you want to learn more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.
With this release, you can configure text, number, single-select,
and multi-select custom fields for issues, epics, tasks, objectives, and key
results. While labels have been the primary way to categorize work items up
to this point, custom fields provide a more user-friendly approach for adding
structured metadata to your planning artifacts.
Custom fields are configured in your top-level group and cascade to all subgroups and projects.
You can map fields to one or more work item types and filter by custom field values in the issues and epics lists.
As of this release, the new issue look is generally available and replaces the legacy issue experience. Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:
Drawer view: You can open items from lists or boards in a drawer for quick viewing without leaving your current context. A button at the top lets you expand to a full-page view.
Change type: Convert types between epics, issues, and tasks using the “Change type” action (replaces “Promote to epic”)
Start date: Issues now support start dates, aligning their functionality with epics and tasks.
Ancestry: The complete hierarchy is above the title and the Parent field in the sidebar. To manage relationships, use the new quick action commands /set_parent, /remove_parent, /add_child, and /remove_child.
Controls: All actions are now accessible from the top menu (vertical ellipsis), which remains visible in the sticky header when scrolling.
Development: All development items (merge requests, branches, and feature flags) related to an issue or task are now consolidated in a single, convenient list.
Layout: UI improvements create a more seamless experience between issues, epics, tasks, and merge requests, helping you navigate your workflow more efficiently.
Linked items: Create relationships between tasks, issues, and epics with improved linking options. Drag and drop to change link types and toggle the visibility of labels and closed items.
You can now automatically assign a Duo Pro or Duo Enterprise seat to users with SAML Group Sync. As long as the GitLab group has available Duo Pro or Duo Enterprise seats, any user mapped from the identity provider is automatically assigned a seat. This reduces the effort to manage seat assignments.
With this release, webhooks that return 4xx errors are now automatically re-enabled. All errors (4xx, 5xx, or server errors) are treated the same way, allowing for more predictable behavior and easier troubleshooting. This change was announced in this blog post.
Failing webhooks are temporarily disabled for one minute, extending to a maximum of 24 hours. After a webhook fails 40 consecutive times, it now becomes permanently disabled.
Webhooks that were permanently disabled in GitLab 17.10 and earlier underwent a data migration.
For GitLab.com, these changes apply automatically.
For GitLab Self-Managed and GitLab Dedicated, these changes affect only those instances where the auto_disabling_webhooksops flag is enabled.
Previously, ghost user contributions would create placeholder references that required manual reassignment, creating extra work during migrations.
Now, importers using new contributions and membership mapping functionality, migration by direct transfer, GitHub, Bitbucket Serber and Gitea importers,
handle ghost user contributions more intelligently.
When importing content to GitLab, contributions previously made by the ghost user on
the source instance are now automatically mapped to the ghost user on the destination instance.
This enhancement eliminates the creation of unnecessary placeholder users for ghost user contributions,
reducing clutter in user mapping interface and simplifying the migration process.
In this milestone, we’ve added SAML verification checks to contribution reassignment when importing to GitLab.com. These checks prevent reassignment errors in groups where SAML SSO is enabled.
If you import to GitLab.com and use SAML SSO for GitLab.com groups, all users must link their SAML identity to their GitLab.com account before you can reassign contributions and memberships.
When you reassign contributions to users who have not verified their SAML identity, you’ll receive error messages. These messages explain the steps to take to help ensure your group memberships are attributed correctly.
The custom wiki sidebar now features improved styling with reduced heading sizes and better left-padding for lists. These ergonomic enhancements improve the readability of custom navigation created through the _sidebar wiki page.
Custom sidebars help teams organize their wiki content in a way that makes sense for their unique knowledge base structure. With this styling update, the sidebar is now easier to scan, creating a clearer visual hierarchy that helps team members find relevant information more quickly.
You can now set work in progress limits by weight in addition to issue count, giving you more flexibility in managing your team’s workload.
Control the flow of work based on the complexity or effort of each task, rather than just the number of issues. Teams that use issue weights to represent effort can now ensure they don’t overcommit by limiting the total weight of issues in a given board list.
Use this feature to optimize your team’s productivity and create a more balanced workflow that accounts for varying task complexity.
CI/CD jobs can occasionally get stuck in the ‘canceling’ state, blocking deployments or access to shared resources.
Users with the Maintainer role can now force-cancel these stuck jobs directly from the job logs page, ensuring problematic jobs can be properly terminated.
You can now manage runners more efficiently in your projects. Runners are displayed in a single-column layout and organized in their own lists instead of the previous two-column view.
This improved organization makes it simpler to find and manage runners, with new features including a list of assigned projects, runner managers, and jobs that a runner has run. For information about additional runner management improvements planned for GitLab 18.0, see issue 33803.
This release adds full support for Kubernetes version 1.32, released in December 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.
The Dynamic Analysis team has introduced a check for CWE-79. This work allows our DAST scanner to check for reflected XSS attacks.
Checking for Reflective XSS is on by default. To turn off this check, in you configuration, set DAST_FF_XSS_ATTACK: false.
If you have questions or feedback, see issue 525861.
The Composition Analysis team has released beta support for static reachability for Python. This beta release focuses on enhancing stability, observability, and provides a better user experience via easier configuration.
Static reachability enriches software composition analysis (SCA) results. Powered by GitLab Advanced SAST, static reachability scans project source code to identify which open source dependencies are in use.
You can use the data produced by static reachability as part of your triage and remediation decision making. Static reachability data can also be used with CVSS and EPSS scores, as well as KEV indicators to provide a more focused view of your vulnerabilities.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team please see this feedback issue.
Previously, when exporting the dependency list or the vulnerability report, you had to remain on the page until the export completed before you could download the report.
Now, you are notified by email with a download link when the dependency list or vulnerability report export is complete.
GitLab 17.11 introduces a new feature that allows users to verify the origin of build artifacts by tracking the source attribute of CI/CD jobs. This enhancement is particularly valuable for security and compliance workflows. For example, organizations can implement software supply chain security measures or require verifiable evidence of security scans for compliance purposes.
Jobs in GitLab now store and display a source value that identifies whether they originated from:
A scan execution policy
A pipeline execution policy
A regular pipeline
You can access the source attribute on the Build > Jobs page with a new filter option, using the Jobs API, or through the ID token claims for artifact verification.
With this new feature, you can now:
Verify the authenticity of security scan results.
Filter jobs by source type to quickly identify policy-enforced scans.
Implement cryptographic verification of artifacts using the new ID token claims.
Ensure compliance requirements are met with proper audit trails.
Security and compliance teams can leverage this feature to:
View only policy-enforced jobs using the new filter on the Jobs page.
Automate tasks by accessing the source field in the Jobs API.
Implement artifact verification using the new ID token claims:
job_source: Identifies the job’s origin.
job_policy_ref_uri: Points to the policy file (for policy-defined jobs).
job_policy_ref_sha: Contains the git commit SHA of the policy.
In the past, you couldn’t assign new compliance frameworks to projects without navigating to the Projects tab
in the compliance center after creating the compliance framework. This situation created unnecessary friction to
creating new compliance frameworks in your groups.
In GitLab 17.11, when creating a compliance framework, we introduced a new step that provides the option of
assigning multiple projects to the compliance framework before it is created.
This new feature:
Helps keep you in the compliance framework creation workflow.
Provides guidance for you to understand that compliance frameworks work together with projects in a group to
monitor and enforce compliance adherence for the entire group.
GitLab Duo Chat now uses Anthropic Claude Sonnet 3.7 as the base model, replacing Claude 3.5 Sonnet for answering most questions.
Claude 3.7 Sonnet has strongly improved coding and reasoning capabilities, making it even better at explaining code, generating code, processing text data, and answering complex DevSecOps questions. You’ll notice more detailed and accurate Chat responses in these areas.
This upgrade applies to all Chat features, and ensures a consistent and improved experience across the entire Chat interface.
Multiple conversations with GitLab Duo Chat is now available in GitLab Self-Managed instances in the web UI. You can create new conversations, browse your conversation history, and switch between conversations without losing context.
For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time. On GitLab Self-Managed, administrators can reduce how long conversations are retained for.
On GitLab Duo Self-Hosted, you can now select and configure individual supported models for each GitLab Duo feature and sub-feature on your GitLab Self-Managed instance.
Previously, placeholder users created during imports appeared mixed with regular users
without clear distinction in the Admin area Users page.
With this release, administrators can now filter for placeholder accounts from the search box
in the Users page in the Admin area. To do this, select Type in the dropdown list,
then choose Placeholder.
For imports to GitLab.com, placeholder users are limited per top-level group. These limits depend on your GitLab license and number of seats. With this release, it’s possible to check your placeholder user usage and limits for a top-level group in the UI.
To view your current usage and limits:
On the left sidebar, select Search or go to and find your group. This group must be at the top level.
GLQL views now support displaying the last comment on an issue or merge request as a column. By including lastComment as a field in your GLQL query, you can see the most recent updates without leaving your current context.
Previously, you had to open each issue or merge request individually to view the last comment, which was time consuming and made it difficult to get a quick overview of progress. This improvement helps teams maintain momentum by providing at-a-glance visibility into ongoing conversations and status updates.
We welcome your feedback on this enhancement and GLQL views in general on our feedback issue.
GitLab provides templates for the most popular Static Site Generators (SSGs), and you can now create a GitLab Pages site using Nuxt, a powerful framework built on Vue.js. Nuxt is particularly valuable for teams looking to build modern, performant web applications with less configuration overhead.
This addition expands your options for quickly launching a Pages site with built-in CI/CD pipelines and a modern development experience, without spending time on initial setup and configuration.
GitLab Duo Code Suggestions can now use imported files in your IDE to enrich and improve the quality of suggestions. Imported files provide additional context about your project. Imported file context is supported for JavaScript and TypeScript files.
You can now quickly identify failed jobs in the pipeline graph with new visual indicators. Failed job groups are highlighted in the pipeline graph, and failed jobs are grouped at the top of each stage. This improved visualization helps you troubleshoot pipeline failures without having to search through complex pipeline structures.
We’re excited to announce UI support for Docker Hub authentication in the GitLab Dependency Proxy. This feature was initially introduced in GitLab 17.10 with GraphQL API support only, and now includes a user interface for easier configuration.
With this enhancement, you can now configure Docker Hub authentication directly from your group settings page, helping you:
In GitLab 18.0, we plan to enable 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.
Starting in GitLab 17.11, you will have the ability to opt out of event data collection before it starts, effectively allowing you to choose participation in advance. For more information and details on how to opt-out please see our documentation.
GitLab secret detection has received significant updates, including 17 new secret push protection rules and 12 new pipeline secret detection rules. Some existing rules have also been updated to improve quality and reduce false positives. For details, see v0.9.0 in the change log.
Many organizations now require a software bill of materials (SBOM) to meet regulatory requirements and help further increase the security of the software supply chain. Previously, you could only export your dependency list as a JSON or CSV file from GitLab. Now, GitLab can produce your SBOM by exporting your dependency list in the CycloneDX format that has become the adopted SBOM standard.
To download an SBOM directly as a CycloneDX file, in the dependency list, select Export > Export as CycloneDX (JSON).
Previously, you could not export a dependency list from GitLab as CSV file. Now, when you download a dependency list, you can select the new CSV option to export the list in in this format.
Previously, the Tool search filter in the vulnerability report allowed you to filter results based on a single group of tools that included the type of scanner (like ESLint or Gemnasium) and the type of report (like SAST or container scanning).
To help you find the appropriate tools more easily, we’ve replaced the Tool filter with the Scanner filter and the Report Type filter. You can now filter your search based on each of these types of tools separately.
There are now additional sorting options for access tokens in the UI and API. These sorting options complement GitLab’s existing token management capabilities, giving you more control over your access token inventory and helping you better maintain access token security. The new sorting options include:
- Sort by expiration date (ascending): View the tokens that expire soonest
- Sort by expiration date (descending): View the tokens with the longest remaining lifetime
- Sort by last used date (ascending): View the tokens that have not been used recently
- Sort by last used date (descending): View the tokens used most recently
