What is new in pipedv1 (plugin-arch piped)

By Khanh Tran (@khanhtc1202) | Tuesday, September 02, 2025

Tags:

Since the alpha release from Jun 2025, plugin-arch piped (aka. pipedv1) is closer to first offical release, we are working on v1.0.0-rc0 and will be released in the coming days.

In this article I would like to share some improvements that have been fixed in the new version pipedv1 compared to its predecessor piped.

Overview

While developing pipedv1, we always considered ensuring backward compatibility, meaning that the features available in piped will be mostly preserved in pipedv1. This ensures seamlessness between using piped and pipedv1, reducing the risk of problems when switching to pipedv1.

Changes in pipedv1 are of 2 types:

Performance improvements or addressing some features requested in pipedv0 but could not be met due to technical reasons.
Removal of some features that are obsolete or no longer prioritized

Fundamental changes like pipedv1 being able to support different platforms and making build pipeline deployment more powerful by turning stage executors into plugins have been described in this blog. This post will focus on smaller changes related to the actual usage of pipecd.

New in pipedv1

`plugins` configurations

From pipedv1, plugin binaries will be the real executor that perform pipeline’s stages execution. Plugin configuration is placed in 2 locations: piped config and application config.

The piped config is where basic plugin configurations are stored, such as where to load the plugin binary or some configurations that can be shared between applications.

apiVersion: pipecd.dev/v1beta1
kind: Piped
spec:
  projectID: dev
  pipedID: xxx
  ...
  plugins:
    - name: kubernetes
      port: 7001
      url: https://github.com/pipe-cd/pipecd/releases/download/link-to-plugin
      deployTargets:
        - name: local
          config:
            kubectlVersion: 1.32.4
        - name: remote
          config:
            kubectlVersion: 1.33.0
    - name: wait
      port: 7002
      url: https://github.com/pipe-cd/pipecd/releases/download/link-to-plugin

NOTE: platformProviders and cloudProviders in piped config will not be available in pipedv1 config. Instead, the deployTargets configuration in plugin config will determine where to deploy your application resources.

Meanwhile, the application config is where plugin configurations are stored specifically for the deployment of that application.

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  labels:
    env: local
  planner:
    alwaysUsePipeline: true
  pipeline:
    - name: K8S-SYNC
  plugins:
    kubernetes:
      input:
        kubectlVersion: 1.33.0
      quickSync:
        prune: true

Pipedv1 automatically identifies plugins based on the stage defined in the pipeline configuration. Which means below application config is valid as well

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  labels:
    env: local
  pipeline:
    - name: K8S-SYNC

For applications config without a pipeline definition, plugins config is required to help piped infer the plugin needed while performing deployment

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-k8s-app
  labels:
    env: local
  plugins:
    kubernetes:

NOTE: kind: XXXApp is deprecated in pipedv1, kind: Application will be used for all applications in app configuration file for pipedv1 managed application.

Migrating application configs to the new format will be covered in detail in another blog. You can learn more about the migration flow for now please check out the migration issue.

Pipeline planning and configuration

Creating pipelines based on different deployment strategies for various specific applications is a strong point that makes PipeCD stand out. With pipedv1, this feature is further enhanced by solving some old limitations in the current piped.

Since pipedv1, you can create a pipeline consisting of only one SYNC stage.

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  pipeline:
    stages:
      - name: K8S_SYNC
        with:
          ...

Or optionally, create a pipeline that includes the SYNC stage combined with other common stages, for example.

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  pipeline:
    stages:
      - name: WAIT
        with:
          duration: 30s
      - name: K8S_SYNC
      - name: WAIT
        with:
          duration: 30s

Stages configurations

Regarding stages (units of the pipecd pipeline), a feature that has been requested by many users is skipOn, which allows skipping a stage in the application deployment pipeline under certain conditions.

In the current version of piped, skipOn is only supported in limited ways for some stages (like Analysis Stage - ref: docs), in pipedv1, all stages support this feature.

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  pipeline:
    stages:
      - name: WAIT
        skipOn:
          paths:
          - '*/canary'
        with:
          duration: 30s

An unstable feature in piped is stage timeout, in pipedv1 version, all stages also support timeout settings. The default stage timeout will be 6 hours.

apiVersion: pipecd.dev/v1beta1
kind: Application
spec:
  name: test-app
  pipeline:
    stages:
      - name: WAIT_APPROVAL
        timeout: 1h # Default is 6h
        with:
          approvers:
          - khanhtc1202

Deprecated / Dis-supported features

“Weird” flag `--enable-default-kubernetes-cloud-provider` in piped execution

A long-time “weird” flag for piped binary execution if you don’t use PipeCD for a Kubernetes application is --enable-default-kubernetes-cloud-provider, which is basically legacy due to the first implementation of PipeCD focusing on supporting only Kubernetes. The default value is false, but if you set that flag to true, piped execution requires connecting to the Kubernetes cluster even before any application deployment is actually triggered.

In pipedv1, nothing like that flag exists in piped execution because pipedv1 supports whatever platform its plugins support equally.

Kubernetes templating feature

Related to Kubernetes support features of PipeCD. Currently, piped supports the Helm Git Remote Chart feature (ref piped config helm chart repository), which pulls the chart file stored directly on Git to the local and builds/templates as for a Local Chart.

With the emergence and standardization of OCI, storing and sharing Helm Charts has become easier via the Helm registry. Therefore, in pipedv1, we decided to stop supporting this feature.

Analysis stage query templating feature

Current piped support building queries used while evaluating metrics with deployment-specific data to be embedded in the analysis template (ref: analysis templating docs).

From pipedv1, along with built-in and custom args are supported with placeholders as {{ .App }} and {{ .AppCustomArgs }} respectively.

Kubernetes-specific built-in args like {{ .K8s.Namespace }} will be marked as deprecated and unsupported after several releases. The corresponding usage for the Kubernetes Namespace use case is changed to {{ .AppCustomArgs.k8sNamespace }}.

Summary

Here are some changes you might notice when switching to pipedv1. We ensure a certain level of backward compatibility between piped and pipedv1. The improvements are all aimed at making pipedv1 support more platforms and making it easier to build pipelines based on plugins.

The official documentation for pipedv1 is still being prepared, and the experimental release of pipedv1 will be available on the official pipecd repo release tab, along with some built-in plugins in the next few days.

Thanks for your attention, cheer 🍻

←Previous