GitLab 19.3 (not yet released)

You can now use get_merge_request to retrieve a merge request along with its diffs, commits, notes, pipelines, or discussions in a single call, so your AI agent no longer has to chain multiple requests to get the full picture of an MR.

You can also use the new list_merge_requests tool to search and filter merge requests by author, assignee, reviewer, state, labels, or free-text query, making it easy to find exactly the MRs you care about without leaving your workflow.

Previously, the mcp scope was hidden from the OAuth applications form in the Admin area, so you couldn’t pre-register an OAuth application for your MCP clients without using Dynamic Client Registration (DCR). Now you can create a shared OAuth application with the mcp scope directly from the Admin area, giving your users a stable client ID to reuse and helping you avoid DCR rate limits on shared networks.

Mistral has deprecated the Devstral 2 model, and GitLab has deprecated Devstral 2 for GitLab Duo Agent Platform Self-Hosted. Mistral Medium 3.5 is a supported alternative available from Mistral.

In previous versions of GitLab, you couldn’t stop merges from bypassing the train. Both the option to merge immediately and the REST API could skip merge train protections without restriction. For teams running high-velocity monorepos, a single merge that skips the train can cancel and restart every in-progress pipeline, multiplying CI costs and straining infrastructure.

Now you can enforce merge train usage across the UI and API with a single project-level setting, preventing bypasses that cancel and restart in-progress pipelines. Owners and Administrators can still override the setting when needed.

In previous versions of GitLab, projects using the Bun JavaScript runtime and package manager had no dependency scanning coverage.

Now, GitLab dependency scanning analyzes Bun projects by parsing bun.lock files (the text-based JSONC format introduced in Bun 1.2).

Because Bun packages are sourced from the npm registry, the GitLab advisory database already covers these dependencies with no additional configuration required. Teams using Bun as an alternative to npm, yarn, or pnpm can now scan their projects for known vulnerabilities as part of their standard CI/CD pipelines. Eligible findings are also supported by dependency scanning auto-remediation.

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

What’s New

• Document Job Router version compatibility matrix
• Verify Workhorse is in the KAS to Rails request path for Job Router

Bug Fixes

• clear-docker-cache prunes all unused images when IMAGE_FILTER_FLAGS is empty
• Concrete-mode dispatch skips steps where When is unset
• PrintPodWarningEvents doesn’t work
• Custom executor fails when the .git folder is corrupt

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

GitLab now fully supports Kubernetes version 1.36. To deploy your applications to Kubernetes and access all features, upgrade your connected clusters to the most recent version. For more information, see supported Kubernetes versions for GitLab features.

The Security Dashboard now includes a SAST triage and remediation funnel. This funnel shows how critical and high SAST vulnerabilities move through triage and remediation over a 30-, 60-, or 90-day window. The funnel traces each stage: detected vulnerabilities, true positives confirmed by SAST false positive detection, vulnerabilities with merge requests created by Agentic SAST Vulnerability Resolution, and vulnerabilities fixed by merged merge requests. These stages show how much of your workflow AI powers and which stages you can scale further.

You can now opt-in to using PostgreSQL 18.4 when performing a fresh install using the Linux packages.

Upgrades to PostgreSQL 18.4 for existing installations is not yet supported.

For more information, refer to the relevant documentation.

GitLab Advanced SAST now supports Objective-C and Swift, bringing the same interprocedural taint analysis it delivers for other languages to iOS development. The beta is available for all GitLab Ultimate customers starting in GitLab 19.3.

The beta detects key OWASP Mobile Top 10 vulnerability classes, including insecure data storage, broken cryptography, insecure communication, and authentication and authorization flaws. When a vulnerability begins in one language and reaches a sink in the other, Advanced SAST detects the complete taint path, including paths that cross the Swift and Objective-C language boundary.

To enable, set GITLAB_ADVANCED_SAST_ENABLED: 'true' in your pipeline. If your project contains Objective-C or Swift files, the gitlab-advanced-sast-ext job runs automatically. For full setup instructions, see the Advanced SAST documentation.

Share feedback in the beta feedback issue.

In previous versions of GitLab, you had no warning when your Flex usage approached a limit. GitLab now sends billing account managers an email notification when a product reaches 50%, 80%, or 100% of its monthly reservation, and when a capped product reaches its spend cap and is cut off for the rest of the billing period. Each threshold triggers at most one email per product per billing period, so you can act on overage early without getting repeat emails for the same threshold.

On-demand usage can run up overage charges you didn’t plan for. Usage caps for GitLab Credits are now generally available: set a subscription-level cap on on-demand credits in Customers Portal, and set a default per-user cap or per-user overrides with the GraphQL API. When consumption reaches a cap, features that consume GitLab Credits, like GitLab Duo Agent Platform, are suspended until the next billing period begins or an administrator adjusts the cap. Usage caps were introduced in GitLab 18.11 behind the budget_caps_graphql_api feature flag. In GitLab 19.3, the feature flag is removed.

With GitLab Flex, overage from one capability draws down the same commitment every other capability depends on. You can now set a spend cap for each capability when you adjust your Flex reservation in the Customers Portal: Restricted (no overage past the reservation), Usage cap (a bounded amount of overage), or Unlimited (unlimited overage past the reservation). When a capped capability reaches its cap, its usage stops for the rest of the billing period, and capabilities without a cap keep running.