PipeCD: One Control Plane Across Many Platforms

▶ Watch (0:02)

PipeCD is a GitOps-style progressive delivery platform targeting Kubernetes, Terraform, ECS, Lambda, and GCP Cloud Run from a single control plane. The system splits into two components: a central control plane that stores deployment data and serves a UI and RPC API, and a lightweight agent called piped. Piped ships as a single binary and runs anywhere, including a pod or an ECS task handler. The split separates platform-team concerns from developer-team concerns, making centralized CD across mixed platforms practical.

What Changed in v1: Plugins Replace Built-In Platform Code

▶ Watch (1:30)

Before v1, all platform-specific execution code lived inside the piped binary. V1 moves every platform and stage-execution code out of the core. Each platform now ships as a separate plugin, distributed independently, and loaded by the piped agent at runtime. The piped agent and its plugins communicate over gRPC. Users control which plugins to install and configure them inside the piped configuration file. The core binary stays small; platform support grows by adding plugins.

Simplified App Configuration with Plugin-Scoped Fields

▶ Watch (2:21)

The v0 app config required a platform-specific application kind field, such as KubernetesApp, and an input spec that had to accommodate every platform PipeCD supported. That made documentation hard to follow. In v1, the kind field is always Application, and platform config moves under a plugin-specific block. The scope is narrower, so each plugin documents only its own fields. Teams migrating from v0 can run a PipeCD CLI command that reformats existing config files automatically, with a migration guide linked via QR code in the talk.

Plugins Available Now and in Development

▶ Watch (3:43)

Most v0 stage executors already ship as v1 plugins: Kubernetes, Terraform, Cloud Run, and Ansible. ECS support is still in development. The new Kubernetes multi-cluster plugin, also in development, targets deploying a single application manifest to multiple clusters in one operation. It will release independently from the standard Kubernetes plugin. A guide for building custom piped plugins is in progress and will release shortly alongside updated v1 documentation.

Community Plugins Built on the Go SDK

▶ Watch (4:43)

The piped plugin SDK for Go reached v0.3.0. On top of that SDK, community-built plugins are already available: OpenTofu, SQL, Azure Functions, and Ansible. All community plugins live in the PipeCD community plugin repository. Contributors who want to build a new plugin can use the SDK and the repo as a starting point. The project holds bi-weekly meetings, and a booth at the pavilion the following morning offered a place to ask questions in person.

Notable Quotes

we just released the PICD v1 at unfa state and is adopt the plug-in architecture Khanh Tran · ▶ 01:33

The pipd and it plugin communicate via gpc protocol Khanh Tran · ▶ 02:03

The cumis multicluster plug-in is the new one uh is aimed to support deploying your application manifest to multiple cluster at once and will be released independently from the communities plug-in. Khanh Tran · ▶ 04:15

Key Takeaways

  • PipeCD v1 moves all platform code out of the piped binary into separate gRPC plugins.
  • A new Kubernetes multi-cluster plugin will deploy one manifest to multiple clusters simultaneously.
  • The Go plugin SDK at v0.3.0 already supports community plugins for OpenTofu, SQL, and Azure Functions.

About the Speaker(s)

Khanh Tran is a CNCF Ambassador and maintainer of the PipeCD project, an LFX mentor, an approver at Kubernetes sig-docs-localizations, and an organizer at Cloud Native Community Group Hanoi. He works as a software engineer at CyberAgent Inc., where he owns the CI/CD system across the organization and focuses on building developer platform tooling at scale.