{"dataset":{"id":"00000000-0000-0000-0000-000000000055","slug":"helm-best-practices","name":"Helm best practices","description":"Source-linked guidance on Helm fundamentals: releases, charts, templates, values files, and chart best practices. Scoped to Helm 3.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Chart best practices","sourceUrl":"https://helm.sh/docs/chart_best_practices/templates/","text":"Structure templates/ so each resource definition resides in its own file, named with dashed notation reflecting the resource kind, e.g. foo-pod.yaml; use .yaml for files producing YAML output and .tpl for those producing none. Defined templates are globally accessible to a chart and all of its subcharts, so defined template names should be namespaced, as in {{- define \"nginx.fullname\" }}; creating charts via helm create is highly recommended since template names are then automatically defined per this best practice. Indent with two spaces, never tabs, chomp whitespace where possible, and avoid adjacent blank lines. Use {{- /* */}} template comments for documentation; # YAML comments stay visible during helm install --debug but can introduce rendering errors on sections where functions like required need values. Scope: Helm. Reviewed October 4, 2026.","id":"helm-best-practices:Chart best practices","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Values files and overrides","sourceUrl":"https://helm.sh/docs/chart_template_guide/values_files/","text":"The Values built-in object provides access to values passed into the chart from multiple sources: the chart's values.yaml, a parent chart's values.yaml if this is a subchart, a values file passed to helm install or helm upgrade with the -f flag, and individual parameters passed with --set. Specificity increases in that order: values.yaml is the default, which a parent chart's values.yaml can override, then a user-supplied values file, then --set parameters. Values files are plain YAML. Access values as attributes of Values, e.g. {{ .Values.favoriteDrink }}; for structured content, nest keys like favorite: drink: coffee and reference them as {{ .Values.favorite.drink }}, though keeping values trees shallow is recommended. Overriding a key to null removes it from the merged values. Scope: Helm. Reviewed October 4, 2026.","id":"helm-best-practices:Values files and overrides","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Templates and built-in objects","sourceUrl":"https://helm.sh/docs/chart_template_guide/getting_started/","text":"Helm charts are structured with specific directories: `templates/` for template files, `values.yaml` for default values overridable during `helm install` or `helm upgrade`, `Chart.yaml` for descriptions accessible in templates, and `charts/` for subcharts. Helm sends all `templates/` files through a rendering engine, collecting results to send to Kubernetes. When authoring production-grade charts, retain starter files like `NOTES.txt` (help text displayed during installation), `deployment.yaml`, `service.yaml`, and `_helpers.tpl` (for reusable helpers). Template names need not follow rigid patterns, though using `.yaml` for YAML files and `.tpl` for helpers is recommended. Plain YAML files placed in the `templates/` directory are sent to Kubernetes as-is. ConfigMaps serve as basic resources for storing configuration data accessible by other objects like pods. Scope: Helm. Reviewed October 4, 2026.","id":"helm-best-practices:Templates and built-in objects","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Chart structure and Chart.yaml","sourceUrl":"https://helm.sh/docs/topics/charts/","text":"Organize charts as directories named after the chart, containing a required Chart.yaml file specifying mandatory apiVersion, name, and version fields. Include values.yaml for default configurations and templates/ for Kubernetes manifest generation. Reserve charts/, crds/, and templates/ directories, along with specified file names, as Helm will not alter other files. Optionally add LICENSE, README.md, values.schema.json, and templates/NOTES.txt. Define dependencies with name, version, and optional repository URLs or aliases, using condition paths for enabling/disabling and tags for grouping. Specify optional metadata like kubeVersion, description, type, keywords, home, sources, maintainers, and import-values. Package charts into versioned archives for deployment. Use helm pull chartrepo/chartname to download and inspect published charts without installation. This structure supports deploying simple pods or complex application stacks. Scope: Helm. Reviewed October 4, 2026.","id":"helm-best-practices:Chart structure and Chart.yaml","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Installing and managing releases","sourceUrl":"https://helm.sh/docs/intro/using_helm/","text":"Use `helm search repo` to locate charts in locally added repositories without network access, leveraging fuzzy string matching for partial phrase queries. Add repositories with `helm repo add [NAME] [URL]`; `helm search hub --list-repo-url` exposes the actual Helm repo URL, which standard `helm search hub` output does not. Install packages using `helm install [RELEASE_NAME] [CHART_NAME]`, which creates a new release object while the client prints which resources were created, the release state, and any additional configuration steps. Helm installs resources in a defined order, starting with Namespace, NetworkPolicy, ResourceQuota, LimitRange, PodSecurityPolicy, PodDisruptionBudget, ServiceAccount, Secret, SecretList, ConfigMap, StorageClass, and PersistentVolume. Scope: Helm. Reviewed October 4, 2026.","id":"helm-best-practices:Installing and managing releases","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}