Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Deployment Direction

We would appreciate your feedback on this direction page. Please comment on our async AMA issue, email Kevin Chu or propose an MR to this page!



What is Deployment?

Deployment is when you promote a coded, integrated, and built software application to a production environment. Once you deploy an application, users derive value from it. Deployment is part of GitLab's Ops section.

In the journey to become elite DevOps performers, deployment is the hardest challenge. Deployment is where development and operations meet. Deployment is a team sport. It requires empowered developers and it requires guard rails set by operators. In overcoming these hurdles, teams must:

Ephemeral infrastructure blurs the line between infrastructure config and software release. As a result, we include our Configure and Release stages in our Deployment direction.

GitLab's Deployment Vision

GitLab's Deployment vision is to enable your organization to be an elite performer in DevOps by making the hardest part of DevOps - deployment - easy, flexible and secure.

We will accomplish this by

  1. Empowering platform engineers to define and automate DevOps practices that have security and compliance guard rails built directly into the process. By empowering the platform engineer Priyanka, she, in turn, enables developers to own their specific deployment operations without toil, yet retain flexibility and efficiency.
  2. Enabling developers to deploy applications consistently and frequently in a compliant, reliable, and repeatable way, no matter the deployment target(s) you've defined or how you've organized your applications and teams.
  3. Taking advantage of the data available in the connected GitLab platform, from planning input to observability and incident data, to make deployment operations, such as scaling rollouts or rollbacks automatic.


The total addressable market (TAMkt) for DevOps tools targeting the Release and Configure stages was $1.79B in 2020 and is expected to grow to $3.25B by 2024 (13.8% CAGR) (i). This analysis is considered conservative as it focuses only on developers and doesn't include other users. External market sizing shows even more potential. For example, continuous delivery alone, which does not include categories such as infrastructure as code, is estimated to have a market size of $1.62B in 2018 growing to $6B by 2026 (17.76% CAGR). This, like the Ops market in general, is a deep value pool and represents a significant portion of GitLab's expanding addressable market.

The deployment tooling market is evolving and expanding. There are now many more options than just adding a delivery job to your CI/CD pipeline. Release Orchestration, advanced deployments, GitOps, infrastructure provisioning, platform as a service, progressive delivery, and feature flags are all methodologies that help teams deploy more easily, frequently, and confidently. Completeness of feature set 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 deployment 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. Otherwise, enterprises, even existing GitLab customers, sometimes buy commercial tools for deployment, such as octopus, harness, and CloudBees electric flow.

Current Position

GitLab has a market-leading CI/CD solution. Deployment using GitLab's CI/CD pipelines work well for many use cases. In particular, CI/CD pipelines are great for individual projects which deploy independently. GitLab users love the ability to define their deployment process as code. They love the developer enablement provided by our robust pipeline definition language.

Independent deployments - for deployments 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, developers use custom CI/CD variables when writing pipelines that deploy to attached Kubernetes clusters. We recently added support for pull-based GitOps via the Kubernetes Agent.

Orchestrated deployment - for complex deployments, particularly those that require orchestration across multiple projects, release managers use Releases to gather artifacts. Sometimes release managers collaborate on the deployment process using GitLab's release.

None of these methods are duplicative and each serves different use cases. However, we will focus on improving:

We will also create clarity in the deployment options and retain our focus by:


The Ops section challenges are applicable to deployment. Some challenges are worth expanding on with some additional highlights:


The Ops section opportunities apply to deployment. GitLab also has some important opportunities to take advantage of specific to deployment:

Key Capabilities for Deployment

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 deployment requirement of governance, compliance, and security, means that deployment 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

  1. Environment management: Organizations typically operate multiple environments, each serving different needs. Deployment tools should help to make managing environments easy and intuitive.
  2. Everything as code: Deployment tooling, including pipelines, infrastructure, environments, and monitoring tools, are constantly evolving. If they can be stored as code and version-controlled, it will enable organizations to more effectively collaborate and avoid costly mistakes.

Control and Compliance

  1. GitOps: Simply checking code into a repository will not prevent drift to occur between code and what is deployed. GitOps solves this problem by automatically managing changes using the single source of truth reflected in the source repository providing more control by preventing drift.
  2. Release Orchestration & Quality gates: Organizations need to control what can be deployed and in which sequence. Enabling reviews and approvals built right into the deployment workflow is a critical requirement. The ability to perform automatic rollback, environment freeze, and scaling deployment also enables organizations to be more in control.

Measurement and Advanced Patterns

  1. Feedback: Deployment is a critical part of the DevOps feedback loop. A successful deployment depends on immediate feedback from Monitoring and Observability tools to ensure a healthy deployment. Furthermore, knowing that an deployment was successful is not just about knowing whether the application deployed is healthy, it also requires understanding the impact to downstream neighbors and the environment as a whole.
  2. Reporting: Understanding how the DevOps team and the entire organization is performing, such as using the DORA metrics, is important to enable iteration towards stronger performance.
  3. Progressive delivery: Deployments can be risky. To mitigate risks, progressive delivery techniques, such as using feature flags, canary and rolling deployments can help mitigate the risk by limiting the impact until the deployment teams are confident that their changes are good to go.


In Deployment, we are targeting Priyanka (Platform Engineer) as our primary persona. She is responsible for setting up the systems her company's development teams use to develop, test, ship, and operate their applications. It is likely she works at an enterprise where there is a mix of deployment targets. She also faces the challenges of ever-increasing complexity; as more contributors, more services, more infrastructure, more databases, and a mix of technologies are added to her applications. She is looking for ways to create a system to manage the complexity.

We plan to iteratively create a solution that addresses priority needs of collaboration and transparency before beginning to focus on control and compliance. We'll do that by focusing on two pillars. We want to make it easy for Priyanka to:

  1. Enable her developers to deploy to Kubernetes. Kubernetes is growing fast and also is a shortcut around building specific integrations with cloud vendors. Kubernetes is an efficient target for deployment. It is also where deployment innovation is happening fastest. It is important that we mitigate this low-end disruption and make deployments to Kubernetes that work by default.
  2. Control her organization's deployment process. GitLab enterprise customers may strive for progressive delivery and other advanced deployment features, however we can't expect enterprises to immediately hurdle release challenges that come along with their traditional deployment targets. Their current challenges are with more controlled release processes and the coordination, collaboration and compliance required when orchestrating releases. We want to solve for these initial needs first by providing a great Release Orchestration UI within GitLab. This is how we can facilitate the Golden Journey from Verify to Release.

One Year Plan

Execute on new categories

Environment Management

Within GitLab today, Priyanka manages environments by defining them directly in gitlab-ci.yaml. This works well when she is managing environments per project, but not when she is managing central platform environments that have multiple applications deploying to them from separate projects. She needs visibility to the environments and the deployments to those environments from across multiple projects.

Deployment Management

Within GitLab today, Priyanka uses gitlab-ci.yaml templates and snippets to publish deployment best practices for the developers she supports to use. This works when the number of projects is small, and the infrastructure and deployment patterns are sufficiently common. It becomes painful when Priyanka is attempting to define the complex infrastructure and multiple deployment methods across a larger number of teams. It becomes even more complicated when she tries to understand the status of deployments across multiple development teams. Priyanka needs a way to enable multiple teams to follow the best practices she defines across multiple projects and track their deployment status with ease.

Continuous Verification

Continuous verification (currently not a product category) is the collection and analysis of data to ensure the application performance is within predetermined quality limits. Practically, this means monitoring your application for abnormalities after a deployment. We plan to enable teams to practice continuous verification using GitLab's new observability capabilities. We also recognize that teams may have alternative preferences for their monitoring or observability platform. We plan to start building a vendor-agnostic experience, that enables the same continuous verification experience all within GitLab.

Continue investment in our existing categories

Kubernetes Management

We've recently adjusted our approach to connecting Kubernetes clusters to your GitLab instance (with the Kubernetes Agent). We will continue to add agent-based, cross-project cluster management capabilities that target Priyanka's pain points when managing centralized Kubernetes clusters.

Release Orchestration

We'd previously made investments in improving the experience for more traditional release engineering processes. We are restarting this investment to provide a foundation for platform teams who need to participate in a centrally coordinated release effort. We will shift our focus to enable Priyanka to control access to specific environments and to set up approval workflows. We will also enable Priyanka with tools to set up release managers to organize releases from multiple projects that will be deployed together.

Infrastructure as Code

We've made considerable improvements to the way you manage your infrastructure with Terraform from within GitLab. We will continue to build capabilities for sharing, collaborating, and enabling developer use of infrastructure definitions provided by platform teams.

Measure Success

GitLab is uniquely positioned as a solution to visualize how well teams are shipping software. Surfacing important health metrics, such as the DORA4 metrics, will help fuel improvement and adoption of additional GitLab features.

What we aren't focused on now

There are important things we won't work on to focus on our one year plan.

  1. Auto DevOps Deployments - While we will enable the creation of Auto DevOps style templates and experiences for the developers in their organization by platform teams, we will not be making significant strides to make Auto DevOps deployments cover a broader set of use cases at this time.
  2. Progressive Delivery - By focusing on where platform teams are today, we'll forgo pushing further on our current progressive delivery capabilities like Feature Flags, A/B Testing and Canary Deployments.
  3. Cost Optimization - We should first improve adoption of our Kubernetes Management capability before focusing more on cluster costs. Enterprises want views into costs beyond clusters. Building capabilities like environment management precedes cost optimization tooling.
  4. Non-Kubernetes Cloud-native - Distinguishing from Kubernetes-native, which is our initial focus area. We will not be focused on other cloud-native solutions, such as Docker Swarm, Apache Mesos, and Amazon ECS, because they're not nearly as successful as Kubernetes.
  5. Building more Deployment Methods - Actively adding templates or improving existing templates is not our main focus. Nor is building customized images for deploying to cloud providers. The CI/CD pipeline is flexible and enables GitLab users to create what they need as is. It is worthwhile to examine how we can enable the wider GitLab community, including our customer success teams, to share and reuse similar templates and treat them as lego blocks that can be adopted and put to use quickly. These will be most beneficial for common deployment targets, such as Fargate and Lambda.
  6. GitLab Pages - While the deployment of static sites is a large market, GitLab Pages is more of a fit for sharing static webpages within an organization today. We are exploring how to accelerate deploying static content more generally in the Jamstack SEG

What's next

Beyond Release and Configure, Monitor is also an important aspect of operating your production deployments. We will be adding direction content on this topic.

Lastly, within GitLab, the nomenclature for deployments, environments, release, delivery are often inconsistent, interchangeable, and confusing. We need to settle on a standard and build it into our products and documentation.

Jobs To Be done

Competitive Landscape

GitHub Actions

GitHub Actions are an automation workflow integrated with GitHub repositories. Each action is triggered by one or multiple events. Using GitHub Actions, users can define any number of jobs, including deployment jobs. Microsoft has setup actions to be like lego pieces, and has built a workflow around finding and reusing actions in an actions marketplace.

GitHub Actions recently introduced environments which can help users set specific rules based on environments to automate deployment workflows. Furthermore, environment scoped secrets enables different secrets for different tiers, separating deployment from development to meet compliance and security requirements.


Harness is a modern, ambitious CI/CD platform that can be a single platform to build, test, deploy and verify any application. Read more about Harness in our DevOps tools comparison page.


Spinnaker, born out of Netflix, is an open-source, cloud-native, multi-cloud continuous delivery platform for releasing software changes.

It views its solution in three parts. First, application management which enables users to visualize and manage cloud resources. Second, application deployment is a powerful and flexible pipeline management system with integrations to the major cloud providers and treats deployments as a first-class citizen. Lastly, managed delivery combines application management and delivery, and enables users to specify what they want in declarative format.

Spinnaker's advantage points are:

One analysis of GitLab vs. Spinnaker can be found on our product comparison page. There is additional analysis that can be found in gitlab#197709 and in gitlab#35219.


Waypoint, by Hashicorp, provides a modern workflow to build, deploy, and release across platforms. Waypoint uses a single configuration file and common workflow to manage and observe deployments across platforms such as Kubernetes, Nomad, EC2, Google Cloud Run, and more. It maps artifacts to runtime after the test and build phases. Waypoint sits alongside the source code, and enables declarative deployment - it takes the manifest of how the platform is configured and will execute the steps sequentially unique for each platform. Waypoint can be used with GitLab CI and even with the Auto DevOps workflow with deployments being done by Waypoint.


Argo CD is part of the Argo Project which is a incubation project in CNCF. Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD is installed as an application in its own namespace in a cluster. Optionally, you can also register additional clusters to do multi-cluster deployments.

Beyond enabling users to practice GitOps, Argo CD does a great job reporting and visualizing the differences between your target state and live state, which greatly facilitates learning and understanding for operators.

Combined together with the other Argo Project capabilities, including Workflow, Rollouts, and Events, using Argo is a fairly complete way to manage the entire Kubernetes Development lifecycle.


Weaveworks positions itself as a Kubernetes platform, enabling devops teams to do GitOps, to manage cluster lifecycles, and to monitor applications. Weaveworks operates a SaaS solution that operates the various open source projects it maintains. Of the open source tools, particularly notable in the deployment context is Flux which enables GitOps, Flagger which enables canary deployments. Scope which enables visualization of Kubernetes, and Cortex which enables monitoring.

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license