Shipwright

Shipwright is an open source framework for building container images on Kubernetes using custom resources and pluggable build strategies (container build automation).

• Kubernetes-native framework for defining and running container image builds (container build automation).
• Uses Custom Resource Definitions (CRDs) to model builds, build runs, and build strategies (Kubernetes extensibility).
• Supports pluggable build strategies to integrate different image build tools and workflows (CI/CD integration).
• Runs builds inside Kubernetes clusters, enabling build isolation and reuse of cluster resources (platform engineering).
• Integrates with cloud native ecosystems through CNCF hosting and alignment with Kubernetes APIs (cloud native tooling).

More About Shipwright

Shipwright is an open source project under the Cloud Native Computing Foundation (CNCF) that provides a Kubernetes-native framework for building container images (container build automation). It addresses the problem of how to define, execute, and manage image builds directly on Kubernetes clusters without relying on external build farms or tightly coupled Continuous Integration (CI) systems. By representing build workflows as Kubernetes resources, Shipwright aligns image creation with the same operational model used for deploying and managing workloads.

At its core, Shipwright exposes Custom Resource Definitions (CRDs) such as Build, BuildRun, and BuildStrategy (Kubernetes extensibility). A Build resource captures configuration such as source code location, image destination, and parameters for the build process. A BuildRun represents an invocation of a Build with execution status and logs. BuildStrategy and ClusterBuildStrategy define how to run particular build tools or pipelines, enabling reuse and governance of build patterns across namespaces and clusters.

Shipwright is designed to support pluggable build strategies, which allows operators to integrate different underlying build technologies (CI/CD integration). Each strategy defines the container images, steps, and environment needed to construct application images, while Shipwright coordinates execution within the cluster. This design enables the use of diverse tools while presenting a consistent Kubernetes Application Programming Interface (API) to developers and platform teams.

Enterprises typically deploy Shipwright into existing Kubernetes clusters to centralize container image builds alongside application workloads (platform engineering). Builds run as Kubernetes pods, which enables usage of cluster scheduling, resource quotas, isolation boundaries, and security policies such as network policies or pod security standards (cluster operations). This model supports scenarios where organizations need to keep builds within controlled environments, integrate with internal registries, and align image creation with cluster-level governance.

From an architectural perspective, Shipwright operates as a controller that observes and reconciles its CRDs, orchestrating build runs and updating status accordingly (Kubernetes controller pattern). It interoperates with container registries through standard container image push operations and leverages Kubernetes primitives such as service accounts, secrets, and config maps for credentials and configuration (infrastructure integration). Because it is hosted by CNCF, Shipwright is positioned within the cloud native ecosystem and is oriented toward interoperability with other Kubernetes-based Continuous Integration and Continuous Deployment (CI/CD) and platform tools.

In an enterprise directory, Shipwright fits into categories such as container build automation, Kubernetes-native CI/CD components, and platform engineering tooling. It is relevant for teams that want build-as-a-service capabilities within clusters, standardized build definitions as Kubernetes resources, and separation of responsibilities between developers defining builds and operators managing strategies, security, and resource policies.