Configuring deployment details is a critical step to ensure services are deployed correctly, efficiently, and consistently. BuildPiper automates the entire CD configuration process — making deployments seamless, secure, compliant, faster, and free of human error.
A well-governed deployment configuration process improves the speed, reliability, and consistency of how services reach production. BuildPiper automates this end-to-end — covering Kubernetes manifest generation, resource policies, security context, scheduling, and lifecycle hooks — so platform teams can deploy confidently without writing or maintaining YAML by hand.
Compliant by Default
Generated manifests follow Kubernetes best practices for security, scalability, and reliability — reducing manual hardening work.
UI-Driven Configuration
Every Kubernetes setting — from probes to tolerations — is exposed through a guided UI, eliminating direct YAML editing for most teams.
BuildPiper provides two approaches for automating the deployment configuration process. Choose the one that aligns with how your team manages Kubernetes manifests today.
A BuildPiper Auto-Generated Manifests
By asking a few questions about your service deployment, BuildPiper generates a compliant, secure, scalable, and reliable service manifest which is utilized for service deployments. This is the recommended approach for most teams.
B Bring Your Own Manifest Files (BYOM)
If you already have Manifests or a Helm chart with a values file, provide the file or the Git URL and BuildPiper will use the same to automate deployments — no rewriting required.
Note: The rest of this page documents the Auto-Generated Manifest approach. For the BYOM workflow, refer to the dedicated BYOM documentation.
The Auto-Generated Manifest configuration is organised into 12 sections, each controlling a specific aspect of how the service runs on Kubernetes. Click any section to jump to its details.
Click any section below to jump directly to the configuration details. The first section, Deploy Details, defines core Kubernetes deployment identity, container settings, and replica scaling.
01 Deploy Details ▸
Service name, deployment name, container, image pull policy, replicas.
02 Access Type ▸
Public, Protected or Private ingress access levels and routing rules.
03 Resource Quota ▸
CPU, Memory, and GPU request and limit boundaries.
04 Configurations & Secrets ▸
Mount ConfigMaps, Secrets, and External Secret keys at chosen paths.
05 Mount Details ▸
Empty directory, host path, PVC binding, and custom entrypoint commands.
06 Env Variables ▸
Plain key/value, ConfigMap, Secret, or pod metadata field references.
07 Node & Service Affinity ▸
Required/preferred node affinity, service affinity and anti-affinity rules.
08 Security Context ▸
Pod-level and container-level security baseline and overrides.
09 Tolerations & Priorities ▸
Toleration of node taints and priority classes for eviction order.
10 Liveness & Readiness ▸
Self-healing restart checks and traffic-gating readiness probes.
11 Labels & Annotations ▸
Identification labels, selectors, and informational annotations.
12 Hooks Details ▸
Pre-deploy and post-deploy hook scripts via inline, file, or Git.
Core identity and scaling settings for the Kubernetes Deployment and Service resources.
Field Name
Field Type
Description / Requirement
Service Name*
Mandatory
Defines a unique service name used for service discovery. Acts as a permanent identity for your application since individual pods are frequently destroyed and recreated. Populates metadata.name in the Kubernetes Service manifest. Example: A backend named order-service can receive requests at http://order-service instead of tracking individual pod IPs.
Deployment Name*
Mandatory
Unique identifier for the Deployment resource within the namespace and prefix for the pods it manages. Populates metadata.name in the Kubernetes Deployment manifest. Example: A deployment named frontend-v2 auto-restarts a crashed pod to maintain the desired state.
Container Name*
Mandatory
A specific label assigned to the primary container in the pod. The container name is referred to later for monitoring purposes.
Select Image Pull Policy*
Mandatory
Determines when Kubernetes pulls the container image from the registry — balancing deployment speed against version consistency. Options: Always (pull every time), IfNotPresent (use cached if available), Never (only local image).
Desired Replica Count*
Mandatory
Number of Pod replicas the Deployment should maintain for high availability and load distribution. Example: If replicas = 3, traffic is distributed across 3 pods. If one crashes, Kubernetes auto-creates a replacement.
Custom Service Account
Non-Mandatory
A separate identity created for the Pod so it can securely access Kubernetes resources, instead of using the shared default identity. Useful when granular RBAC is required — e.g. creating an app-sa ServiceAccount with permission to only read specific secrets.
In BuildPiper, the Ingress access levels determine how your service is exposed to the network and who can reach it.
PUBLIC Public Access
For services that need to be reachable from the open internet — the standard choice for customer-facing applications.
How it works: Maps a public-facing Load Balancer (with a public IP) to the cluster’s Ingress controller. Anyone with the URL can attempt access.
PROTECTED Protected Access
A layer of restriction making the service reachable only to specific, authorised users.
How it works: May have a reachable endpoint but access is restricted via IP Whitelisting or mandatory OIDC/SSO authentication. Limited to employees, VPN users, or authorized partners.
PRIVATE Private Access
The most restrictive tier — the service is never accessible beyond the internal network.
How it works: Uses an Internal Load Balancer with a private IP from your VPC. DNS records usually only resolve within the private network. Accessible only from within the Kubernetes cluster.
Note: Refer to the Ingress documentation for detailed configuration of each access level.
Field Name
Field Type
Description / Requirement
Choose Access Level
Mandatory
Select Public, Protected, or Private (see cards above).
Service Port*
Mandatory
Specify the port on which the service will be accessible.
URL
Mandatory
The Host or Fully Qualified Domain Name (FQDN). Populates spec.rules[].host in the YAML, telling the Ingress controller to route traffic only when a request matches this specific domain (e.g. ot-payment-service.example.com).
Protocol
Pre-selected
Defines the network protocol used for the connection.
Exposed Path
Mandatory
The URL path (e.g. /api or /). Populates spec.rules[].http.paths[].path and lets the Ingress route traffic to different backend services based on the specific URI requested.
Target Port
Mandatory
The port where your application is actually listening inside the container.
Configure ephemeral and persistent storage mounts, plus container entrypoint overrides.
Field Name
Field Type
Description / Requirement
Empty Directory
Non-Mandatory
Mounts an empty directory inside the container. Commonly used when multiple containers in the same pod need to share files. Data is accessible to all containers that mount it and persists for the lifetime of the pod — once the pod is deleted, the data is removed.
Host Path
Non-Mandatory
Mounts a host path inside the container.
Bind PVCs
Non-Mandatory
Binds a Persistent Volume Claim (PVC) inside the container.
Custom Entrypoint CMD
Non-Mandatory
Execute a custom entrypoint command inside the container.
metadata.name # Pod name
metadata.namespace # Namespace
metadata.uid # Unique pod ID
spec.nodeName # Node where pod is running
status.podIP # Pod IP address
status.hostIP # Node IP
Allow pods to land on tainted nodes, and define which pods get evicted first when the cluster runs out of room.
Field Name
Field Type
Description / Requirement
Setup Tolerations
Non-Mandatory
Allow a Pod to be scheduled on a Node that has a Taint. Configure Key, Operator, Value, and Effect (e.g. NoSchedule means the pod won’t land there without a match).
Setup Priority
Non-Mandatory
Select pre-defined classes like system-cluster-critical or system-node-critical to ensure vital services never get stuck in a Pending state.
Toleration Example
A group of servers with high-cost NVMe storage is tainted with storage=premium. To ensure your Database Pod uses those fast disks, add a Toleration with Key = storage, Operator = Equal, Value = premium.
Priority Example
During a traffic spike, your cluster is at 100% capacity. Your Checkout Service (High Priority) needs to scale up. Kubernetes sees a Background Image Optimizer (Low Priority) and shuts it down to give CPU/Memory to Checkout immediately.
Note: BP loads default priority classes directly from Kubernetes. Custom priority classes must be applied directly to the cluster.
Configure the two probes that Kubernetes uses to detect crashed containers and route traffic only to ready pods.
LIVENESS Self-Healing Restart Probe
If this check fails, Kubernetes assumes the container has crashed or deadlocked and restarts it automatically. Example: Your app has a bug where it occasionally stops responding — the Liveness probe detects the silence and triggers a restart.
READINESS Traffic-Gating Probe
If this check fails, Kubernetes doesn’t kill the app — it simply stops sending traffic until the check passes. Example: The app is running but still downloading 500 MB of data — readiness stays Failed so users aren’t sent to an app that isn’t ready.
Identification tags and informational metadata attached to Kubernetes resources.
Field Name
Field Type
Description / Requirement
Labels (Key / Value)
Non-Mandatory
Identification tags used by Kubernetes to group and select Pods. Indexed and searchable. Example: env: prod or app: payment-gateway.
Label Selector (Key / Value)
Non-Mandatory
Search criteria defining which resources this deployment belongs to or which pods a service should send traffic to.
Annotations (Key / Value)
Non-Mandatory
Non-identifying info — “sticky notes” for external tools or humans. Used for build versions, contact info, or structured JSON that doesn’t affect scheduling.
