-
Platform / DevOps engineers
-
Teams running multiple Kubernetes applications
-
Organizations looking for clean Helm architecture
-
Anyone tired of giant, unmaintainable Helm charts
-
Reduce YAML duplication and enforce consistent Kubernetes standards
-
Provide small, focused Helm library charts with clear responsibilities
-
Separate platform concerns from application logic
-
Favor explicit composition over hidden or implicit behavior
helm-platform/
├── common/ # Core library chart (mandatory)
├── service/ # Library chart for Kubernetes Services
├── ingress/ # Library chart for HTTP/HTTPS exposure
└── ...This project provides Helm library charts published as OCI artifacts on GitHub Container Registry (GHCR). They are designed to be consumed as dependencies by application charts.
- Adding a Dependency
To use a library chart (for example common), declare it in your application chart’s Chart.yaml:
dependencies:
- name: common
version: 0.2.5
repository: oci://ghcr.io/qireloFetching Dependencies
helm dependency updateUsing the Library Templates. Library charts expose reusable templates via define / include.
{{ include "common.deployment" . }}Rendering and Installing
helm template my-app .
helm install my-app .The example repository includes a complete example application demonstrating how to compose the library charts together.
Each chart is released independently using Git tags.
The release-chart.yaml workflow automatically packages and publishes a chart to the OCI registry when a release tag is pushed.
From the helm-platform repository root:
- Create a release tag
git tag <chart-name>-v<version>Example
git tag common-v0.1.0Where:
<chart-name> is the chart directory name (e.g. common)
<version> is the chart version to release (e.g. 0.1.0)- Push the tag
git push origin <chart-name>-v<version> Example
git push origin common-v0.1.0Made with ❤️ and open source.

