helm-install

Install a helm chart

$ helm install [name] [repository_name]/[chart_name]

$ helm install [name] [path/to/source_directory]

$ helm install [package_name] [https://example.com/charts/packagename-1.2.3.tgz]

$ helm install [repository_name]/[chart_name] [[-g|--generate-name]]

$ helm install [name] [repository_name]/[chart_name] --dry-run

$ helm install [name] [repository_name]/[chart_name] --set [parameter1]=[value1],[parameter2]=[value2]

$ helm install [name] [repository_name]/[chart_name] [[-f|--values]] [path/to/values.yaml]

helm install [NAME] [CHART] [flags]

Examples:
helm install my-nginx stable/nginx-ingress
helm install --generate-name my-app-chart ./my-app-directory
helm install -f custom-values.yaml my-database oci://myregistry/charts/postgresql

[NAME]
    The name for the new release. If omitted and --generate-name is not used, Helm will prompt for a name. It must be unique within the namespace.

[CHART]
    The chart to install. This can be a path to a chart directory, a `.tgz` archive, a URL to a chart, or a reference to a chart in a repository (e.g., 'repo/chart-name').

--dry-run
    Simulate an install. Helm will render templates and show the output without actually deploying any resources to Kubernetes.

--debug
    Enable verbose output for debugging purposes, showing detailed information during the installation process.

--namespace <namespace>
    Target Kubernetes namespace to deploy resources into. Defaults to the current kubectl context's namespace.

--create-namespace
    If set, the target namespace will be created during the installation if it does not already exist.

--version <version>
    Specify the exact chart version to install when using charts from a repository.

--values <file>, -f <file>
    Specify one or more YAML files containing values to override chart defaults. Multiple files are merged in order.

--set <key=value>
    Set individual values on the command line. Can be specified multiple times for multiple values (e.g., `--set replicaCount=3,image.tag=latest`).

--set-string <key=value>
    Set string values on the command line. Ensures values are treated as strings, useful for values that might otherwise be parsed as numbers or booleans.

--generate-name
    Generate a random, unique name for the release if `NAME` is not provided. Useful for ephemeral deployments or testing.

--wait
    Wait until all Kubernetes resources associated with the release are in a ready state before marking the installation as successful.

--timeout <duration>
    The maximum time to wait for Kubernetes resources to be ready when `--wait` is enabled. Defaults to 5 minutes (5m0s).

--atomic
    If set, and the installation fails for any reason, the release will be automatically uninstalled to prevent partial deployments.

--skip-crds
    If set, Custom Resource Definitions (CRDs) included within the chart will not be installed or updated by Helm.

--repo <url>
    Specify the URL of the chart repository to use. This is an alternative to `helm repo add`.

The `helm install` command is fundamental for deploying applications packaged as Helm charts onto a Kubernetes cluster. A Helm chart is a collection of files that describe a related set of Kubernetes resources, representing a single application or a component of a larger one. When you execute `helm install`, Helm takes the specified chart (which can be a local path, a chart from a configured repository, or a direct URL), processes its templates with any provided custom values, and then sends the resulting Kubernetes resource definitions to the Kubernetes API server for creation. This operation creates a new "release" in Kubernetes, which Helm tracks internally. This tracking enables future lifecycle management operations such as upgrades, rollbacks, and uninstallation of the deployed application. It is the initial step in bringing an application to life using Helm's package management capabilities. Customization is a key feature, allowing users to override default chart values using various flags like `--set` or by providing a custom values file with `-f` or `--values`.

Successful `helm install` execution requires a properly configured Kubernetes context (typically managed via `kubectl`) with sufficient RBAC permissions in the target cluster and namespace to create and manage the necessary resources. It's crucial to thoroughly review the chart's documentation and values, especially for production environments, to understand its resource requirements and potential impact. If a release with the specified `NAME` already exists, `helm install` will fail unless the `--replace` flag is used. However, for idempotent deployments or updates, `helm upgrade --install` is generally preferred as it handles both initial installation and subsequent upgrades gracefully.

helm install is extensively used for deploying a wide range of applications and services on Kubernetes, including:
- Databases: PostgreSQL, MySQL, MongoDB.
- Message Queues: RabbitMQ, Apache Kafka.
- Web Servers/Proxies: Nginx, Apache HTTP Server.
- Monitoring Stacks: Prometheus, Grafana, Loki.
- CI/CD Tools: Jenkins, GitLab Runner.
- Custom Applications: Packaging and deploying your own proprietary applications consistently.

While `helm install` is specifically for initial deployments, for workflows that require an operation to either install a new release or update an existing one (i.e., be idempotent), it is often more robust to use the `helm upgrade --install` command. This command will perform an `install` if the release does not already exist, or an `upgrade` if it does, streamlining your deployment scripts and CI/CD pipelines.

Helm, widely recognized as the 'package manager for Kubernetes,' was initially developed by Deis (later acquired by Microsoft) and subsequently donated to the Cloud Native Computing Foundation (CNCF). The `helm install` command has always been a core part of its functionality. A pivotal architectural shift occurred with Helm v3, which saw the removal of the Tiller server-side component that was central to Helm v2. This change simplified the deployment process and significantly enhanced the security model by allowing `helm install` (and all other Helm commands) to interact directly with the Kubernetes API server, eliminating the need for a separate privileged Tiller deployment within the cluster.

helm upgrade(1), helm uninstall(1), helm list(1), helm rollback(1), kubectl(1)