Feb 18, 2025
Available now on GitLab

The latest features available on GitLab SaaS

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

Add project files to Duo Chat in VS Code and JetBrains IDEs

Add project files to Duo Chat in VS Code and JetBrains IDEs

Add your project files directly to Duo Chat in VS Code and JetBrains to unlock more powerful, context-aware AI assistance.

By adding project files, Duo Chat gains deep understanding of your specific codebase, enabling it to provide highly contextual and accurate responses. This context awareness gives you more relevant code explanations, precise debugging help, and suggestions that seamlessly integrate with your existing codebase. We welcome your feedback on this new, exciting feature. Please share your thoughts in our feedback issue.

Workspaces container support with Sysbox

Workspaces container support with Sysbox

GitLab workspaces now supports building and running containers directly in your development environment. When your workspace runs on a Kubernetes cluster configured with Sysbox, you can build and run containers without additional configuration.

Introduced in GitLab 17.4 as part of our sudo access feature, this capability enables you to maintain your complete container workflow in your GitLab workspace environment.

Create workspaces without a custom devfile

Create workspaces without a custom devfile

Previously, setting up a workspace required creating a devfile.yaml configuration file. GitLab now provides you with a default file that includes common development tools. This enhancement:

  • Removes configuration barriers.
  • Enables you to create a workspace quickly from any project.
  • Includes common development tools pre-configured and ready to use.
  • Lets you focus on development instead of configuration.

Start developing and create a workspace immediately without additional setup or configuration steps.

Create workspaces without a custom devfile

Simplified access to deployments within project environments

Simplified access to deployments within project environments

Have you ever struggled to get an overview of your deployments within a project? You can now view recent deployment details in the environments list without having to expand each environment. For each environment, the list shows your latest successful deployment and, if different, your most recent deployment attempt.

Simplified access to deployments within project environments

Run multiple Pages sites with parallel deployments

Run multiple Pages sites with parallel deployments

You can now create multiple versions of your GitLab Pages sites simultaneously with parallel deployments. Each deployment gets a unique URL based on your configured prefix. For example, with a unique domain your site would be accessible at project-123456.gitlab.io/prefix, or without a unique domain at namespace.gitlab.io/project/prefix.

This feature is especially helpful when you need to:

  • Preview design changes or content updates.
  • Test site changes in development.
  • Review changes from merge requests.
  • Maintain multiple site versions (for example, with localized content).

Parallel deployments expire after 24 hours by default to help manage storage space, though you can customize this duration or set deployments to never expire. For automatic cleanup, parallel deployments created from merge requests are deleted when the merge request is merged or closed.

Run multiple Pages sites with parallel deployments

Enhancing workflow visibility: new insights into merge request review time

Enhancing workflow visibility: new insights into merge request review time

To improve development workflow tracking, Value Stream Analytics (VSA) has been extended with a new event - Merge request last approved at. The merge request approval event marks the end of the review phase and the start of the final pipeline run or merge stage. For example, to calculate the total merge request review time, you can create a VSA stage with Merge request reviewer first assigned as the start event and Merge request last approved at as the end event.

With this enhancement, teams gain deeper insights into opportunities to optimize review times, which help reduce the overall cycle time of development, leading to faster software delivery.

Enhancing workflow visibility: new insights into merge request review time

EPSS, KEV, and CVSS data for vulnerability risk prioritization

EPSS, KEV, and CVSS data for vulnerability risk prioritization

We’ve added support for the following vulnerability risk data:

  • Exploit Prediction Scoring System (EPSS)
  • Known Exploited Vulnerabilities (KEV)
  • Common Vulnerabilities and Exposures (CVE)

You can now efficiently prioritize risk across your dependency and container image vulnerabilities using this data. You can find the data in the Vulnerability Report and in the Vulnerability Details page.

EPSS, KEV, and CVSS data for vulnerability risk prioritization

Automated Duo Pro and Duo Enterprise seat assignment

Automated Duo Pro and Duo Enterprise seat assignment

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.

Automated Duo Pro and Duo Enterprise seat assignment

Configure DAST scans through the UI with full control

Configure DAST scans through the UI with full control

To effectively test complex applications, security teams need flexibility when they configure DAST scans. Previously, DAST scans configured through the UI had limited configuration options, which prevented successful scanning of applications with specific security requirements. This meant you had to use pipeline-based scans even for quick security assessments.

You can now configure DAST scans through the UI with the same granular control available in pipeline-based scans. This includes:

  • Full authentication configuration, including custom headers and cookies
  • Precise crawl settings like maximum pages, maximum depth, and excluded URLs
  • Advanced scan timeouts and retry attempts
  • Custom scanner behavior, like maximum links to crawl and DOM depth
  • Targeted scanning modes for specific vulnerability types

Save these configurations as reusable profiles to maintain consistent security testing across your applications. Every configuration change is tracked with audit events, so you know when scan settings are added, edited, or removed.

This enhanced control helps you run more effective security scans while maintaining compliance using detailed audit trails. Instead of spending time managing pipeline configurations, you can quickly launch the right scan for each application to find and fix vulnerabilities faster.

Configure DAST scans through the UI with full control

Automatic CI/CD pipeline cleanup

Automatic CI/CD pipeline cleanup

In the past, if you wanted to delete older CI/CD pipelines, you could only do this through the API.

In GitLab 17.9, we have introduced a project setting that allows you to set a CI/CD pipeline expiry time. Any pipelines and related artifacts older than the defined retention period are deleted. This can help reduce the disk usage in projects that run lots of pipelines that generate large artifacts, and even improve overall performance.

Automatic CI/CD pipeline cleanup

Preview Other improvements in GitLab Preview

Manage project integrations from a group with the REST API

Manage project integrations from a group with the REST API

Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it’s possible to manage these integrations with the REST API too.

Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.

Control access to GitLab Pages for groups

Control access to GitLab Pages for groups

You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.

Work items GraphQL API - additional query filters

Work items GraphQL API - additional query filters

The Work Items GraphQL API now includes additional query filters that let you filter by:

  • Created, updated, closed, and due dates
  • Health status
  • Weight

These new filters give you more control when querying and organizing work items through the API.

Discover and migrate certificate-based Kubernetes clusters

Discover and migrate certificate-based Kubernetes clusters

The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2024 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).

To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.

We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.

GitLab-managed Kubernetes resources

GitLab-managed Kubernetes resources

Deploy your applications to Kubernetes with more control and automation using GitLab-managed Kubernetes resources. Previously, you had to manually configure Kubernetes resources for each environment. Now, you can use GitLab-managed Kubernetes resources to automatically provision and manage these resources.

With GitLab-managed Kubernetes resources, you can:

  • Automatically create namespaces and service accounts for new environments
  • Manage access permissions through role bindings
  • Configure other required Kubernetes resources

When your developers deploy applications, GitLab automatically creates the necessary Kubernetes resources based on the provided resource templates, streamlining your deployment process and maintaining consistency across environments.

GitLab-managed Kubernetes resources

Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects

Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects

In GitLab 17.9 the Composition Analysis team starts the transition to Dependency Scanning using SBOM with the new Dependency Scanning analyzer. This analyzer will be a replacement for Gemnasium, which will reach end of support in 18.0, remaining available for use through GitLab 19.0.

The Dependency Scanning using SBOM approach will better support customers through expansion of language support, a tighter integration and experience within the GitLab platform, and a shift towards industry standard report types (SBOM-based scanning and reporting). As of GitLab 17.9, the new Dependency Scanning analyzer will be enabled by default in the latest Dependency Scanning CI/CD template (Dependency-Scanning.latest.gitlab-ci.yml) for the following project and file types: * C/C++/Fortran/Go/Python/R projects using conda with a conda-lock.yml file. * Objective-C projects using Cocoapods with a podfile.lock file. * Rust projects using Cargo with a cargo.lock file. * Swift projects using Swift with a package.resolved file.

With this change we are introducing a new CI/CD variable: DS_ENFORCE_NEW_ANALYZER which is set to false by default.

This approach ensures that all existing customers of the latest template continue to use the Gemnasium analyzer by default and it enables automatically the new Dependency Scanning analyzer for the file types listed above.

Existing customers who wish to migrate to the new Dependency Scanning analyzer can set DS_ENFORCE_NEW_ANALYZER to true (at the project, group, or instance level). You can read more about this change in the deprecation announcement and the associated migration guide.

Customers who want to entirely prevent the use of the new Dependency Scanning analyzer must set the CI/CD variable DS_EXCLUDED_ANALYZERS to dependency-scanning.

Block deletion of active security policy projects

Block deletion of active security policy projects

To ensure secure management of security policies and prevent disruption to enabled and enforced policies, we’ve added protection to prevent deletion of security policy projects that are in active use.

If a security policy project is linked to any groups or projects, the links must be removed before the security policy project can be deleted.

Enforce custom stages in pipeline execution policies

Enforce custom stages in pipeline execution policies

We’re excited to introduce a new capability for pipeline execution policies that allows you to enforce custom stages into your CI/CD pipelines in Inject mode. This feature provides greater flexibility and control over your pipeline structure while maintaining security and compliance requirements, supplying you with:

  • Enhanced pipeline customization: Define and inject custom stages at specific points in your pipeline, allowing for more granular control over job execution order.
  • Improved security and compliance: Ensure that security scans and compliance checks run at the most appropriate times in your pipeline, such as after build but before deployment.
  • Flexible policy management: Maintain centralized policy control while allowing development teams to customize their pipelines within defined guardrails.
  • Seamless integration: Custom stages work alongside existing project stages and other policy types, providing a non-disruptive way to enhance your CI/CD workflows.

How does it work?

The new and improved inject_policy strategy for pipeline execution policies allows you to define custom stages in your policy configuration. These stages are then intelligently merged with your project’s existing stages using a Directed Acyclic Graph (DAG) algorithm, ensuring proper ordering and preventing conflicts.

For example, you can now easily inject a custom security scanning stage between your build and deploy stages.

The inject_policy stage replaces inject_ci which will be deprecated, allowing you to opt into the inject_policy mode to gain the benefits. The inject_policy mode will become the default when configuring policies with Inject in the policy editor.

Enforce custom stages in pipeline execution policies

Support custom roles in merge request approval policies

Support custom roles in merge request approval policies

We’ve made merge request approval policies more flexible by adding the ability to assign custom roles as approvers.

You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals.

Support custom roles in merge request approval policies

Apply a compliance framework by using a project’s compliance center

Apply a compliance framework by using a project’s compliance center

In GitLab 17.2, we released the ability for group owners to apply and remove compliance frameworks for all projects in a group by using the group’s compliance center.

We have expanded this to now allow group owners to also apply and remove compliance frameworks at the project level. This will make it even easier for group owners to apply and monitor compliance frameworks at the project level.

The ability to apply and remove compliance frameworks at the project level is only available for group owners and not project owners.

Email notifications for service accounts

Email notifications for service accounts

You can now set a custom email address to receive email notifications for service accounts. When a custom email address is specified when creating a service account, GitLab sends notifications to that address. Each service account must use a unique email address. This can help you monitor processes and events more effectively.

Thank you Gilles Dehaudt, Étienne Girondel, Kevin Caborderie, Geoffrey McQuat, Raphaël Bihore from the SNCF Connect & Tech team for your contribution!

OAuth application authorization audit event

OAuth application authorization audit event

Previously, when a user authorized a OAuth application, no audit event was generated. However, this event is important for security teams to monitor the OAuth applications authorized by users on a specific GitLab instances.

With this release, GitLab now provides a User authorized an OAuth application audit event to track when users successfully authorize OAuth applications. This new audit event further improves your ability to audit your GitLab instance.

Search and filter the Credentials Inventory

Search and filter the Credentials Inventory

You can now use search and filter capabilities in the Credentials Inventory. This makes it easier to identify tokens and keys which fall within certain user-defined parameters, including tokens that expire within a certain window. Previously, the entries in the Credentials Inventory were presented as a static list.

Search and filter the Credentials Inventory

Use API to disable 2FA for individual enterprise users

Use API to disable 2FA for individual enterprise users

You can now use the API to clear all two-factor authentication (2FA) registrations for an individual enterprise user. Previously, this was only possible in the UI. Using the API allows for automated and bulk operations, saving time when 2FA resets need to be done at scale.

View inactive project and group access tokens

View inactive project and group access tokens

You can now view inactive group and project access tokens in the UI. Previously, GitLab instantly deleted project and group access tokens after they expired or were revoked. This lack of a record of inactive tokens made auditing and security reviews more difficult. GitLab now retains inactive group and project access token records for 30 days, which helps teams track token usage and expiration for compliance and monitoring purposes.

View inactive project and group access tokens

Group sharing visibility enhancement

Group sharing visibility enhancement

We’re excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group’s overview page, you couldn’t see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.

We welcome feedback about this change in epic 16777.

Group sharing visibility enhancement

Change work item type to another

Change work item type to another

You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.

Change work item type to another

Speed up adding new child items by keeping the form open

Speed up adding new child items by keeping the form open

We’ve streamlined the process of creating multiple child items by keeping the form open after each submission, making it easier to add multiple entries without extra clicks. This update saves you time and ensures a smoother workflow when managing your tasks.

Workspace extensions now support proposed APIs

Workspace extensions now support proposed APIs

Workspace extensions now support enabling proposed APIs, improving compatibility and reliability in production environments. This update allows extensions that depend on proposed APIs to run without errors, including critical development tools like the Python Debugger. The change expands API access while maintaining stability.

Get started with the GitLab integration with Kubernetes

Get started with the GitLab integration with Kubernetes

In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don’t require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.

To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.

Implement OCI-based GitOps with the FluxCD CI/CD component

Implement OCI-based GitOps with the FluxCD CI/CD component

Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.

License scanning support for Swift packages

License scanning support for Swift packages

In GitLab 17.9, we added support for license scanning on Swift packages. This will allow users who use Swift within their projects to better understand the licensing of their Swift packages.

This data is available to composition analysis users through the Dependency List, SBOM reports, and GraphQL API.

Dependency list filter by component in projects

Dependency list filter by component in projects

On the Dependencies list in a project, you can now filter by the package name using the Component filter.

Previously, you could not search for packages in the Dependencies list for a project level. Now, setting the Component filter will find a packages that contain the specified string.

Dependency list filter by component in projects

Filter by identifier in the Vulnerability Report

Filter by identifier in the Vulnerability Report

In the Vulnerability Report, you can now filter the results by vulnerability identifier so you can find specific vulnerabilities (like CVEs or CWEs) that are in your project or group. You can use the identifier in conjunction with other filters like the severity, status, or tool filters. The vulnerability identifier filter is limited to reports with 20,000 vulnerabilities or less.

Filter by identifier in the Vulnerability Report

Support merge request variables in pipeline execution policies

Support merge request variables in pipeline execution policies

Pipeline execution policies now support additional merge request variables, allowing you to create more sophisticated policies that take into account information related to the merge request. This provides more targeted and efficient control over CI/CD enforcement. The following variables are now supported:

  • CI_MERGE_REQUEST_SOURCE_BRANCH_SHA
  • CI_MERGE_REQUEST_TARGET_BRANCH_SHA
  • CI_MERGE_REQUEST_DIFF_BASE_SHA

With this enhancement, you can:

  • Implement advanced security scans that compare changes between source and target branches, ensuring thorough code review and vulnerability detection.
  • Create dynamic pipeline configurations that adapt based on the specifics of each merge request, streamlining your development process.

Custom expiration date for rotated service account tokens

Custom expiration date for rotated service account tokens

When rotating an access token for a service account, you can now use the expires_at attribute to set a custom expiration date. Previously, tokens automatically expired seven days after rotation. This allows for more granular management of token lifetimes, enhancing your ability to maintain secure access controls.

New permissions for custom roles

New permissions for custom roles

You can create custom roles with the Read compliance dashboard 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.

Rotate access tokens with self_rotate scope

Rotate access tokens with self_rotate scope

You can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.

Thank you Stéphane Talbot and Anthony Juckel for your contribution!

Support for additional group memberships with multiple OIDC providers

Support for additional group memberships with multiple OIDC providers

You can now configure additional group memberships when using multiple OIDC providers. Previously, if you configured multiple OIDC providers, you were limited to a single group membership.

View access token IP addresses

View access token IP addresses

Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.

Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!

View access token IP addresses

Duo Chat is now resizable

Duo Chat is now resizable

In the GitLab UI, you can now resize the Duo Chat drawer. This makes it easier to view code outputs, or keep Chat open whilst working with GitLab in the background.

Duo Chat is now resizable

Restrict users from making their profile private

Restrict users from making their profile private

Users can choose to make their user profile public or private. Administrators can now control whether users have the option to make profiles private across their GitLab instance. In the Admin Area, “Allow users to make their profiles private” controls this setting. This setting is enabled by default, allowing users to choose private profiles.

Features in Experiment Features in Experiment

Fine-grained permissions for job tokens

Fine-grained permissions for job tokens

Job tokens are ephemeral credentials that provide access to resources in pipelines. Since these tokens inherit permissions from the user, they often have broad access capabilities. Fine-grained permissions for job tokens allow you to control which resources a job token can access in a project.

We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team, see this feedback issue.

Deprecations Deprecations

The complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Changelog

Please check out the changelog to see all the named changes:

Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating

Check out our update page.

GitLab Subscription Plans

See what your team could do with The DevSecOps Platform.

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source