piped is a single binary component you run as an agent in your cluster, your local network to handle the deployment tasks.
It can be run inside a Kubernetes cluster by simply starting a Pod or a Deployment.
This component is designed to be stateless, so it can also be run in a single VM or even your local machine.
A centralized component managing deployment data and provides gPRC API for connecting
pipeds as well as all web-functionalities of PipeCD such as
authentication, showing deployment list/details, application list/details, delivery insights…
A project is a logical group of applications to be managed by a group of users.
Each project can have multiple
piped instances from different clouds or environments.
There are three types of project roles:
- Viewer has only permissions of viewing to deployment and application in the project.
- Editor has all viewer permissions, plus permissions for actions that modify state such as manually trigger/cancel the deployment.
- Admin has all editor permissions, plus permissions for managing project data, managing project
A collect of resources (containers, services, infrastructure components…) and configurations that are managed together.
PipeCD supports multiple kinds of applications such as
A deployment is a process that does transition from the current state (running state) to the desired state (specified state in Git) of a specific application. When the deployment is success, it means the running state is synced with the desired state specified in the target commit.
A yaml file that contains configuration data to define how to deploy the application.
Each application requires one application configuration file at application directory in the Git repository.
The default file name is
A directory in Git repository containing application configuration file and application manifests. Each application must have one application directory.
A list of stages specified by user in the application configuration file that tells
piped how the application should be deployed. If the pipeline is not specified, the application will be deployed by Quick Sync way.
A temporary middle state between current state and desired state of a deployment process.
There are 3 strategies that PipeCD supports while syncing your application state with its configuration stored in Git. Which are:
- Quick Sync: A fast way to make the running application state as same as its Git stored configuration. The generated pipeline contains only one predefined
- Pipeline Sync: Sync the running application state with its Git stored configuration through a pipeline defined in its application configuration.
- Auto Sync: Depends on your defined application configuration,
pipedwill decide the best way to sync your application state with its Git stored configuration.
Note: The previous name of this concept was Cloud Provider.
PipeCD supports multiple platforms and multiple kinds of applications. Platform Provider defines which platform, cloud and where application should be deployed to.
Currently, PipeCD is supporting these five platform providers:
An external product that provides metrics/logs to evaluate deployments, such as
CloudWatch and so on.
It is mainly used in the Automated deployment analysis context.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.