Loading...

About the Helm Chart Starter Kit

Helm's own helm create scaffold is generic by design — every team then spends a day adding the same production necessities: resource limits, probes, security contexts, HPA and PDB templates, and values wiring. This starter kit generates a chart with those decisions already made, structured the way production charts end up anyway.

The generated chart follows the conventions that make charts maintainable: everything configurable through values.yaml with sane defaults, helpers for names and labels in _helpers.tpl, and optional resources (Ingress, HPA, PDB) gated behind enabled flags.

Frequently asked questions

What should a production-ready chart include that helm create doesn't emphasize?

Resource requests and limits (unset means no QoS guarantees), liveness/readiness probes wired to real endpoints, a securityContext (runAsNonRoot, readOnlyRootFilesystem where possible), a PodDisruptionBudget so voluntary evictions can't take out all replicas, and image pinning by tag or digest — never :latest as the default value.

How should values.yaml be structured?

Mirror the resource hierarchy (image.repository, image.tag, resources.requests.cpu), give every value a working default, and gate optional features behind enabled booleans (ingress.enabled, autoscaling.enabled). Document each value with a comment — values.yaml is your chart's public API, and breaking its shape breaks every consumer's overrides.

When is a Helm chart the wrong tool?

When you control both the chart and its only consumer, plain manifests with Kustomize overlays are simpler — Helm earns its templating complexity when you need multi-environment value variation, distribution to other teams, or release lifecycle management (rollbacks, hooks). Many platforms run both: Helm for third-party software, Kustomize for first-party apps.

Need this managed for you, not just automated?

We're also a hands-on DevOps consultancy — Kubernetes, CI/CD, and cloud infrastructure.

Explore Our Services