Syntax: helm create <chart-name>

Description: Creates a new Helm chart with the specified name. This command generates a chart directory with a standard structure including default templates, values.yaml, and Chart.yaml.

• Creates a new chart directory with a standard structure
• Includes default templates, values.yaml, and Chart.yaml
• Provides a starting point that follows Helm best practices

• You can customize the generated files to match your application needs

  # Create a new chart named 'myapp'
  helm create myapp
  
  # View the generated structure
  tree myapp
  
  # Output shows:
  # myapp/
  # ├── Chart.yaml
  # ├── values.yaml
  # ├── charts/
  # └── templates/
  #     ├── NOTES.txt
  #     ├── _helpers.tpl
  #     ├── deployment.yaml
  #     ├── service.yaml
  #     └── ...
  

Syntax: helm install <release-name> <chart-path>

Description: Installs a Helm chart to your Kubernetes cluster, creating a new release with the specified name.

• Deploys a chart to your Kubernetes cluster
• Creates a new release with a unique name
• Can override values using --set or -f flags

• Use --dry-run to preview changes without applying them

  # Basic install
  helm install myrelease ./myapp
  
  # Install with custom values file
  helm install myrelease ./myapp -f custom-values.yaml
  
  # Install with inline value overrides
  helm install myrelease ./myapp --set replicaCount=3
  
  # Install in a specific namespace
  helm install myrelease ./myapp --namespace production --create-namespace
  
  # Dry run to see what would be installed
  helm install myrelease ./myapp --dry-run --debug
  
  # Install from a packaged chart
  helm install myrelease myapp-1.0.0.tgz
  
  # Install with a generated name
  helm install myapp --generate-name
  
  # Wait for all resources to be ready before marking release as successful
  helm install myrelease ./myapp --wait --timeout 5m
  

Syntax: helm upgrade <release-name> <chart-path>

Description: Upgrades an installed release with a new version of a chart or updated configuration values.

• Updates an existing release with new configurations or chart version
• Maintains revision history for rollback capability
• Can use --install to install if release doesn’t exist

• Supports value overrides like install command

  # Basic upgrade
  helm upgrade myrelease ./myapp
  
  # Upgrade with new values
  helm upgrade myrelease ./myapp -f production-values.yaml
  
  # Upgrade or install if not exists (atomic operation)
  helm upgrade myrelease ./myapp --install
  
  # Upgrade with specific values
  helm upgrade myrelease ./myapp --set image.tag=v2.0.0
  
  # Force resource updates even if unchanged
  helm upgrade myrelease ./myapp --force
  
  # Reuse previous values and merge with new ones
  helm upgrade myrelease ./myapp --reuse-values --set newKey=newValue
  
  # Reset values to chart defaults
  helm upgrade myrelease ./myapp --reset-values
  
  # Wait for upgrade to complete
  helm upgrade myrelease ./myapp --wait --timeout 10m
  
  # Atomic upgrade - rollback on failure
  helm upgrade myrelease ./myapp --atomic --timeout 5m
  

Syntax: helm uninstall <release-name>

Description: Uninstalls a release from the Kubernetes cluster, removing all associated resources.

• Deletes a release and all associated Kubernetes resources
• Removes the release from Helm’s history by default
• Use --keep-history to retain release history for potential restoration

• Respects hook deletion policies defined in templates

  # Basic uninstall
  helm uninstall myrelease
  
  # Uninstall but keep history (allows rollback)
  helm uninstall myrelease --keep-history
  
  # Uninstall from specific namespace
  helm uninstall myrelease --namespace production
  
  # Uninstall with custom timeout
  helm uninstall myrelease --timeout 5m
  
  # Dry run - see what would be deleted
  helm uninstall myrelease --dry-run
  
  # Uninstall and wait for all resources to be deleted
  helm uninstall myrelease --wait
  

Syntax: helm list

Description: Lists all installed Helm releases in the current or specified namespace.

• Shows all releases in the current namespace
• Displays release name, namespace, revision, status, and chart info
• Supports filtering and output formatting options

• Use --all-namespaces to see releases across all namespaces

  # List all releases in current namespace
  helm list
  
  # List all releases across all namespaces
  helm list --all-namespaces
  
  # List releases in specific namespace
  helm list --namespace production
  
  # Show all releases including uninstalled (if kept history)
  helm list --all
  
  # Filter by status
  helm list --deployed
  helm list --failed
  helm list --pending
  
  # Show more details (longer output)
  helm list --all-namespaces -o wide
  
  # Output as JSON
  helm list -o json
  
  # Output as YAML
  helm list -o yaml
  
  # Filter releases by name pattern
  helm list --filter 'myapp.*'
  
  # Limit number of results
  helm list --max 10
  
  # Sort by release date
  helm list --date
  

Syntax: helm status <release-name>

Description: Shows the status of a deployed Helm release including resource information and deployment details.

• Displays detailed information about a deployed release
• Shows resource status, last deployment time, and revision number
• Includes NOTES.txt content if present

• Useful for debugging and verifying deployments

  # Show status of a release
  helm status myrelease
  
  # Show status from specific namespace
  helm status myrelease --namespace production
  
  # Show status at specific revision
  helm status myrelease --revision 2
  
  # Output as JSON
  helm status myrelease -o json
  
  # Output as YAML
  helm status myrelease -o yaml
  
  # Show status without displaying NOTES
  helm status myrelease --show-desc
  

Syntax: helm rollback <release-name> [revision]

Description: Rollbacks a release to a previous revision number.

• Reverts a release to a previous revision
• Useful for quick recovery from failed upgrades
• Creates a new revision (rollback is tracked in history)

• Can rollback to any previously deployed revision

  # Rollback to previous revision
  helm rollback myrelease
  
  # Rollback to specific revision
  helm rollback myrelease 3
  
  # Rollback with timeout
  helm rollback myrelease 2 --timeout 5m
  
  # Wait for rollback to complete
  helm rollback myrelease --wait
  
  # Force rollback even if resources haven't changed
  helm rollback myrelease --force
  
  # Dry run - see what would be rolled back
  helm rollback myrelease --dry-run
  
  # Recreate resources (delete and recreate)
  helm rollback myrelease --recreate-pods
  
  # Cleanup on fail
  helm rollback myrelease --cleanup-on-fail
  

Syntax: helm get all <release-name>

Description: Retrieves all information about a deployed release including templates, values, hooks, and notes.

• Retrieves all information about a release
• Shows manifest, values, hooks, and notes
• Useful for debugging and understanding what was deployed

• Can retrieve information from specific revisions

  # Get all info about a release
  helm get all myrelease
  
  # Get all info from specific revision
  helm get all myrelease --revision 2
  
  # Get all info from specific namespace
  helm get all myrelease --namespace production
  
  # Output as template for reuse
  helm get all myrelease --template '{{.Release.Manifest}}'
  

Syntax: helm get values <release-name>

Description: Shows the user-supplied values for a release.

• Shows the values that were used for a specific release
• Displays only user-supplied values by default
• Use --all to see all values including defaults

• Useful for understanding current configuration

  # Get user-supplied values
  helm get values myrelease
  
  # Get all values (including defaults)
  helm get values myrelease --all
  
  # Get values from specific revision
  helm get values myrelease --revision 2
  
  # Output as JSON
  helm get values myrelease -o json
  
  # Output as YAML
  helm get values myrelease -o yaml
  
  # Save values to file
  helm get values myrelease > current-values.yaml
  

Syntax: helm show values <chart-name>

Description: Shows the default values of a Helm chart before installation.

• Displays the default values.yaml from a chart
• Works with local charts, remote charts, or chart repositories
• Useful for understanding available configuration options

• Shows values before installation

  # Show default values of local chart
  helm show values ./myapp
  
  # Show values from packaged chart
  helm show values myapp-1.0.0.tgz
  
  # Show values from chart repository
  helm show values bitnami/nginx
  
  # Show values at specific version
  helm show values bitnami/nginx --version 15.0.0
  
  # Save default values to file
  helm show values ./myapp > default-values.yaml
  

Syntax: helm template <release-name> <chart-path>

Description: Renders chart templates locally without installing to the cluster.

• Renders chart templates locally without connecting to Kubernetes
• Outputs rendered YAML manifests to stdout
• Useful for debugging templates and previewing changes

• Does not require cluster access

  # Render templates to stdout
  helm template myrelease ./myapp
  
  # Render with custom values
  helm template myrelease ./myapp -f custom-values.yaml
  
  # Render with inline values
  helm template myrelease ./myapp --set replicaCount=3
  
  # Render and save to file
  helm template myrelease ./myapp > rendered-manifests.yaml
  
  # Show only specific template
  helm template myrelease ./myapp --show-only templates/deployment.yaml
  
  # Debug mode - show more information
  helm template myrelease ./myapp --debug
  
  # Validate rendered output
  helm template myrelease ./myapp --validate
  
  # Include CRDs in output
  helm template myrelease ./myapp --include-crds
  
  # Render for specific Kubernetes version
  helm template myrelease ./myapp --kube-version 1.28.0
  

Syntax: helm lint <chart-path>

Description: Runs a series of tests to verify that the chart is well-formed and follows best practices.

• Runs tests to verify chart is well-formed
• Checks Chart.yaml, values.yaml, and template syntax
• Identifies common errors and issues

• Should be run before packaging or installing

  # Lint a chart
  helm lint ./myapp
  
  # Lint with custom values
  helm lint ./myapp -f custom-values.yaml
  
  # Lint with inline values
  helm lint ./myapp --set replicaCount=3
  
  # Strict linting (fail on warnings)
  helm lint ./myapp --strict
  
  # Lint with debug output
  helm lint ./myapp --debug
  
  # Lint multiple charts
  helm lint ./myapp ./anotherapp
  

Syntax: helm history <release-name>

Description: Prints historical revisions for a given release.

• Displays revision history for a release
• Shows revision number, update time, status, and description
• Useful for understanding what changed and when

• Helps identify which revision to rollback to

  # Show release history
  helm history myrelease
  
  # Show history from specific namespace
  helm history myrelease --namespace production
  
  # Show more revisions (default is 256)
  helm history myrelease --max 100
  
  # Output as JSON
  helm history myrelease -o json
  
  # Output as YAML
  helm history myrelease -o yaml
  
  # Output as table (default)
  helm history myrelease -o table
  

Syntax: helm test <release-name>

Description: Runs the tests defined in a chart for a release.

• Executes tests defined in chart’s templates/tests/ directory
• Tests are Kubernetes pods with the helm.sh/hook: test annotation
• Validates that a release is working correctly

• Returns exit code based on test success/failure

  # Run tests for a release
  helm test myrelease
  
  # Run tests from specific namespace
  helm test myrelease --namespace production
  
  # Run tests with timeout
  helm test myrelease --timeout 5m
  
  # Show test logs
  helm test myrelease --logs
  
  # Cleanup tests after run (default: false)
  helm test myrelease --cleanup
  
  # Filter which tests to run
  helm test myrelease --filter name=test-connection
  

Syntax: helm dependency update <chart-path>

Description: Updates the charts/ directory based on Chart.yaml dependencies.

• Downloads chart dependencies listed in Chart.yaml
• Stores dependencies in the charts/ subdirectory
• Creates or updates Chart.lock file

• Required before packaging or installing charts with dependencies

  # Update dependencies
  helm dependency update ./myapp
  
  # Update and skip refreshing repository index
  helm dependency update ./myapp --skip-refresh
  
  # Verify dependencies
  helm dependency list ./myapp
  
  # Build dependencies (use Chart.lock)
  helm dependency build ./myapp
  

Syntax: helm repo add <name> <url>

Description: Adds a chart repository to your local Helm configuration.

• Adds a chart repository to your local Helm configuration
• Repositories are stored in ~/.config/helm/repositories.yaml
• Enables searching and installing charts from the repository

• Can add both HTTP and OCI repositories

  # Add a chart repository
  helm repo add bitnami https://charts.bitnami.com/bitnami
  
  # Add with authentication
  helm repo add myrepo https://charts.example.com --username user --password pass
  
  # Add and force update if exists
  helm repo add bitnami https://charts.bitnami.com/bitnami --force-update
  
  # Add repository with custom certificate
  helm repo add myrepo https://charts.example.com --ca-file ca.crt
  
  # Add repository skipping TLS verification (not recommended)
  helm repo add myrepo https://charts.example.com --insecure-skip-tls-verify
  
  # List all repositories
  helm repo list
  

Syntax: helm repo update

Description: Updates information of available charts from chart repositories.

• Updates the local cache of charts from all added repositories
• Fetches the latest available charts and versions
• Should be run periodically to see new chart releases

• Similar to apt update or yum update

  # Update all repositories
  helm repo update
  
  # Update specific repository
  helm repo update bitnami
  
  # Update with failure on any repository error
  helm repo update --fail-on-repo-update-fail
  
  # Update multiple specific repositories
  helm repo update bitnami stable
  

Syntax: helm search repo <keyword>

Description: Searches repositories for charts matching a keyword.

• Searches added repositories for charts matching keyword
• Shows chart name, version, app version, and description
• Supports regex patterns for advanced searching

• Only searches locally added repositories

  # Search for charts
  helm search repo nginx
  
  # Search with version information
  helm search repo nginx --versions
  
  # Search with regex
  helm search repo 'nginx.*'
  
  # Show development versions (pre-release, etc.)
  helm search repo nginx --devel
  
  # Search with specific version constraint
  helm search repo nginx --version "~15.0"
  
  # Output as JSON
  helm search repo nginx -o json
  
  # Output as YAML
  helm search repo nginx -o yaml
  
  # Search all repositories
  helm search repo --max-col-width 0
  

• This hook runs a database migration job before installing or upgrading the main application resources.
• It ensures that the database schema is up-to-date before the application starts.
• The migrate.sh script would contain the logic to perform the database migration, and it would use environment variables to connect to the database.

  # templates/hooks/db-migrate.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-db-migrate
    annotations:
      "helm.sh/hook": pre-install,pre-upgrade
      "helm.sh/hook-weight": "0"
      "helm.sh/hook-delete-policy": hook-succeeded,hook-failed
  spec:
    template:
      metadata:
        name: {{ include "myapp.fullname" . }}-db-migrate
      spec:
        containers:
          - name: migrate
            image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
            command: ["./migrate.sh"]
            env:
              - name: DB_HOST
                value: {{ .Values.database.host }}
              - name: DB_NAME
                value: {{ .Values.database.name }}
        restartPolicy: Never
    backoffLimit: 3
  

• This hook runs a database initialization job only during the initial installation of the chart.
• It creates the database schema if it doesn’t already exist.
• It uses a lower weight to ensure it runs before the migration hook.
• The psql command is used to create the database, and it connects using environment variables for the database host and credentials.
• This hook will not run during upgrades, ensuring that it only initializes the database on the first install.

  # templates/hooks/db-init.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-db-init
    annotations:
      "helm.sh/hook": pre-install
      "helm.sh/hook-weight": "-5"  # Runs before migration (weight: 0)
      "helm.sh/hook-delete-policy": hook-succeeded
  spec:
    template:
      spec:
        containers:
          - name: init-db
            image: postgres:14
            command:
              - sh
              - -c
              - |
                psql -h $DB_HOST -U $DB_USER -c "CREATE DATABASE IF NOT EXISTS {{ .Values.database.name }};"
            env:
              - name: DB_HOST
                value: {{ .Values.database.host }}
              - name: DB_USER
                valueFrom:
                  secretKeyRef:
                    name: db-secret
                    key: username
              - name: PGPASSWORD
                valueFrom:
                  secretKeyRef:
                    name: db-secret
                    key: password
        restartPolicy: Never
  

• This hook runs a job after the main application resources are installed to check if the service is ready.
• It uses a simple curl command to check the health endpoint of the service, retrying until it gets a successful response.
• This ensures that the application is fully operational before the release is considered successful.
• The hook will be deleted after it succeeds, preventing it from running again unnecessarily.
• This is particularly useful for applications that require some time to become ready after deployment, such as those that perform initialization tasks or have complex startup processes.
• By using a post-install hook, you can provide immediate feedback on the success of the deployment and ensure that users are aware of any issues with service readiness right after installation.

  # templates/hooks/smoke-test.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-smoke-test
    annotations:
      "helm.sh/hook": post-install,post-upgrade
      "helm.sh/hook-weight": "5"
      "helm.sh/hook-delete-policy": hook-succeeded
  spec:
    template:
      spec:
        containers:
          - name: smoke-test
            image: curlimages/curl:latest
            command:
              - sh
              - -c
              - |
                echo "Waiting for service to be ready..."
                until curl -f http://{{ include "myapp.fullname" . }}:{{ .Values.service.port }}/health; do
                  echo "Service not ready yet, retrying in 5 seconds..."
                  sleep 5
                done
                echo "Service is ready!"
        restartPolicy: Never
    backoffLimit: 10
  

• This hook creates a backup of the database before upgrading the application.
• It uses the pg_dump command to create a SQL backup file with a timestamp.
• The backup is stored in a persistent volume claim to ensure it’s retained even if the job is deleted.
• The hook runs with a weight of -10 to ensure it executes before other upgrade hooks like migrations.
• This is a critical safety measure to ensure you can restore your data if an upgrade fails or causes data corruption.

  # templates/hooks/backup.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-backup-{{ now | date "20060102-150405" }}
    annotations:
      "helm.sh/hook": pre-upgrade
      "helm.sh/hook-weight": "-10"
      "helm.sh/hook-delete-policy": hook-succeeded
  spec:
    template:
      spec:
        containers:
          - name: backup
            image: "{{ .Values.backup.image }}"
            command:
              - sh
              - -c
              - |
                echo "Creating backup before upgrade..."
                pg_dump -h $DB_HOST -U $DB_USER $DB_NAME > /backup/backup-$(date +%Y%m%d-%H%M%S).sql
                echo "Backup completed successfully"
            env:
              - name: DB_HOST
                value: {{ .Values.database.host }}
              - name: DB_USER
                value: {{ .Values.database.user }}
              - name: DB_NAME
                value: {{ .Values.database.name }}
            volumeMounts:
              - name: backup-storage
                mountPath: /backup
        volumes:
          - name: backup-storage
            persistentVolumeClaim:
              claimName: backup-pvc
        restartPolicy: Never
  

• This hook sends a notification to Slack after the application is successfully installed or upgraded.
• It uses the Helm built-in .Release.IsInstall variable to determine whether this is a new installation or an upgrade.
• The hook runs with a weight of 10 to ensure it executes after other post-install/upgrade hooks like smoke tests.
• Notifications are sent regardless of hook success or failure (deletion policy: hook-succeeded,hook-failed).
• This is useful for keeping your team informed about deployments in production environments.

  # templates/hooks/notify.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-notify
    annotations:
      "helm.sh/hook": post-install,post-upgrade
      "helm.sh/hook-weight": "10"  # Runs after smoke test
      "helm.sh/hook-delete-policy": hook-succeeded,hook-failed
  spec:
    template:
      spec:
        containers:
          - name: notify
            image: curlimages/curl:latest
            command:
              - sh
              - -c
              - |
                if [ "{{ .Release.IsInstall }}" = "true" ]; then
                  ACTION="installed"
                else
                  ACTION="upgraded"
                fi
                curl -X POST {{ .Values.slack.webhookUrl }} \
                  -H 'Content-Type: application/json' \
                  -d "{\"text\":\"Application {{ .Release.Name }} has been $ACTION to version {{ .Chart.Version }} in namespace {{ .Release.Namespace }}\"}"
        restartPolicy: Never
  

• This hook performs cleanup operations before the main application resources are deleted.
• It uses kubectl to delete specific resources (in this case, ConfigMaps) that match certain labels.
• The hook requires a ServiceAccount with appropriate RBAC permissions to delete resources in the namespace.
• This is useful for cleaning up dynamically created resources that might not be tracked by Helm directly.
• The hook will be deleted after it succeeds, preventing orphaned cleanup jobs from accumulating.

  # templates/hooks/cleanup.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-cleanup
    annotations:
      "helm.sh/hook": pre-delete
      "helm.sh/hook-weight": "0"
      "helm.sh/hook-delete-policy": hook-succeeded
  spec:
    template:
      spec:
        containers:
          - name: cleanup
            image: bitnami/kubectl:latest
            command:
              - sh
              - -c
              - |
                echo "Cleaning up resources..."
                kubectl delete configmap -n {{ .Release.Namespace }} -l app={{ include "myapp.name" . }},release={{ .Release.Name }}
                echo "Cleanup completed"
        serviceAccountName: {{ include "myapp.fullname" . }}-cleanup
        restartPolicy: Never
  

• This hook generates a random password and creates a Kubernetes secret before the main application resources are installed.
• It uses the bitnami/kubectl image to run kubectl commands directly from the job.
• The generated password is stored in a secret named <release-name>-db-secret in the same namespace as the release.
• The hook is set to run only during installation, ensuring that a new secret is created each time a new release is installed.
• The before-hook-creation deletion policy ensures that if the hook runs multiple times (e.g., due to retries), the previous secret will be deleted before a new one is created, preventing orphaned secrets from accumulating.
• This hook is useful for scenarios where you need to generate dynamic configuration or credentials that must be available before the main application resources are created.

  # templates/hooks/create-secret.yaml
  apiVersion: batch/v1
  kind: Job
  metadata:
    name: {{ include "myapp.fullname" . }}-create-secret
    annotations:
      "helm.sh/hook": pre-install
      "helm.sh/hook-weight": "-15"  # Runs very early
      "helm.sh/hook-delete-policy": before-hook-creation
  spec:
    template:
      spec:
        containers:
          - name: create-secret
            image: bitnami/kubectl:latest
            command:
              - sh
              - -c
              - |
                # Generate random password
                PASSWORD=$(openssl rand -base64 32)
  
                # Create Kubernetes secret
                kubectl create secret generic {{ include "myapp.fullname" . }}-db-secret \
                  --from-literal=password=$PASSWORD \
                  --namespace={{ .Release.Namespace }} \
                  --dry-run=client -o yaml | kubectl apply -f -
  
                echo "Secret created successfully"
        serviceAccountName: {{ include "myapp.fullname" . }}-admin
        restartPolicy: Never