GitLab 18.3 release notes

We’re excited to announce significant improvements to the group overview in Your work, designed to streamline how you discover and access your groups. The new tabbed interface features a Member tab, which provides a comprehensive view of accessible groups, and an Inactive tab to track groups pending deletion. We’ve also streamlined group management by adding Edit and Delete actions to the list view for users with appropriate permissions. We hope that these improvements make it easier to find and manage the groups that matter most to you.

We value your feedback on this update! Join the discussion in epic 18401 to share your experience with the new navigation system.

We’ve upgraded the Admin area projects list to provide a more consistent experience for GitLab administrators:

• Delayed deletion protection: Project deletions now follow the same safe deletion flow used throughout GitLab, preventing accidental data loss.
• Faster interactions: Filter, sort, and paginate projects without page reloads for a more responsive experience.
• Consistent interface: The projects list now matches the look and behavior of other project lists across GitLab.

This update brings the administrator experience in line with GitLab design standards, and adds important safety features to protect your data. Future enhancements to project management will automatically appear in all project lists throughout the platform.

GitLab 18.3 introduces several improvements to the dynamic analysis security testing job output.

This improved job output provides clear, structured information that helps you understand scan results and troubleshoot failures.

Each section of the job output is concise and intuitive, with a link to our troubleshooting documentation at the bottom of the output. To override concise job output, set DAST_FF_DIAGNOSTIC_JOB_OUTPUT: "true" in your DAST configuration.

Enterprise users want to manage their compliance frameworks and security policies across multiple top-level groups. This is often the case when all groups in an instance:

• Share the same compliance frameworks. For example, when all projects in a group must adhere to the ISO 27001 standard.
• Enforce similar policies. For example, when all groups share the same pipeline execution policy.

With GitLab 18.3, compliance and security policy management is now available in beta for GitLab Self-Managed instances. You can now create, configure, and allocate compliance frameworks and security policies from a single top-level group and enforce them across all of the other top-level groups across your GitLab Self-Managed instance.

When you use a compliance and security policy top-level group, you have a single source of truth where you can manage and edit your compliance frameworks and security policies. Group admins can then apply these compliance frameworks and security policies to all the projects within those groups.

When you manage key frameworks and policies from the chosen top-level compliance and security policy group, it’s easier to manage and enforce key compliance and security needs across your GitLab Self-Managed instance. However, groups still retain the ability to create their own compliance frameworks and security policies to address specific situations or workflows that can arise in those groups.

This feature is for GitLab Self-Managed customers because GitLab.com and GitLab Dedicated customers are already able to manage policies centrally within a single top-level group or namespace.

Workspaces now use shallow cloning to reduce startup time. During initialization, GitLab downloads only the latest commit history instead of the full Git history. After the workspace starts, Git converts the shallow clone to a full clone in the background.

This feature applies automatically to all new workspaces, no configuration is required, and it doesn’t affect your development workflow.

The GitLab CLI (glab) now includes a new top-level command, opentofu. The opentofu command is aliased to terraform and tf commands to assist with GitLab-managed
OpenTofu and Terraform states.

The following commands have been added:

• glab opentofu init: Initialize the state backend locally.
• glab opentofu state list: List all states in a project.
• glab opentofu state download: Download the latest state or a specific version.
• glab opentofu state delete: Delete the entire state or a specific version.
• glab opentofu state lock: Lock a state.
• glab opentofu state unlock: Unlock a state

To manage state with the opentofu command, you must have at least glab 1.66 or later.

GitLab now fully supports Kubernetes version 1.33. If you deploy your apps to Kubernetes, you can upgrade your connected clusters to the most recent version and take advantage of all its features.

For more information, see the Supported Kubernetes versions for GitLab features.

OAuth applications can now seamlessly integrate with your organization’s single sign-on requirements. Previously, users had to authenticate twice: first with GitLab, then with SSO, creating unnecessary friction and complexity.

Now, OAuth applications can specify a parameter in their authorization requests to automatically trigger SSO authentication when required. This provides:

• A unified authentication experience for users
• Automatic compliance with your organization’s SSO policies
• Consistent security across all GitLab integrations
• Simple implementation for developers with just a parameter addition

Your OAuth integrations now respect SSO policies automatically, eliminating confusing authentication workflows while maintaining security.

Administrators can now set the default behavior for unique domains on new GitLab Pages sites. By default, new Pages sites use unique domain URLs (like my-project-1a2b3c.example.com) to prevent cookie sharing between sites.

With this new setting for the instance, you can set new Pages sites to use path-based URLs (like my-namespace.example.com/my-project) by default. This helps organizations align GitLab Pages behavior with their workflows and security requirements.

Users can still override this setting for individual projects, and existing Pages sites remain unaffected.

This release introduces an enhanced wiki experience with three key improvements: you can now subscribe to wiki pages, view wiki comments while editing a page, and sort wiki page comments.

These enhancements help teams collaborate more effectively on documentation by letting you:

• Discuss content directly in context.
• Suggest improvements and corrections.
• Keep documentation accurate and up-to-date.
• Share knowledge and expertise.

With these updates, your GitLab wiki becomes living documentation that evolves alongside your projects through direct feedback and discussion.

You can now bulk edit more epic attributes in a group. In addition to labels, you can now update assignee, health status, subscription, confidentiality, and milestone for multiple epics at once.

This enhancement makes it faster to manage large numbers of epics by letting you apply the same changes across multiple epics simultaneously.

Use the Projects REST API to programmatically enable or disable the Pipeline execution policy setting in security policy projects with the new spp_repository_pipeline_access field. Previously, this setting could only be managed through the GitLab UI. With this enhancement, you can now:

• GET the current Pipeline execution policy status.
• PUT to enable or disable the setting programmatically.

This improvement enables better automation and integration workflows for teams managing security policies at scale.

Scan execution policy templates help you quickly create scan execution policies based on common use cases. Choose from three templates:

• Merge request security
• Scheduled scanning
• Release security

Once you select a template, choose which GitLab security scans to enable with the template to get up and running immediately. If you have more advanced use cases, you can switch to the custom configuration to extend the policy with specific branch patterns, pipeline sources, and more.

GitLab Ultimate now provides comprehensive audit events for security policy management, with events organized and centralized within each security policy project.

Security teams can now:

• Track all policy modifications with detailed metadata.
• Monitor enforcement failures, including scan and pipeline execution failures.
• Monitor skipped scan execution and pipeline execution pipelines.
• Detect policy violations within each project, including MRs merged with policy violations.
• Receive alerts when limits are exceeded.
• Detect policy configuration errors.
• Use streaming-only options for high-volume scenarios.

New audit events include:

• security_policy_create
• security_policy_delete
• security_policy_update
• security_policy_merge_request_merged_with_policy_violations
• security_policy_yaml_invalidated
• security_policies_limit_exceeded
• security_policy_violations_detected (streaming only)
• security_policy_pipeline_failed (streaming only)
• security_policy_pipeline_skipped (streaming only)
• merge_request_branch_bypassed_by_security_policy

This enhancement strengthens your security posture by ensuring you have access to policy changes, configuration errors, and enforcement gaps, enabling faster incident response and thorough auditing capabilities.

The new Service Account & Access Token Exceptions feature allows you to designate service accounts and access tokens that can bypass merge request approval policies when necessary. This eliminates friction for known automations, while preserving security controls.

Key capabilities include:

• Automated workflow support: Configure specific service accounts, bot users, group access tokens, and project access tokens to bypass approval requirements for CI/CD pipelines, pull mirroring, and automated version updates. Service accounts can push directly to protected branches using approved tokens while maintaining restrictions for human users.
• Emergency access and auditing: Enable break-glass scenarios for critical incidents with comprehensive audit trails. All bypass events generate detailed audit logs with context and reasoning, supporting compliance requirements while allowing rapid response during outages or security fixes.
• GitOps integration: Unblock common automation challenges including repository mirroring, external CI systems (Jenkins, CloudBees), automated changelog generation, and GitFlow release processes. Service accounts receive the minimum required permissions with token-based access scoped to specific projects and branches.

This enhancement maintains strict security policies with flexibility for modern DevOps automation needs, eliminating custom workarounds while preserving governance controls.

GitLab 18.3 introduces enterprise user enhancements that give organizations greater control over user privacy and lifecycle management.

Group owners can now delete enterprise users in their namespace with the Users API. This destructive action unlinks user contributions and associates them with a system-wide Ghost user. These option is particularly valuable for cleaning up users erroneously created with automated SCIM imports or managing federated environments where usernames and emails need to be repurposed.

Additionally, organizations can now hide enterprise user emails on their user profiles, providing broader email privacy enforcement for all enterprise users.

We’re also releasing GitLab Runner 18.3 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.

Bug Fixes:

• In GitLab 18.2.0, runners are unable to pull the job cache by using the subdirectory file as cache key
• Docker executor fails to start jobs intermittently and returns an incorrect username or password error message.
• Inconsistency in *_get_sources hooks usage between none and empty Git strategies
• Operator deployed with non-OLM manifests assumes wrong default images
• Operator creates ConfigMap with the wrong name if CR has the app.kubernetes.io/instance label
• Operator 1.10.0 on OpenShift 4.9 fails to create runner ConfigMap and start pod in the gitlab-runner namespace

What’s new:

• GitLab Runner Operator now supports runner manager pod annotation
• GitLab Runner Operator now supports OpenShift 4.19

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