BP facilitates seamless onboarding of existing clusters — EKS, GKE, AKS, or on-premises — allowing you to manage and deploy workloads directly from the platform.

Platform teams can manage Namespaces, Ingress, Gateways, ConfigMaps, and Secrets without writing complex YAML. BP handles automated generation and versioning of these manifests.

A centralised Kubernetes Dashboard offers real-time telemetry into pod health, node utilisation, container logs, and event streams — eliminating the need for direct kubectl access.

BP facilitates Rolling and Canary deployments reinforced by automated Rollout Validation and mandatory client approval gates to align technical execution with business sign-off.

Check if Required RBAC Permissions are available and configured for BuildPiper to access the cluster.

Static Kubernetes Credentials Generation must be completed to ensure stable, non-interactive connectivity between BP and the cluster API server.

Network policy deletion is required in case of Google Cloud (GKE) to prevent BP from being blocked from communicating with the cluster.

A granular status indicator for essential cluster components, including etcd, CoreDNS, and Controller Manager, verifying the operational integrity of the cluster’s core planes.

Display of the control plane version (e.g., v1.28.x) as reported by the Kubernetes API server.

Real-time graphs displaying aggregate CPU and Memory (RAM) consumption across the entire cluster, calculated as a percentage of total allocatable resources.

A summarised view of the node pool, detailing the count of worker nodes and their operation state (Healthy / Unhealthy).

A total count of namespaces present in the cluster, reflecting the logical segmentation of the environment.

BP provides a comprehensive, real-time view of all nodes in your cluster, clearly indicating whether each node is in a Ready or Not Ready state. BP offers a read-only view in this section.

A centralised view of all namespaces including operational status (Active, Terminating, or Failed), configured resource quotas, and current CPU and memory usage per namespace.

A comprehensive map of the cluster’s workload identifying the specific Namespace and Node where each pod is scheduled, alongside active Labels, current Status, and Execution Duration.

Create a new Kubernetes namespace directly within BuildPiper. Upon creation, the namespace is automatically onboarded into the platform and immediately available for use in applications and environments.

For namespaces that already exist on the target Kubernetes cluster, BP supports discovery and onboarding into the platform while retaining existing CPU and memory resource limit configurations.

BP provides a centralised inventory view of all namespaces present on the onboarded Kubernetes cluster, regardless of whether they were created natively or through BP.

Registry URL: your-registry-name.azurecr.io

Username: Admin username or Service Principal ID

Password: Access Key or Secret corresponding to the username/Service Principal

Registry URL: https://nexus.buildpiper.com

Username: Nexus account with view and push permissions

Password: Corresponding password or user token

Registry URL: registry.cn-hangzhou.aliyuncs.com

Access Key: AccessKey ID from Alibaba Cloud RAM user credentials

Region: Alibaba Cloud region ID (e.g., cn-hangzhou)

Registry URL: ghcr.io

Username: GitHub username or Organization name

Password: Personal Access Token (PAT) with packages scopes

Registry URL: https://us-central1-docker.pkg.dev

Username: _json_key

JSON Key: Paste full content of Service Account JSON key file

Registry URL: https://index.docker.io/v1/

Username: Docker Hub ID (not email)

Password: Docker Hub password or Personal Access Token (PAT)

Cloud-based and self-hosted Bitbucket repositories supported.

Cloud-based and self-hosted GitHub repositories supported.

Cloud-based and self-hosted GitLab repositories supported.

Git URL, Branch, Build Context, and Dockerfile Path. The build context is the directory Docker uses during the build — typically the root of your repo.

Clone from external source (Git submodules), Select Platform (AMD/ARM multi-arch), Shallow Cloning for optimised performance, Provenance Attestations for image build proof.

Build Env Details (key-value pairs for runtime configuration) and Build Labels (custom metadata/labels added to the generated image).

Pre-hooks and Post-hooks to execute custom scripts before or after the build. Available via Command, File Upload, or Git source.

By asking a few questions about your service deployment, BuildPiper generates a compliant, secure, scalable, and reliable service manifest which is utilised for service deployments.

If you already have Manifests or a Helm and values file, you can provide the file or the Git URL and BuildPiper will use the same to automate deployments.

Service Name, Deployment Name, Container Name, Image Pull Policy, Desired Replica Count, Custom Service Account.

Public (internet-facing), Protected (IP whitelist/OIDC), Private (internal VPC only). Service Port, URL, Protocol, ExposedPath, Target Port.

Request Memory/CPU (minimum guaranteed), Limit Memory/CPU (maximum ceiling), optional GPU quota specification.

Config Map, Secret Map, External Secret Key — all mountable on a path or sub-path.

Liveness: Self-healing — restarts crashed containers. Readiness: Traffic controller — stops sending traffic until the app is ready.

Node Affinity Required/Preferred, Service Affinity (co-locate pods), Service Anti-Affinity (spread pods across nodes).

Pod-level: Run As User/Group, FS Group. Container-level: ReadOnly Root Filesystem, Allow Privilege Escalation, Linux Capabilities (add/drop).

Tolerations allow pods to schedule on tainted nodes. Priorities determine which pods are evicted first when the cluster is under resource pressure.

Provides instantaneous visibility into the deployment process and granular pod details, ensuring teams can monitor the health of their services as they go live.

Centralises Kubernetes events and pod logs within the UI, allowing users to gain immediate insights into application performance and quickly identify underlying issues.

Features a critical browser-based SSH capability that enables engineers to exec into pods directly from the BP interface for advanced, real-time troubleshooting.

Empowers users to manage workloads dynamically by scaling pods directly from the UI, without manual CLI intervention.

Offers full access to deployment and pod YAMLs, providing a clear view of the underlying specifications and ensuring configuration consistency.

Major divisions in a pipeline that define when and how to run. Supports Manual Approvals, Conditional Execution. If all jobs in a stage succeed, the pipeline moves to the next stage; if they fail, the pipeline is suspended.

A series of steps that run sequentially as a unit. The smallest unit of work that can be scheduled to run within a pipeline. Jobs define what to run (e.g., code compilation, test runs).