> ## Documentation Index > Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Helm Introduction > Introduction to Helm, a Kubernetes package manager that packages, templates, installs, upgrades, and manages complex multi-resource applications as single releases. Let's start by understanding what Helm is and why it matters for Kubernetes deployments. Kubernetes is excellent at running and scaling containerized applications, but humans often struggle with the complexity of the manifests required to deploy a complete application. A typical application deployed to a cluster is not a single object but a set of interconnected Kubernetes resources that must be created and configured correctly. Common resources for a typical web application (for example, WordPress) include: * A Deployment (or StatefulSet for databases) for Pods that run MySQL or the web server * A PersistentVolume (PV) and PersistentVolumeClaim (PVC) to persist database data * A Service to expose the web server * A Secret to store credentials (e.g., admin passwords) * Additional objects such as CronJobs for backups, Jobs, ConfigMaps, Ingress, etc. Managing each of these objects as separate YAML files means running multiple `kubectl apply` commands and manually editing many manifests whenever defaults or configuration values change. That process becomes error-prone and difficult to scale as the application evolves. Here is an example of multiple Kubernetes manifests concatenated in a single file (three documents separated by `---`). This shows the many pieces an application may require: ```yaml theme={null} # PersistentVolume apiVersion: v1 kind: PersistentVolume metadata: name: pv0003 labels: app: wordpress spec: capacity: storage: 20Gi volumeMode: Filesystem accessModes: - ReadWriteOnce hostPath: path: /mnt/data --- # PersistentVolumeClaim apiVersion: v1 kind: PersistentVolumeClaim metadata: name: wp-pv-claim labels: app: wordpress spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi --- # Deployment (simplified) apiVersion: apps/v1 kind: Deployment metadata: name: wordpress-mysql labels: app: wordpress spec: selector: matchLabels: app: wordpress tier: mysql strategy: type: Recreate template: metadata: labels: app: wordpress tier: mysql spec: containers: - name: mysql image: mysql:5.6 env: - name: MYSQL_ROOT_PASSWORD valueFrom: secretKeyRef: name: mysql-secret key: root-password ``` You can see how many different pieces must be created and configured correctly. Trying to manage all of this by hand quickly leads to duplication, fragile upgrades, and tricky cleanup when you want to remove the application. Enter Helm. Kubernetes does not natively model an entire application as a single unit — it knows only about the individual objects you declare. Helm changes that by packaging related Kubernetes manifests into a single deployable unit called a chart. Helm is widely described as a package manager for Kubernetes because it: * Packages all manifests needed for an application into a chart * Supports templating so you can provide values to customize the chart for different environments * Manages releases and revisions so you can upgrade or roll back an application reliably * Installs and uninstalls all objects that belong to a release with a single command Think of a Helm chart like a game installer: instead of copying dozens of files one-by-one, you run a single command that places everything in the right place and records what was installed. Installing an application with Helm is a single command: ```bash theme={null} $ helm install wordpress ``` Note: In practice `helm install` generally expects both a release name and a chart, for example: ```bash theme={null} $ helm install ``` You can supply custom values via a `values.yaml` file or with `--set` on the command line. Helm renders templates using those values and submits the rendered manifests to Kubernetes. Helm keeps track of release history. When you upgrade a release, Helm computes the diff between the current and desired states and applies the minimal changes necessary to the cluster. It stores revisions so you can roll back to a previous release if needed. Uninstalling a release with `helm uninstall` removes the objects that belong to that release, although you may need to manually clean up some cluster-level resources (or volumes with `reclaimPolicy: Retain`) afterward. Common Helm operations ```bash theme={null} # Install a chart (create a new release) $ helm install # Upgrade an existing release with a new chart or values $ helm upgrade [flags] # Roll back to a previous revision of a release $ helm rollback # Uninstall (delete) a release and its objects $ helm uninstall ``` Quick reference — Kubernetes objects vs. typical use | Resource Type | Use Case | | - | - | | Pod / Deployment / StatefulSet | Run application containers; StatefulSet for stable network IDs and persistent storage for databases | | PersistentVolume (PV) / PersistentVolumeClaim (PVC) | Persistent storage for stateful apps | | Service | Expose Pods within the cluster or as a load-balanced endpoint | | Secret | Store sensitive data such as passwords or API keys | | ConfigMap | Store non-sensitive configuration data | | Ingress | Control external HTTP(S) access to Services | | CronJob / Job | Scheduled or one-off tasks (backups, migrations) | Helm treats a related set of Kubernetes objects as a single release. It handles templating, installs, upgrades, rollbacks, and uninstalls so you can manage an application as a unit instead of micromanaging each file. Why use Helm? * Simplifies deployment and lifecycle management of complex applications * Enables reusable charts you can publish and share * Allows environment-specific customization via `values.yaml` or CLI overrides * Provides release history and safe rollbacks Next topics to explore * Chart structure (Chart.yaml, templates/, values.yaml) * Helm templating language and functions * Best practices for writing and sharing charts * Helm release lifecycle and debugging upgrades/rollbacks Links and references * Helm documentation: [https://helm.sh/docs/](https://helm.sh/docs/) * Kubernetes documentation: [https://kubernetes.io/docs/](https://kubernetes.io/docs/) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.