{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreicqtw73ywddmek6fkufinwbsy3ijdlexa7dyoldstloubnbvmyhhm",
"uri": "at://did:plc:5c4fdh2tkwp6vnd4g4oxyqyu/app.bsky.feed.post/3mmgwt7qoffp2"
},
"path": "/releases/19/gitlab-19-0-released/",
"publishedAt": "2026-05-21T00:00:00.000Z",
"site": "https://docs.gitlab.com",
"tags": [
"Notable Contributor",
"Norman",
"Related issue",
"Related epic",
"issue 598100",
"upgrade the packaged PostgreSQL server",
"Documentation",
"Migrating from the Linux package to Mattermost Standalone",
"Docker",
"migration guide",
"epic 600511",
"Norman Debald (@Modjo85)",
"Standard Webhooks",
"Van Anderson",
"Norman Debald",
"Watch the overview video",
"feedback issue",
"Runner instrumentation: Feature negotiation, OTLP export client, and first job_execution span",
"Add configurable prepare stage timeout to runner configuration",
"Comprehensive fixes for FF_SCRIPTS_TO_STEPS feature flag implementation",
"SignatureDoesNotMatch error when downloading S3 cache",
"Runtime error when GitLab Runner runs in AWS with S3 cache",
"Broken RPM S3 download links for amd64, arm64, arm, and armhf in GitLab Runner 18.9.0 and later",
"Negative exit codes are reported incorrectly on Windows",
"Incorrect Kubernetes executor service container naming documentation",
"CHANGELOG",
"@mention"
],
"textContent": "On May 21, 2026, GitLab 19.0 was released with the following features.\n\nWe’d also like to announce this month’s Notable Contributor: Norman Debald!\n\nWe are excited to recognize Norman, a Level 3 contributor with more than 40 merged improvements across GitLab since joining in May 2022.\n\n## Primary features\n\n### Group-level custom review instructions for GitLab Duo\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Add-ons: GitLab Duo Enterprise\n * Links: Documentation, Related issue\n\n\n\nIn previous versions of GitLab, you could only define custom review instructions for GitLab Duo at the project level. Teams working across many projects in the same group had to duplicate the same instructions in every project.\n\nNow you can configure shared custom review instructions for an entire group and its subgroups.\n\nSelect a project in your group to use as a template. When GitLab Duo performs a code review, it combines the group-level `.gitlab/duo/mr-review-instructions.yaml` file with any instructions defined in the individual project.\n\nBoth Code Review Flow and GitLab Duo Code Review support group-level custom instructions.\n\n### Configure work item types\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related epic\n\n\n\nPreviously, work item types could be either an **Issue** or a **Task**. You can now configure custom work item types in a project to match the way your team plans and tracks work.\n\nYou can create or rename types to **User Story** , **Bug** , or **Maintenance**. Each work items displays with it’s type name and a unique icon. The new types support custom fields and status lifecycles, and appear in your saved views and issue boards. Type configuration in the top-level group (GitLab.com) or organization (GitLab Self-Managed) cascades down to all projects.\n\nYou can also control which types are available for each project. Enable or disable a type across all projects at once, or let individual projects manage their own type visibility. When you disable a type in a project, existing work items are not affected.\n\n### GitLab Secrets Manager now available in open beta\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed\n * Links: Documentation, Related epic\n\n\n\nIn previous versions of GitLab, the GitLab Secrets Manager was available only to a closed beta cohort. Most teams relied on external services such as HashiCorp Vault or AWS Secrets Manager.\n\nThe GitLab Secrets Manager is now available in open beta for Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. When the GitLab Secrets Manager is enabled, project and group Owners can store, retrieve, and reference CI/CD secrets in GitLab. Secrets are scoped to a project or group and are accessible to only pipeline jobs that explicitly request them.\n\nDuring open beta, GitLab Secrets Manager follows the beta support policy and might not be ready for production use.\n\nTo share feedback, see issue 598100.\n\n### GitLab Duo Developer enhancements for merge request workflows\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nGitLab Duo Developer now supports multiple trigger methods: assign it to an issue, select **Generate MR** , or `@mention` it in any issue or MR discussion thread to turn feedback, To-do items, and design questions into code changes, follow-up MRs, or research summaries.\n\nWith `AGENTS.md` and `agent-config.yml` configured, GitLab Duo Developer runs your tests and checks before committing. After a top-level group or instance administrator enables the Developer Flow, GitLab automatically adds mention and assign triggers to eligible projects.\n\n### Dependency scanning by using SBOM generally available\n\n * Tier: Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related epic\n\n\n\nThe GitLab SBOM-based dependency scanner is now generally available. Maven, Gradle, and Python projects now have complete visibility into vulnerabilities across their full dependency tree, including vulnerable packages introduced transitively, not just those declared directly.\n\nThe analyzer now includes automatic dependency resolution for Maven, Gradle, and Python projects. When a lockfile or resolved dependency graph is not present, the analyzer automatically invokes tooling to resolve the full transitive dependency graph before scanning. Dependency resolution is enabled by default and requires little-to-no additional configuration beyond including the v2 Dependency Scanning template.\n\nFor projects where dependency resolution is not possible, the analyzer falls back to manifest scanning. It parses `pom.xml`, `requirements.txt`, `build.gradle`, and `build.gradle.kts` to identify direct dependencies. Manifest scanning ensures teams always get a starting point for vulnerability coverage, even for projects without lock or build files.\n\nManifest scanning is enabled by default and returns direct dependencies only. For full transitive coverage, enable dependency resolution or provide a dependency lockfile or graph export manually.\n\n## Agentic Core\n\n### GitLab Duo Core moves to usage-based billing\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nStarting in GitLab 19.0, GitLab Duo Core moves to usage-based billing. Code Suggestions in the Web IDE and desktop IDEs now consume GitLab Credits.\n\nGitLab Duo Chat is also changing. For GitLab Duo Core users, Chat is now agentic and runs on GitLab Duo Agent Platform. To use GitLab Duo Chat in the GitLab UI or desktop IDEs, enable GitLab Duo Agent Platform for your instance or top-level group.\n\n### Filter exact code search results by repository\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nYou can now filter exact code search results by repository. With the `repo:` syntax, you can directly scope your search query to specific repositories or repository patterns without having to go to individual projects.\n\nFor example, searching for `def authenticate repo:my-group/my-project` returns results only from that repository. You can also use partial paths or patterns to match multiple repositories.\n\n### Merge request ready event trigger\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nYou can now configure flows and external agents to run on the **Merge request ready** event.\n\nWhen a draft merge request is marked as ready for review, GitLab Duo automatically runs the flow or external agent.\n\nTo configure a trigger, go to **AI** > **Triggers** in your project.\n\nThis feature is behind the `merge_request_ready_flow_trigger` feature flag, disabled by default.\n\n### Claude Opus 4.7 now available in GitLab Duo Agent Platform\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nClaude Opus 4.7 is now available in GitLab Duo Agent Platform. Opus 4.7 delivers meaningful improvements to complex, multistep tasks that require sustained reasoning, precise instruction following, and self-verification before surfacing results. This includes flows supporting CI/CD pipelines, code review, vulnerability resolution, and more.\n\n### Support for self-hosted Gemini models\n\n * Tier: Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nGitLab Duo Agent Platform Self-Hosted is now compatible with Gemini models. Gemini models support multiple flows, including the Code Review Flow, SAST Vulnerability Resolution Flow, Fix CI/CD Pipeline Flow, and more.\n\n### Expanded open source model support in GitLab Duo Agent Platform\n\n * Tier: Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nGitLab Duo Agent Platform now supports additional open source models for self-hosted deployments, including Devstral 2 123B, GLM-5.1-FP8, and others. This helps customers power agentic workflows across a variety of environments, including offline and network-restricted deployments.\n\n### Per-session tool approvals with admin controls\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nBefore GitLab Duo Agentic Chat can use a tool on your behalf, it requires your approval. Each tool invocation requires a separate approval.\n\nNow, you can approve a trusted tool once for an entire session and streamline your workflows.\n\nAdministrators control whether tool approval for sessions is available. The following settings cascade from instance to group to project:\n\n * **On by default**\n * **Off by default**\n * **Always off**\n\n\n\nGroups and subgroups can modify the setting unless an administrator sets it to **Always off**.\n\nThe default setting is **Off by default** , ensuring each tool invocation requires explicit approval unless an administrator changes it.\n\n### Resolve merge conflicts with GitLab Duo (Beta)\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nIn previous versions of GitLab, you had to resolve merge conflicts manually in the GitLab UI or from the command line, even for straightforward cases.\n\nNow GitLab Duo can autonomously analyze merge conflicts, edit the conflicting files, create a commit, and push to the source branch. Trigger conflict resolution from the **Resolve conflicts** page or directly from the merge request widget. When complete, GitLab Duo posts a summary comment so reviewers can see what changed.\n\nGitLab Duo respects branch protection rules and does not force-push to protected branches.\n\nThis feature is in beta and is gated behind the `mr_ai_resolve_conflicts` feature flag, disabled by default.\n\n### Restrict the AI Catalog to a group hierarchy\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nTop-level group Owners can now restrict the AI Catalog to show only agents and flows owned by projects within their group hierarchy. This blocks agents, external agents, or flows not in this hierarchy from being visible or enabled by any user in that group.\n\n### Purchase credits on the Free tier on GitLab Self-Managed\n\n * Tier: Free\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nFree tier users on GitLab Self-Managed can now unlock the full power of GitLab Duo Agent Platform, no Premium or Ultimate subscription required. Choose your monthly credit amount, commit to an annual term, and get instant access to AI-powered development tools. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.\n\n### Admin-defined network access controls for Agent Platform remote flows\n\n * Tier: Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nAdministrators can now define centralized network policies for GitLab Duo Agent Platform remote flows directly in Settings. Top-level group administrators on GitLab.com, and instance administrators on GitLab Self-Managed and Dedicated, can configure organization-wide domain denylists and allowlists that projects inherit automatically. An additional setting controls whether projects can extend the approved domain list with custom entries. Policies are enforced at runtime across all remote flows, giving security and platform teams a consistent governance layer for agent network egress.\n\n## Scale and Deployments\n\n### PostgreSQL 17 minimum requirement\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nThe minimum supported version of PostgreSQL is now version 17. If you use the packaged PostgreSQL 16, upgrade the packaged PostgreSQL server before installing GitLab 19.0.\n\n### Linux package support for Ubuntu 20.04 discontinued\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nUbuntu 20.04 reached end of standard support in May 2025. From GitLab 19.0, Linux packages are no longer provided for Ubuntu 20.04. GitLab 18.11 is the last release with packages for this distribution. Before upgrading to GitLab 19.0, migrate to Ubuntu 22.04 or another supported operating system.\n\n### Redis 6 support removed\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nSupport for Redis 6 is removed in GitLab 19.0. If you use an external Redis 6 deployment, migrate to Redis 7.2 or Valkey 7.2 before upgrading. The bundled Redis included with the Linux package has used Redis 7 since GitLab 16.2 and is not affected.\n\n### Mattermost removed from the Linux package\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nBundled Mattermost is removed from the Linux package in GitLab 19.0. If you currently use the bundled Mattermost, refer to Migrating from the Linux package to Mattermost Standalone for migration instructions. Customers not using the bundled Mattermost are not impacted.\n\n### Linux package support for SUSE distributions discontinued\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nLinux package support for SUSE distributions ends in GitLab 19.0, which affects openSUSE Leap 15.6, SUSE Linux Enterprise Server 12.5, and SUSE Linux Enterprise Server 15.6. GitLab 18.11 is the last version with Linux packages for these distributions. To continue to use SUSE distributions, migrate to a Docker deployment of GitLab.\n\n### Spamcheck removed from Linux package and GitLab Helm chart\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nSpamcheck is removed from the Linux package and GitLab Helm chart in GitLab 19.0. Customers not currently using Spamcheck are not impacted. If you use the bundled Spamcheck, you can deploy it separately using Docker. No data migration is required.\n\n### NGINX Ingress replaced by Gateway API with Envoy Gateway\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nGateway API with Envoy Gateway becomes the default networking configuration in the GitLab Helm chart in GitLab 19.0, replacing NGINX Ingress which reached end-of-life in March 2026. If migration to Envoy Gateway is not immediately feasible, you can explicitly re-enable the bundled NGINX Ingress, which remains available until its planned removal in GitLab 20.0. This change does not impact the NGINX used in the Linux package, or Helm chart instances using an externally managed Ingress or Gateway API controller.\n\n### Bundled PostgreSQL, Redis, and MinIO removed from GitLab Helm chart\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nThe bundled Bitnami PostgreSQL, Bitnami Redis, and MinIO charts are removed from the GitLab Helm chart and GitLab Operator in GitLab 19.0 with no replacement. These components were intended only for proof-of-concept and test environments and are not recommended for production use. If you run an instance with any of these bundled services, follow the migration guide to configure external services before upgrading to GitLab 19.0.\n\n### Reliable SCIM user deprovisioning for large groups\n\n * Tier: Premium, Ultimate\n * Offering: GitLab.com\n * Links: Documentation, Related issue\n\n\n\nFor organizations managing large numbers of users through SCIM, deprovisioning group members could time out and return `500` errors. SCIM `DELETE` and `PATCH` requests now return a success response immediately. Membership removal is handled asynchronously, so identity providers and SCIM clients receive consistent success responses.\n\n## Unified DevOps and Security\n\n### Auto remediation for vulnerable dependencies (Experiment)\n\n * Tier: Ultimate\n * Offering: GitLab.com\n * Links: Documentation, Related epic\n\n\n\nAuto remediation for dependencies is now available as an experiment in GitLab 19.0. When dependency scanning detects a vulnerable Ruby dependency with a known fix, GitLab automatically opens a merge request to update it to a safe version without human input. Only Ruby projects are supported in the experiment.\n\nAfter each pipeline, GitLab identifies the highest-severity vulnerability with an available patch or minor version upgrade. GitLab generates the manifest file change and opens a merge request through a service account. The merge request then goes through your project’s standard review and approval workflow.\n\nDuring the experiment, up to three auto-remediation merge requests can be open per project at a time.\n\nTo share feedback or request to try out the experiment make a comment on epic 600511. To enable the experiment on your project, a GitLab team member must enable the `dependency_management_auto_remediation` feature flag for your project.\n\n### Dependency scanning in security configuration profiles\n\n * Tier: Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation, Related issue\n\n\n\nGitLab 18.11 introduced security configuration profiles for SAST and secret detection. Now, dependency scanning is also available with the **Dependency Scanning - Default** profile. This profile gives you a unified control surface to apply standardized SCA coverage across all of your projects without editing a single CI/CD configuration file.\n\nThe profile activates two scan triggers:\n\n * **Merge Request Pipelines** : Automatically runs a dependency scanning scan each time new commits are pushed to a branch with an open merge request. Results include only new vulnerabilities introduced by the merge request.\n * **Branch Pipelines (default only)** : Runs automatically when changes are merged or pushed to the default branch, providing a complete view of your default branch’s dependency posture.\n\n\n\n### Dependency resolution for Gradle SBOM scanning\n\n * Tier: Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation | Related epic\n\n\n\nGitLab dependency scanning using SBOM now automatically generates a dependency graph (`gradle.graph.txt`) for Gradle projects. Previously, Gradle dependency scanning required you to generate a dependency graph manually as part of your build. Now, when a graph file is not available, the analyzer generates one automatically, removing this manual step for Java and Kotlin projects using Gradle.\n\n### Improved array support for CI/CD inputs\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation, Related issue\n\n\n\nCI/CD inputs now have improved support for working with arrays. Use the array index operator `[]` to access specific elements within array inputs. This enhancement provides more flexible and powerful input interpolation capabilities in your pipeline configurations, enabling you to reference individual array items directly without additional processing steps.\n\n### Select multiple values for pipeline inputs\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation, Related issue\n\n\n\nPreviously, you could only select a single value when selecting input options in the UI, limiting flexibility for pipelines with more complex options.\n\nNow when you run a pipeline with inputs from the UI, you can select multiple values from a dropdown list and the selected values are combined into an array, for example `[\"option1\",\"option2\"]`. This makes it easy to restart services on multiple instances, build multiple Docker images, run tests with multiple tag combinations, or perform any operation across multiple targets in a single pipeline run.\n\n### Detailed CI/CD Catalog component usage analytics\n\n * Tier: Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nWhen you manage a CI/CD component in the GitLab Catalog, usage details are critical for managing upgrades, enforcing compliance, and communicating breaking changes. You need to know which projects use your components, and which versions they are using. Previously, this information was not available, making it difficult to notify the right maintainers, plan deprecations safely, or ensure projects stay current with the latest security patches.\n\nThe component usage details view in the catalog resource page now shows exactly which projects use each component, the version they are running, and whether they are on the latest version or an outdated one. Projects using older versions are surfaced at the top, so you can prioritize outreach, drive adoption of security fixes, and ensure a smooth upgrade path across your organization.\n\n### Configure parallel pipeline limits for merge trains\n\n * Tier: Premium, Ultimate\n * Offering: GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation,\n * [Related issue](https: //gitlab.com/gitlab-org/gitlab/-/work_items/374188)\n\n\n\nIn previous versions of GitLab, you couldn’t change the maximum of 20 parallel pipelines in a merge train, which forced you to either overwhelm your runners or skip merge trains entirely. Now you can configure the parallel pipeline limit per merge train to balance runner load and merge throughput. You can set the limit per project or instance-wide. Setting the limit to 1 means each merge request runs one at a time, against a clean target branch.\n\nThanks to Norman Debald (@Modjo85) for this community contribution.\n\n### Customize default merge request titles\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nIn previous versions of GitLab, the default title for a new merge request came from the source branch or first commit, and you couldn’t enforce a consistent naming convention across your project.\n\nNow you can configure a default merge request title template per project. Templates support variables for the source branch, target branch, first commit subject, linked issue ID, issue title, and a human-readable version of the source branch name. For example, the template `Resolve %{issue_id} \"%{issue_title}\"` produces titles like `Resolve 123 \"Fix login bug\"`. You can still edit the title before creating the merge request.\n\n### Secure webhooks with HMAC signing tokens\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation, Related issue\n\n\n\nThe existing `X-Gitlab-Token` header sends a static secret in plain text, making webhooks susceptible to interception and replay attacks.\n\nYou can now add a signing token to any webhook. GitLab uses the signing token to compute an HMAC-SHA256 signature over:\n\n * The unique webhook ID.\n * The request timestamp.\n * The webhook payload.\n\n\n\nGitLab then sends the result in the `webhook-signature` header alongside `webhook-id` and `webhook-timestamp` headers, following the Standard Webhooks specification.\n\nYou can recompute the signature to confirm requests genuinely came from GitLab and that the payload has not been modified. By also validating the timestamp, you can reject replayed requests.\n\nThanks to Van Anderson and Norman Debald for their community contributions!\n\n### Cross-project pushes using CI/CD job tokens\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation, Related issue\n\n\n\nIn previous versions of GitLab, you could only use a CI/CD job token (`CI_JOB_TOKEN`) to push to the same repository where the pipeline runs. Cross-project pushes required a personal access token or deploy token.\n\nYou can now use a job token to push to another project when:\n\n 1. The target project opts in.\n 2. The user who starts the pipeline has at least the Developer role in the target project.\n\n\n\nThis feature is behind the `allow_push_to_allowlisted_projects` feature flag, disabled by default in GitLab 19.0. Ask your administrator to enable it.\n\n### Mermaid diagram rendering upgraded to version 11\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated\n * Links: Documentation, Related issue\n\n\n\nGitLab now uses Mermaid version 11 for rendering diagrams in Markdown.\n\nPreviously, GitLab supported Mermaid version 10. With this upgrade, you get access to all the new diagram types, syntax improvements, and bug fixes introduced in Mermaid 11, including enhanced rendering for flowcharts, sequence diagrams, and more.\n\n### Rapid Diffs for merge request reviews (Beta)\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed\n * Links: Documentation, Related issue\n\n\n\nIn previous versions of GitLab, you would have to wait for the **Changes** tab to load all files before you could begin reviewing, which slowed down large reviews.\n\nNow you can use Rapid Diffs to review merge requests with faster initial load, smoother scrolling, and more responsive interactions across files. Rapid Diffs uses the same technology that already powers the commits page.\n\nRapid Diffs is in beta. Some features from the classic diff experience aren’t yet available. You can switch back at any time.\n\nWatch the overview video and share your experience in the feedback issue.\n\n### GitLab Runner 19.0\n\n * Tier: Free, Premium, Ultimate\n * Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated, GitLab Dedicated for Government\n * Links: Documentation\n\n\n\nWe’re also releasing GitLab Runner 19.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.\n\n#### What’s New\n\n * Runner instrumentation: Feature negotiation, OTLP export client, and first job_execution span\n * Add configurable prepare stage timeout to runner configuration\n\n\n\n#### Bug Fixes\n\n * Comprehensive fixes for FF_SCRIPTS_TO_STEPS feature flag implementation\n * SignatureDoesNotMatch error when downloading S3 cache\n * Runtime error when GitLab Runner runs in AWS with S3 cache\n * Broken RPM S3 download links for amd64, arm64, arm, and armhf in GitLab Runner 18.9.0 and later\n * Negative exit codes are reported incorrectly on Windows\n * Incorrect Kubernetes executor service container naming documentation\n\n\n\nThe list of all changes is in the GitLab Runner CHANGELOG.",
"title": "GitLab 19.0",
"updatedAt": "2026-05-21T00:00:00.000Z"
}