The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Verify |
| Maturity | Lovable |
| Content Last Reviewed | 2024-12-19 |
Thanks for visiting this direction page on the Runner Core category at GitLab. This page belongs to the Runner Group within the Verify Stage and is maintained by Darren Eastman.
Vision:
Context
GitLab Runner - the near-ubiquitous build agent that executes CI jobs on a target compute platform is a critical foundational pillar of GitLab's one DevSecOps platform vision. The fundamental problems customers must solve in this product category include installing, configuring, and scaling CI/CD build agents (runners) on public or private cloud infrastructure and securely executing CI/CD jobs on heterogeneous computing architectures, x86-64, ARM, and s390x.
For customers that run millions of CI/CD jobs monthly, the primary GitLab Runner autoscaling options for CI/CD builds in ephemeral, isolated environments are Kubernetes and public cloud or on-premise virtual machine environments. Therefore, critical needs for this customer segment include consistently fast start times for builds, fast build times as measured by total wall clock time, low CI build failure rates due to runner or runner host infrastructure issues, and minimal operational overhead. Other customers require seamless support for multi-platform and architecture builds, while others need the flexibility to install a build agent according to their organization's security and compliance policies
In the calendar year 2025, our major investment themes for new features and capbilities aligned to the product organization's FY25 R&D investment themes alignment are as follows:
Drive Use Case Adoption to Fully Realize Value:
In the next three months (January to March) we plan to deliver these features or capabilities:
prepare stage.In both the 17.7 and 17.8 milestones, we are working on addressing long overdue technical debt issues aimed at improving reliability and reducing the duration of the runner release pipelines.
We are not actively working on the following features:
Runner Priority - The problem to solve for this viral feature is routing CI jobs to an available or less busy Runner. One use case that has come up in multiple customer conversations is routing CI/CD jobs to public cloud-hosted runners (cloud bursting) when the capacity of on-premise hosted runner infrastructure is at capacity. Using the public cloud for burst-only workloads is critical as it enables customers to keep their cloud costs for runner infrastructure to a minimum. For FY25, we decided not to prioritize work on a solution to this problem due to the complexity of architectural changes needed for the GitLab CI job queueing mechanism. However, recent customer interviews have highlighted how critical this problem is and the urgency of a solution for their expanded use of GitLab CI. Therefore, the next step is a small iteration, which aims to develop a proof-of-concept solution
Sticky Runners - For this feature, the problem to solve is that users need to improve CI job performance in scenarios where each job can generate intermediate build elements with hundreds of GBs in size. In the current GitLab CI model, a significant amount of pipeline execution time is due to the uploading and downloading of intermediate build elements between jobs in a pipeline. Given the current Runner executor implementation, i.e., we support several executor types out of the box (shell, docker, Kubernetes), changing the CI job execution paradigm in GitLab is a significant architectural change. The Sticky Runners MVC feature is not in the near-term roadmap due to higher priority features in the Runner core and the Verify stage.
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
When you run a continuous integration pipeline job or workflow, the code in that pipeline must execute on some computing platform to complete your software's building, testing, and deployment. Terms used to describe the software that handles the pipeline code execution include worker, agent, or runner.
So while the basic functionality of pipeline code execution is table stakes in the industry, the ability to efficiently build software on multiple compute platforms with low operational maintenance overhead are critical features for a best-in-class solution.
.gitlab-ci.yml file provides a declarative syntax for defining jobs, stages, and dependencies, making it easy for developers to set up and manage their pipelines.| Solution | CI/CD Agent naming convention/brand | Self-Managed Option Availablity | Notes |
|---|---|---|---|
| GitHub Actions | Runners | Available | At its core, GitHub Action Runners are similar to GitLab Runners in that they communicate to a central server via a REST API, execute jobs, and send the logs and artifacts back to the server when finished. However, multi-platform support, native autoscaling on cloud instances, support for Kubernetes as a build environment, concurrency, and parallel CI/CD job execution are more mature in GitLab Runner. As expected, GitHub has continued to invest in features and capabilities to improve the maturity of GitHub Action Runners. For instance, the recently released Actions Runner Controller (ARC) enables GitHub Actions Runners to autoscale on Kubernetes clusters. However, as noted by others, there is operational overhead involved in the setup and configuration of ARC. On the GitHub public roadmap, we also notice similar investment themes regarding multi-platform support as GitHub continues to target market segments requiring a self-managed platform. |
| Harness.io | Harness Delegate | Available | Harness currently provides the following types of Delegate: Kubernetes, Shell Script, AWS ECS, Helm, Docker. Though the Delegates perform a similar essential function as GitLab Runner, i.e., executes tasks provided by the Harness Manager, the Delegates' primary purpose is to deploy software to the target platform. In this regard, the value proposition of the GitLab Agent for Kubernetes is a critical consideration when evaluating capabilities in GitLab for developer frictionless cloud-native deployment. |
| Nx Cloud | Nx Agents | Available | Nx Cloud a build system for optimizing CI performance and scaling for monorepos,includes Nx agents which dynamically distrbutes the CI/CD jobs across multiple buiild machines. |
| Jenkins | Agents | Available | In Jenkins, an agent is a software executable that runs a task under the direction of the Jenkins controller. Like GitLab Runner, a Jenkins agent can run on different computing environments (bare metal, virtual machines, containers, Kubernetes clusters). Java must be supported and installed on the host OS to run a Jenkins agent. |