PipeCD is an Apache-2.0 licensed, CNCF Sandbox GitOps continuous delivery platform written in Go that gives teams one consistent deployment and operations experience across Kubernetes, Terraform, GCP Cloud Run, AWS Lambda and AWS ECS.

What it is

PipeCD is a GitOps-style continuous delivery platform that unifies deployment and operations for applications of many kinds across multiple clouds. It lives in the cloud-native ecosystem, carries CNCF Sandbox status, and is written in Go under the Apache-2.0 licence. Its stated goal is a single deployment interface for every platform a team runs, so engineers do not learn a different delivery mechanism per runtime. Deployment operations are driven by pull request on Git: the desired state lives in a repository, and PipeCD reconciles the cluster toward it.

The concrete problem it solves is tool sprawl and credential exposure in delivery pipelines. It replaces the practice of stitching together one delivery tool per platform and per cloud, where each tool demands its own manifest conventions, its own deployment credentials, and its own pipeline syntax. PipeCD requires no CRD and no changes to application manifests; a pipeline definition is added alongside the existing manifests. Deployment credentials are never exposed or required outside the application cluster. Continuous integration keeps its job of testing and building artifacts, and PipeCD takes the rest.

Key capabilities

• Unified pipeline definition that constructs deployment pipelines for Kubernetes, Terraform, GCP Cloud Run, AWS Lambda and AWS ECS from the same interface.
• No CRD and no manifest rewrites: existing application manifests stay as they are, with only a pipeline definition added.
• Credential isolation, where deployment credentials are not exposed or required outside the application cluster.
• Built-in deployment analysis as a pipeline stage, measuring impact from metrics, logs and emitted requests.
• CI-agnostic integration: any CI tests and builds the artifacts, and PipeCD handles the deployment.
• Insights reporting metrics including lead time, deployment frequency, MTTR and change failure rate.
• Rollback behavior shown in the project documentation, with a rolled-back deployment illustrated on the project site.

Who uses it and how

• Platform and operations teams running cross-platform workloads, where the same delivery workflow covers Kubernetes alongside Terraform, Cloud Run, Lambda or ECS.
• Organizations at company scale: the project is designed to manage thousands of cross-platform applications in multi-cloud, while still working for small projects.
• GitOps teams that want deployment changes reviewed as pull requests rather than executed through ad-hoc commands.
• Delivery organizations that want to measure delivery performance through lead time, deployment frequency, MTTR and change failure rate.
• Teams with an existing CI investment, which keeps its build and test role while PipeCD owns the release step.

Getting started

The quickstart guide at pipecd.dev/docs/quickstart/ sets up PipeCD components and deploys a hello-world application for testing purposes, while the installation guide at pipecd.dev/docs/installation/ covers a real-life environment and the pipe-cd/tutorial repository shows how to run PipeCD locally; a hosted playground is also offered for trying it.

How it compares

No list of paid products that this project replaces is provided in the available facts, and no comparable tools are named either, so PipeCD stands alone in this registry. The only competitive axis the facts support is licence and deployment model: it is Apache-2.0 and self-hosted, with CNCF Sandbox governance rather than a vendor-controlled product.

When to use it — and when not to

A self-hoster must stand up and operate the PipeCD components described in the installation guide, so teams without the appetite to run and maintain that delivery infrastructure should not pick it. The project carries 235 open issues and the README excerpt is high-level, providing no explicit release cadence or detailed operational prerequisites such as database or storage requirements, so anyone needing documented guarantees before adopting should verify those details in the documentation first.