PipeCD: a GitOps delivery platform for Kubernetes, Terraform, Lambda and ECS

The problem PipeCD addresses: one delivery model for unlike platforms

Most delivery tooling is built around one target. A Kubernetes controller reconciles manifests against a cluster. A script wraps a cloud provider CLI. A Terraform runner applies a plan. Each of those has its own notion of what a deployment is, its own status output and its own rollback story, so a team that ships to Kubernetes and to AWS Lambda ends up maintaining two mental models and two dashboards.

PipeCD's answer is to define the deployment as a pipeline and keep the target platform behind that definition. The README states the project provides "a unified continuous delivery solution for multiple application kinds on multi-cloud" and that the same deployment interface covers Kubernetes, Terraform, GCP Cloud Run, AWS Lambda and AWS ECS. The audience is therefore an organisation with more than one of those in production, or one that expects to add a second without retraining everyone.

The README also makes a claim worth reading carefully: "No CRD or applications' manifest changes are required; Only need a pipeline definition along with your application manifests." That matters if your manifests are shared with other tooling and you do not want a controller's custom resources written into them. The cost of that choice is that the pipeline definition is a separate artifact you now own and review.

How a PipeCD deployment pipeline is structured and where credentials live

The control plane and the execution agent are separate processes. The control plane holds the application and deployment records, reads the Git repository, and exposes the web interface. The agent, called piped, runs where the applications run and performs the actual apply. The README puts the boundary plainly: "No deployment credentials are exposed or required outside the application cluster." The control plane therefore does not need your cloud keys or your cluster's kubeconfig.

A deployment is a pipeline definition plus the application manifests, both in Git. A pull request changes the desired state, and the README describes the workflow as "doing deployment operations by pull request on Git." The pipeline stages are declared rather than inferred, which is why the project calls the definition "Simple, unified and easy to use but powerful."

One stage type is not just a wrapper around a deploy command. The README describes "Built-in deployment analysis as part of the deployment pipeline to measure impact based on metrics, logs, emitted requests." That means a pipeline can pause and evaluate whether the new version is behaving, rather than treating a successful apply as success. The project also reports delivery metrics: "lead time, deployment frequency, MTTR and change failure rate."

The integration boundary with CI is deliberate. The README says "The CI tests and builds artifacts, PipeCD takes the rest," so PipeCD does not replace your build system. It starts from the point where an artifact exists.

Installing PipeCD and running the local tutorial

The README does not carry install commands. It points at three separate resources, and they serve different purposes. The quickstart guide at pipecd.dev/docs/quickstart/ sets up the components and deploys a hello-world application for testing. The installation guide at pipecd.dev/docs/installation/ is for a real environment. The tutorial, in the separate repository pipe-cd/tutorial, is the one the README describes as showing "how to run PipeCD locally for introduction."

Start by cloning that tutorial repository, since the local walkthrough lives there and not in the main tree:

git clone https://github.com/pipe-cd/tutorial.git
cd tutorial

The main repository is a Go module, so building from source is a Go toolchain operation. The module declares Go 1.26.2, and the Makefile groups its targets by action prefix, with build, check, test, run, up and down among the documented actions. To see what is available before running anything:

make help

The Makefile states that help prints the available targets with their descriptions, which is the reliable way to find the target names rather than guessing them.

The local environment targets are the ones to look at first. The Makefile comments describe up as preparing the local environment (registry, kind cluster) and down as shutting it down, and the repository has a local/ directory alongside quickstart/ and manifests/. A first real use is to bring up that environment, then follow the tutorial's hello-world application through a deployment and watch the pipeline stages in the web interface. The repository also ships examples/ with v0/ and v1/ subdirectories and a .pipe/ directory, which is where the pipeline definitions for the sample applications live.

The web/ directory holds the front end, so the interface is part of this repository rather than a hosted service. Nothing in the README suggests a managed offering; you run the components yourself.

What PipeCD asks of you in return

The honest trade-off is operational surface. PipeCD is a control plane plus at least one agent plus a web front end, and the README's own claim is that it is "Designed to manage thousands of cross-platform applications in multi-cloud for company scale." That design point is also the reason a single small service pays more than it gets: you are running a distributed system to deploy one container image.

The plugin structure visible in the repository reinforces this. The release list includes a separately versioned Kubernetes plugin, pkg/app/pipedv1/plugin/kubernetes/v0.4.0, and the search terms around the project include pipecd plugin and pipecd v1. A separately versioned plugin means the platform integration has its own release cadence, and you should expect to track it alongside the main version rather than assume it moves in lockstep.

The README is also silent on a few things a person evaluating it will want. It does not document rollback behaviour, it does not describe what happens to an in-flight deployment when the control plane is unavailable, and it does not state the resource footprint of the control plane. Those are questions for the installation guide and the docs site, not for the README. If you need a tool whose failure modes are documented in the front page of the repository, this is not that.

Where it is clearly the wrong tool: a team that deploys only to Kubernetes and is content with a controller that reconciles manifests from Git. PipeCD's distinguishing features are the cross-platform interface and the analysis stage. Without a second platform and without a reason to gate on metrics, you are adopting the control plane for nothing.

PipeCD compared with Argo CD

The comparison people search for is PipeCD vs Argo CD, and the difference is not feature count but where the abstraction sits. Argo CD is a Kubernetes controller. Its unit of work is an Application pointing at manifests, it reconciles continuously against a cluster, and its state lives in custom resources inside that cluster. That is a good fit when Kubernetes is the only target, because the tool disappears into the platform you already run.

PipeCD inverts this. Its unit of work is a deployment pipeline, the target platform is a detail behind it, and the control plane sits outside the application cluster. That is why the README can say no CRD or manifest changes are required: nothing is being registered with the Kubernetes API to represent the application. The same pipeline shape is then reused for Terraform, Cloud Run, Lambda and ECS, which a Kubernetes controller cannot do because it has no concept of those targets.

The practical consequence runs both ways. If you already run Argo CD and add a Lambda function, you either add a second tool or move the Lambda into PipeCD and now run both. If you start with PipeCD, you get one interface but you own a control plane that Argo CD users get from the cluster they already have. Neither is wrong; they optimise for different first constraints.

Maintenance, licensing and what to check before committing

PipeCD is not archived, and the last push to the default branch was on 2026-08-23, the same date as the v0.58.0 release. Recent release history shows a steady cadence: v0.57.0 on 2026-06-25, the Kubernetes plugin at v0.4.0 on 2026-08-14, and v0.58.0 on 2026-08-23. The project describes itself as a Cloud Native Computing Foundation Sandbox project, and the README points to CNCF Slack, GitHub Issues and Discussions, and a recurring community meeting as the support channels. There is no commercial support commitment stated in the README.

The licence is Apache-2.0, which is a permissive licence that generally allows commercial use, modification and redistribution with the usual conditions around notices and attribution. The repository carries a NOTICE.txt and the README notes that the Linux Foundation has registered trademarks. This is a description of what the repository states, not legal advice; if you are embedding PipeCD in a product, have your own counsel read the LICENSE and NOTICE.txt files.

The upgrade cost is the part to price before you commit. A control plane that reads Git and an agent that applies changes are two things to keep in version agreement, and the separately versioned Kubernetes plugin adds a third. The RELEASES.md and RELEASE files in the repository root are where the project records its release process, and they are the right place to check what a version bump involves. Verify three things first: which platforms you actually deploy to, whether the plugin for each of them is at a version you are willing to run, and whether your team will operate the control plane or expect someone else to.

Editorial conclusion

PipeCD fits teams that already run several deployment targets and want one pipeline definition, one interface and one place to read deployment metrics, with credentials kept inside the target cluster. It is a poor fit if you only run Kubernetes and are happy with a CRD-based tool, because PipeCD asks you to operate a control plane and a piped agent for a benefit you would not use. Before adopting it, read the installation guide and the tutorial repository, then confirm which of the supported platforms you actually deploy to, since the pipeline definition and the plugin set differ per platform.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes