GitLab 18.0 release notes

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

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.

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.

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.

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.

You can now choose to run Application Security Testing (AST) scanners in merge request (MR) pipelines. To minimize the impact to your pipelines, this is as an opt-in behavior you can control.

Previously, the default behavior depended on whether you used the Stable or Latest CI/CD template edition to enable a scanner:

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

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.

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.

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!

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 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:

1. In your group, go to Security & Compliance > Policies
2. Create or edit a license approval policy.
3. Find the new package exception options in the visual editor or configure them in YAML mode.
4. Choose between allowlist or denylist mode for the licenses.
5. Add specific licenses to your policy.
6. For each license, define package exceptions in PURL format (for example, pkg:npm/@angular/animation@12.3.1).
7. 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.

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.

Thank you John Parent for your contribution!

We’ve made significant improvements to GitLab Query Language (GLQL) views. These improvements include support for:

• The >= and <= operators for all date types
• The View actions dropdown in views
• The Reload action
• Field aliases
• Aliasing columns to a custom name in GLQL tables

We welcome your feedback on this enhancement, and on GLQL views in general, in issue 509791.

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.

Previously, you had to configure the integration to create Jira issues from vulnerabilities from the Project settings page.

You can now configure this integration from the project integrations API, which allows you to automate the setup.

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.

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.

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.

What’s new:

• Add ConfigurationError and ExitCodeInvalidConfiguration to the GitLab Runner build error classifications
• Improve cloud provider error messages for failed cache uploads to cloud storage

Bug Fixes:

• GitLab Runner can use cached images even when disallowed

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