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.
The delivery direction covers the deployment and release features and capabilities in GitLab and two related concepts, Continuous Delivery and Continuous Deployment. Delivery is composed of two parts, deployment and release. Deployment covers the processes and actions needed to deploy a new version of the software to a target infrastructure. This includes both production and non-production infrastructures. Release includes the processes and actions needed to make a deployed application available to users. This encompasses both the packaging of code artifacts with associated metadata and the orchestration of making those changes accessible to end users.
Continuous Delivery(CD) tools automate the process of delivering code changes to target environments (development, test, production) reliably and efficiently, typically after passing quality or compliance checks when the target is a production environment.
Continuous Deployment goes one step further than Continuous Delivery. In Continuous Deployment, every change that goes through a deployment pipeline is automatically promoted to production, resulting in many production deployments every day.
GitLab's Delivery vision is to make sophisticated deployment automation accessible to every developer, for every - platform, everywhere.
We will accomplish this by
For Developers:
For Platform Engineers:
For Operations:
We created a glossary to discuss related terms in a consistent way.
The delivery tooling market is evolving and expanding. There are now many more options than just adding a deployment job to your CI/CD pipeline. Release Orchestration, advanced releases, GitOps, infrastructure provisioning, platform as a service, progressive delivery, and feature flags are all methodologies that help teams deliver software more easily, frequently, and confidently. Completeness of feature sets from vendors is becoming increasingly important as teams want the benefits from all worlds; traditional, table stakes deployment features alongside modern, differentiating features.
To increase deployment frequency and be competitive in the market, enterprises have turned to centralized cloud teams or cloud center of excellence that are responsible for helping development teams be more efficient and productive. These teams have centralized buying power for DevOps and delivery tools. They may also have organizational support to build a DIY DevOps platform. For cloud-native DIY platforms, we've found (through customer interviews) that open-source point deployment solutions (such as Flux or ArgoCD) are the primary options because of their focus on cloud-native principles and early adoption of pull-based deployment. These tools often come with auxiliary tooling for release management, like Flagger and Argo Rollouts Otherwise, enterprises, even existing GitLab customers, sometimes buy commercial tools for deployment, such as Octopus, Harness, and CloudBees electric flow.
The market leading enterprise CD platforms of the future must include the following core capabilities: automated deployment pipeline orchestration, compliance frameworks, automated approval gates, integration with multiple artifact repositories, environment management, integration with Agentic AI systems, support for easily configured advanced deployment strategies (blue-green, canary, rolling updates) feature flag support, observability, comprehensive audit trails and audit logging.
Modern, Developer-Friendly Experience
Compliance-Ready by Design
First-Class Auditing and Accountability
**Enterprise ready
In Delivery, our primary persona is Priyanka (Platform Engineer). They are responsible for setting up the systems that development teams use to develop, test, ship, and operate their applications. They - likely - work at an enterprise where there is a mix of delivery targets from VMs to Kubernetes and bare metal to cloud infrastructure. They also face the challenges of ever-increasing complexity; as more contributors, more services, more infrastructure, more databases, and a mix of technologies are added to their applications. They are looking for ways to create a system to manage the complexity at scale, and especially to present the necessary parts of this complexity to their users, the application operators.
In line with Priyanka's users, our most important secondary persona is Allison (Application Operator).
As our primary target customers are enterprise customers, we want to make sure that regulatory and compliance requirements related to application delivery are covered from the start. As a result, we pay special attention to the needs of Cameron (Compliance Manager) and Rachel (Release Manager).
and Ingrid (Infrastructure Operator).
Enterprises are increasingly choosing to have a cloud-first strategy. Furthermore, with the increasing adoption of microservices architecture and infrastructure as code, traditional release tools are inadequate. This, coupled with the traditional delivery requirements of governance, compliance, and security, means that delivery tools have to meet a high bar and address a set of evolving technology and compliance requirements. The primary themes for these capabilities are that first organizations need collaboration and transparency, then control and compliance and before requiring measurement and advanced patterns. We list these key capabilities of deployment platforms in priority order of user need:
Collaboration and Transparency
Control and Compliance
Measurement and Advanced Patterns
GitLab has a market-leading CI/CD solution. Deployments and releases using GitLab's CI/CD pipelines work well for many use cases. GitLab users love the developer enablement provided by our robust pipeline definition language, but they find it painful to write and manage hundreds of lines of code to describe their custom delivery logic. Similarly, orchestrating large deployments across projects is painful with GitLab. This complexity is exacerbated by the complexity of infrastructure and the delivery domain. Customers today look for alternative solutions, like FluxCD to hide some of the complexity from software engineering teams.
Independent software deliveries - for the delivery of individual projects that can be deployed in an automated fashion without coordination, developers deploy using CI/CD pipelines in the following ways:
Kubernetes deployments - for deployments to Kubernetes, we have support for pull-based GitOps via the Kubernetes Agent and FluxCD, while push-based GitOps is supported by CI/CD tunnel. Supporting both push- and pull-based deployments, GitLab can be used to migrate to full GitOps approaches of Kubernetes management and can support even dynamic use cases that pull-based only approaches struggle supporting.
Visualising deployment status - once a deployment reaches its target infrastructure, application operators want to make sure that it's running smoothly and serves its users, and they want to be able to troubleshoot issues if needed. GitLab offers a minimal UI to show the status of deployments in Kubernetes.
Orchestrated delivery - for complex releases, particularly those that require orchestration across multiple projects, release managers use Releases to gather artifacts. Sometimes release managers collaborate on the delivery process using GitLab's release.
Continuous Delivery - many industries have strict regulatory requirements to follow that direct them to Continuous Delivery practices. GitLab supports Continuous Delivery via Protected environments and Deployment approval rules.
None of these methods are duplicative and each serves different use cases.
To build toward the future vision, we're first ensuring our existing capabilities are stable and reliable. For Q4 FY26 (November 2025 - January 2026), we're focused on critical maintenance work including reducing severity 1-2 bugs and addressing technical debt in the Deploy stage.
Simultaneously, we're incorporating enterprise customer feedback to refine our delivery roadmap and ensure our next phase of development addresses the most pressing market needs.