PipeCD: A GitOps CD Platform That Trades CRDs for Pipeline Definitions
The One CD for All {applications, platforms, operations}. The tutorial shows how to run PipeCD locally for introduction.
At a glance
- What is it?
- PipeCD is a CNCF sandbox project that unifies deployment across Kubernetes, Terraform, AWS Lambda, and more. It avoids CRDs and manifest changes, but its local tutorial and multi-component architecture demand careful setup.
- Who is it for?
- Adopt PipeCD if you manage multiple application kinds across clouds and want a single GitOps pipeline interface without CRDs or manifest changes. Skip it if you need a mature, battle-tested CD tool with extensive community plugins, or if your team cannot commit to learning a new pipeline DSL and managing the control plane and agent components.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem PipeCD Solves
Most CD tools are built for one platform. You use Argo CD for Kubernetes, a separate tool for Lambda, and yet another for Terraform. PipeCD aims to replace that stack with one GitOps platform. The README states it provides a unified continuous delivery solution for multiple application kinds on multi-cloud. The target user is an engineering team that deploys to several clouds and wants a consistent interface. The README claims it works for small projects too, but the design emphasis is on managing thousands of cross-platform applications at company scale. This is not a tool for a single Kubernetes cluster with one team. It is for organizations that have heterogeneous infrastructure and want to reduce the number of deployment tools they maintain.
The Core Mechanism: Pipeline Definitions Instead of CRDs
PipeCD's key design choice is that it does not require CRDs or changes to your application manifests. Instead, you write a pipeline definition alongside your existing manifests. This definition describes the deployment stages. The README says the pipeline definition is simple, unified, and powerful. The control plane and the agent, called piped, execute the pipeline. The piped component runs inside your cluster or environment and holds no deployment credentials outside that cluster. The README emphasizes that no deployment credentials are exposed or required outside the application cluster. That is a security advantage over tools that store cloud credentials in a central server. The pipeline can include built-in deployment analysis, which measures impact based on metrics, logs, and emitted requests. This analysis is part of the pipeline, not an external add-on.
Running PipeCD Locally: The Tutorial Path
The README points to a separate tutorial repository for running PipeCD locally. The quickstart guide on the docs site shows how to set up components and deploy a hello-world application. The tutorial is for introduction, not production. You will need to run the control plane and at least one piped agent. The exact commands are not in the README, so you must follow the tutorial repository. The installation guide covers real-life environments. Given the multi-component architecture, local setup is not a single binary. You need a database, the control plane, and the piped agent. The tutorial likely uses Docker Compose or a similar orchestration. This is a barrier for someone who wants to evaluate the tool quickly. You cannot just download a binary and run it.
Supported Platforms and the CI Handoff
The README lists Kubernetes, Terraform, GCP Cloud Run, AWS Lambda, and AWS ECS as supported platforms. This is a broad range. Terraform support is notable because infrastructure deployment is not usually part of an application CD tool. The pipeline definition can include Terraform apply stages. The README also states that PipeCD is easy to interact with any CI. The CI tests and builds artifacts, and PipeCD takes the rest. This is a clean separation. But it means your CI must produce artifacts that PipeCD can deploy. There is no built-in build step. If your CI is not set up to produce the right artifacts, you must change it. The README does not describe the artifact format, so you need to check the documentation for each platform.
Insights and Delivery Metrics
PipeCD includes an insights feature that shows metrics like lead time, deployment frequency, MTTR, and change failure rate. These are DORA metrics. The README says these measure delivery performance. This is a differentiator. Most CD tools show deployment status but not aggregate metrics. The insights feature likely aggregates data from the control plane's deployment history. This is useful for teams that want to track improvement over time. However, the README does not explain how to export these metrics or integrate with external dashboards. If you already use a metrics platform, you may need to build that integration yourself. The metrics are only as good as the deployment data you feed in, so you must ensure all deployments go through PipeCD.
Limitations and Failure Modes
The most obvious limitation is the lack of CRD support. That is a feature, but it also means you cannot use Kubernetes custom resources to manage deployments. If your team is familiar with Argo CD's Application CRD, PipeCD's pipeline definition is a different model. The README does not mention any rollback mechanism beyond the pipeline stages. If a deployment fails, the pipeline may have a rollback stage, but that is not documented in the README. Another failure mode is the dependency on the piped agent. If the agent loses connectivity to the control plane, deployments may stall. The README does not describe high availability for piped. For a single cluster, this is fine. For multi-cloud, you need to run piped in each environment, which adds operational overhead. The README also does not mention any secrets management integration, so you must handle secrets outside PipeCD.
Alternatives and the Difference in Approach
The main alternative is Argo CD. Argo CD is Kubernetes-native and uses CRDs for application definitions. It has a large ecosystem and is a graduated CNCF project. PipeCD is a sandbox project, which means it is less mature. The difference is that Argo CD is Kubernetes-only, while PipeCD supports multiple platforms. If you only use Kubernetes, Argo CD is a safer choice because it is more established. Another alternative is Flux, which also uses CRDs and is Kubernetes-only. For multi-cloud, you might use Spinnaker, which is older and more complex. PipeCD's approach is to provide a unified pipeline DSL across platforms. The trade-off is that you learn one DSL instead of using a familiar Kubernetes-native resource. The README's claim of no manifest changes is a direct contrast to Argo CD, which often requires you to add annotations or labels to your manifests.
Maintenance, Upgrade, and License
PipeCD is licensed under Apache-2.0, which is permissive. The repository is active, with recent releases in 2026. The version numbers suggest a regular release cadence. The maintenance cost is on you. You must upgrade the control plane and each piped agent. The README does not describe an upgrade path. The project is a CNCF sandbox project, which means it is early-stage. The community is there, but it is not as large as Argo CD's. The ADOPTERS.md file lists public users, but the README does not mention any specific companies. You should check that file to see if there are adopters with a similar scale. The license allows commercial use without restrictions, but you should review the license text yourself. The project has a Code of Conduct and community meetings, which is a sign of a healthy governance model.
Editorial conclusion
Adopt PipeCD if you manage multiple application kinds across clouds and want a single GitOps pipeline interface without CRDs or manifest changes. Skip it if you need a mature, battle-tested CD tool with extensive community plugins, or if your team cannot commit to learning a new pipeline DSL and managing the control plane and agent components. Before adopting, verify that your target platforms (Kubernetes, Terraform, AWS Lambda, ECS, Cloud Run) are fully covered by the current release, test the local tutorial to understand the pipeline definition syntax, and check the ADOPTERS.md list for organizations with similar scale. Also confirm that your CI can hand off artifacts cleanly, since PipeCD expects CI to build and test while it handles deployment.
Community notes