---
schema_version: 1
route: /t/helmfile.md
tool: "helmfile"
---

# sincecutoff.com /t/helmfile — Helmfile

- name: Helmfile
- kind: cli
- children: none
- homepage: <https://github.com/helmfile/helmfile>

Changes to the tools coding agents drive, since a model's training cutoff, each linked to its first-party source. Check installed versions and limitations before acting; a cutoff date does not establish what a model knows.
Original editorial content: [Apache 2.0](https://sincecutoff.com/v1/data-license.txt), by [0xPatrick](https://0xpatrick.dev). Preserve applicable license and [NOTICE](https://sincecutoff.com/notice.txt) attribution when redistributing. Third-party source text and examples retain their own rights. [License scope and attribution](https://sincecutoff.com/v1/license.json).
To stay current, read the changes feed: [`/v1/changes.md?tool=helmfile`](https://sincecutoff.com/v1/changes.md?tool=helmfile) (or `.json`), adding `since=YYYY-MM-DD` for your training cutoff. Entries for registered children are included; the registry itself is `/v1/tools.json`. How to page and save your place: [llms.txt](https://sincecutoff.com/llms.txt).

### helmfile `dir=` selector filters releases and skips sub-helmfile traversal (2026-10-16)
- slug: helmfile-dir-selector-filters-releases-and-skips-sub-helmfile-traversal-72c8262a73c1
- score: 0.97

How to use it:

When syncing a service in nested Helmfiles, run `helmfile -l dir=<path> sync` to select releases whose defining Helmfile is in that directory or a subdirectory; Helmfile skips sub-Helmfile branches whose location rules out a match.

Examples:

```
helmfile -l dir=apps/<single-service> sync
```

- why_it_matters: When syncing one service in a project with nested helmfiles, select its directory to filter releases and skip sub-helmfile branches that cannot match.
- before: Before this change, CLI selectors could skip a nested Helmfile before loading or rendering it only when that entry had explicit `selectors:` provably incompatible with the CLI selectors; otherwise the nested branches were parsed and templated before release filtering.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.8.2>, <https://github.com/helmfile/helmfile/pull/2609>, <https://github.com/helmfile/helmfile/blob/v1.8.2/docs/index.md>
- gotchas: "Version: v1.8.2"; "-l, --selector <key=value>: Select releases matching labels; `dir=<path>` uses the defining Helmfile's directory relative to the root and matches that directory and its subdirectories. The option can be specified multiple times; comma-separated selectors in a group are all required, while separate groups are resolved independently."; "dir=<path> (required): For this task, provide a relative directory path. Trailing slashes and `./` prefixes are stripped. Absolute paths, escaping `..` segments, and bare `.` are rejected. `dir` is reserved; user-defined `dir` labels are ignored for selector matching and cause a warning."; "Prerequisite: Helmfile v1.8.2 documentation describes this selector. Helm must be installed for Helmfile operation."; "Directory matching is relative to the root directory: the file passed via `-f` (or that directory itself when `-f` points to one), or the current directory when no `-f` is given."; "`dir=` uses directory-prefix matching, so a path matches releases in that directory and its subdirectories."; "Values are normalized by stripping trailing slashes and `./` prefixes."; "Absolute paths, `..` segments that escape the root, and bare `.` are rejected at parse time; omit the selector to match every release."; "The `dir` label key is reserved; user-defined `dir` labels are ignored for selector matching and produce a warning."

### helmfile kubedog startup-only pod logs (2026-10-16)
- slug: helmfile-kubedog-startup-only-pod-logs-6eb571e2196d
- score: 0.98

How to use it:

When tracking a release with kubedog and routine logs enabled, set `trackLogsUntilReady: true` or pass the documented flags to `helmfile apply`. Each pod’s routine logs stop after its first Ready transition while readiness and failure tracking continue.

Examples:

```
helmfile apply --track-mode kubedog --track-timeout 600 --track-logs --track-logs-until-ready
```

- why_it_matters: When reviewing deployment logs for a kubedog-tracked release, limit routine pod output to startup while tracking readiness and failures for every pod.
- before: With `trackLogs: true`, use the default full streaming behavior, which continues printing logs throughout tracking.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.8.2>, <https://github.com/helmfile/helmfile/pull/2814>, <https://helmfile.readthedocs.io/en/latest/advanced-features/>
- gotchas: "Version: v1.8.2"; "track-mode / trackMode (required): Set to `kubedog` to enable kubedog tracking."; "track-logs / trackLogs (required): Enable log output from tracked resources; required for `track-logs-until-ready` to apply."; "track-logs-until-ready / trackLogsUntilReady (required): Stop routine pod logs after each pod first becomes ready; config default is `false`."; "track-timeout / trackTimeout: Tracking timeout in seconds; default is 300. The example uses 600."; "Prerequisite: Enable kubedog tracking with `trackMode: kubedog` or `--track-mode kubedog`, and enable routine logs with `trackLogs: true` or `--track-logs`."; "The option applies only when `trackLogs` is enabled; `trackFailedLogs: true` alone retains failed-only behavior."; "Job logs retain their existing behavior."; "Kubernetes readiness timestamps have second precision, so logs from the readiness second are retained."; "Log output remains limited to startup if the same pod later becomes unready or fails; replacement pods reset the filter."; "Kubernetes continues collecting logs; the change limits printed output."

### helmfile per-release `trackLogsInterval` (2026-10-16)
- slug: helmfile-per-release-tracklogsinterval-9c3581fbc9ec
- score: 0.97

How to use it:

When using Kubedog tracking with `trackLogs` or `trackFailedLogs` on `helmfile apply` or `helmfile sync`, set `trackLogsInterval` on the release to control log update frequency. An explicitly supplied `--track-logs-interval` overrides it; otherwise it overrides the `10s` default (minimum `1s`).

Examples:

```
releases:
  - name: <release>
    chart: <chart>
    trackMode: kubedog
    trackLogs: true
    trackLogsInterval: 1s
```

```
helmfile apply --track-mode kubedog --track-logs --track-logs-interval 1s
```

- why_it_matters: When tuning kubedog log updates for a release, configure its log output interval in the release configuration.
- before: The release note says Kubedog’s log output interval was configured by the `--track-logs-interval` argument; there was no matching per-release option to save in helmfile.yaml.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.8.2>, <https://github.com/helmfile/helmfile/pull/2825>, <https://github.com/helmfile/helmfile/blob/v1.8.2/docs/advanced-features.md>
- gotchas: "Version: v1.8.2"; "releases[].trackLogsInterval: Duration between log output updates; default `10s`, minimum `1s`."; "--track-logs-interval: Command-line log output interval; overrides the release setting when explicitly supplied."; "releases[].trackMode: Set to `kubedog` to enable Kubedog resource tracking."; "releases[].trackLogs: Print logs from tracked resources during deployment; interval applies when this or `trackFailedLogs` is enabled."; "releases[].trackFailedLogs: Print collected logs only for pods that fail during deployment; interval applies when this or `trackLogs` is enabled."; "Prerequisite: Use Kubedog tracking and enable either `trackLogs` or `trackFailedLogs`; supported commands are `helmfile apply` and `helmfile sync`."; "Applies to `helmfile apply` and `helmfile sync` with either `trackLogs` or `trackFailedLogs` enabled."; "The default is `10s`; the minimum is `1s`."; "Deployment progress is checked for changes every 10 seconds."

### helmfile release-level continueOnError keeps independent releases processing (2026-09-30)
- slug: helmfile-release-level-continueonerror-keeps-independent-releases-processing-b0ab8ab90b30
- score: 0.98

How to use it:

When syncing releases, set `continueOnError: true` on releases whose failures should not stop independent DAG branches. Helmfile skips dependent releases and exits non-zero if any release fails.

Examples:

```
releases:
  - name: app-a
    chart: ./charts/app-a
    continueOnError: true
  - name: app-b
    chart: ./charts/app-b
    continueOnError: true

helmfile sync
```

```
helmfile sync --file <path/to/helmfile.yaml>
```

- why_it_matters: Continue syncing independent releases after a release fails while deploying a Helmfile release set.
- before: By default, `helmfile sync` stops on the first release failure (fail-fast).
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.8.1>, <https://github.com/helmfile/helmfile/pull/2804>, <https://github.com/helmfile/helmfile/blob/v1.8.1/docs/configuration.md>, <https://github.com/helmfile/helmfile/blob/v1.8.1/docs/cli.md>, <https://github.com/helmfile/helmfile/blob/v1.8.1/docs/releases.md>
- gotchas: "Version: v1.8.1"; "continueOnError: Release-level boolean; defaults to false. When true, Helmfile continues independent releases after this release fails; releases depending on it are skipped. Does not change Helm rollback behavior or make the command succeed."; "sync (required): Helmfile subcommand that syncs cluster state from the Helmfile."; "--file: Path to the Helmfile YAML state; defaults to `helmfile.yaml`."; "The setting defaults to false."; "Only independent releases continue; releases that depend on a failed release are skipped."; "The command exits non-zero when any release fails."; "For apply, diff and chart-preparation failures remain fatal and are not converted into tolerated release errors."; "Helm's per-release rollback behavior and other existing Helm behavior are unchanged."

### helmfile supports continuing after failed releases (2026-09-13)
- slug: helmfile-supports-continuing-after-failed-releases-39aed36d9af7
- score: 0.96

How to use it:

When chart preparation fails for a release, run Helmfile with `--allow-failed-releases` to skip that release, continue preparing other releases, and report failures at the end.

Examples:

```
helmfile --allow-failed-releases template
```

- why_it_matters: Prepare charts for other releases even when a release fails during chart preparation.
- before: Failure handling aborted by default. `helmfile list` displayed whatever it could while reporting errors.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.8.0>, <https://github.com/helmfile/helmfile/pull/2616>, <https://github.com/helmfile/helmfile/blob/v1.8.0/docs/cli.md>
- gotchas: "Version: v1.8.0"; "--allow-failed-releases: Defaults to false. Continue preparing charts for other releases when chart preparation fails; skip failed releases and report failures at the end."; "The default remains abort on failure."; "The `list` command always displays whatever it can while reporting errors."

### helmfile supports disabling hooks (2026-07-17)
- slug: helmfile-supports-disabling-hooks-6442c4195fef
- score: 0.93

How to use it:

When Helmfile hook shell commands must be disabled, set `HELMFILE_DISABLE_HOOKS=true` for the Helmfile invocation. If hooks are configured while this setting is active, Helmfile returns an error instead of triggering them.

Examples:

```
HELMFILE_DISABLE_HOOKS=true helmfile <command>
```

- why_it_matters: Run Helmfile without executing hooks when hook shell commands should be disabled.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.7.1>, <https://github.com/helmfile/helmfile/pull/2691>, <https://github.com/helmfile/helmfile/blob/v1.7.1/pkg/event/bus.go>, <https://github.com/helmfile/helmfile/blob/v1.7.1/pkg/envvar/const.go>
- gotchas: "Version: v1.7.1"; "HELMFILE_DISABLE_HOOKS: Boolean environment variable parsed with Go `strconv.ParseBool`; when true, hook triggering is blocked if hooks are configured."; "Prerequisite: Use Helmfile v1.7.1 or later; the setting is present in the v1.7.1 source."; "Hooks can execute arbitrary shell commands."

### helmfile releaseSpec adds conditionTemplate (2026-07-04)
- slug: helmfile-releasespec-adds-conditiontemplate-12b89257e3be
- score: 0.97

How to use it:

When a release needs a dynamic enablement condition, set `conditionTemplate` to a Go template that renders a boolean. If both condition fields are set, its rendered value replaces `condition`; `list` does not evaluate it.

Examples:

```
releases:
  - name: <release-name>
    chart: <repository/chart>
    conditionTemplate: '{{`{{ eq .Release.Namespace "kube-system" }}`}}'
```

- why_it_matters: Enable or disable releases dynamically based on templated release conditions.
- before: Use `condition` as a direct `true` or `false` value, or as a values lookup path ending in `.enabled`.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.7.0>, <https://github.com/helmfile/helmfile/pull/2669>, <https://github.com/helmfile/helmfile/blob/v1.7.0/docs/writing-helmfile.md>, <https://github.com/helmfile/helmfile/blob/v1.7.0/docs/configuration.md>
- gotchas: "Version: v1.7.0"; "conditionTemplate: String Go template for a release condition; it must render to a boolean. When both condition fields are set, its rendered value replaces `condition`."; "condition: Release enablement condition: direct `true` or `false`, or a values lookup path ending in `.enabled`. Replaced by the rendered `conditionTemplate` value when both are set."; "The rendered `conditionTemplate` must be boolean."; "`conditionTemplate` is not evaluated by the `list` command."; "If `condition` and `conditionTemplate` are both set, the rendered template value replaces `condition`."

### helmfile template/apply/sync add --template-args for helm lookup() support (2026-07-04)
- slug: helmfile-template-apply-sync-add-template-args-for-helm-lookup-support-582e264610ed
- score: 0.93

How to use it:

When a chart uses `lookup()` and rendering needs live cluster values, pass `--template-args="--dry-run=server"` to `helmfile template`, `apply`, or `sync`. `--template-args` forwards extra arguments to Helm rendering.

Examples:

```
helmfile template --template-args="--dry-run=server"
```

```
helmfile apply --template-args="--dry-run=server"
```

```
helmfile sync --template-args="--dry-run=server"
```

- why_it_matters: Render or apply Helm charts that use `lookup()` from a Helmfile workflow.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.7.0>, <https://github.com/helmfile/helmfile/blob/main/docs/cli.md>, <https://github.com/helmfile/helmfile/blob/v1.7.0/cmd/sync.go>, <https://github.com/helmfile/helmfile/blob/v1.7.0/cmd/apply.go>, <https://helm.sh/docs/chart_template_guide/debugging/>
- gotchas: "Version: v1.7.0"; "--template-args <string>: Extra arguments appended to Helm rendering; the default is empty. `--dry-run=server` enables a server connection for `lookup()`."; "--dry-run=server: Helm server-side dry run; requires cluster connectivity. Pass it as the value to `--template-args` when rendering needs `lookup()`."; "Prerequisite: `--dry-run=server` requires cluster connectivity. Helm uses its Kubernetes connection configuration for `lookup()`; API access errors fail template processing."

### helmfile apply tracks kubedog progress in parallel with Helm (2026-06-22)
- slug: helmfile-apply-tracks-kubedog-progress-in-parallel-with-helm-f462c48dfff2
- score: 0.98

How to use it:

When applying a Helmfile release with live kubedog progress, run `helmfile apply --track-mode kubedog`. Helmfile tracks resources in parallel with Helm and buffers Helm output per release. [Release notes](https://github.com/helmfile/helmfile/releases/tag/v1.6.0)

Examples:

```
helmfile apply --track-mode kubedog
```

```
helmfile apply --track-mode kubedog --track-timeout <seconds>
```

- why_it_matters: Apply a Helmfile release with live resource convergence progress while Helm installs or upgrades it.
- before: Tracking ran only after Helm finished; there was no progress feedback during the release.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.6.0>, <https://github.com/helmfile/helmfile/pull/2654>, <https://github.com/helmfile/helmfile/blob/v1.6.0/cmd/apply.go>, <https://github.com/helmfile/helmfile>
- gotchas: "Version: v1.6.0"; "--track-mode: Tracking mode for releases: `helm` (default), `helm-legacy` (Helm v4 only), or `kubedog`."; "--track-timeout: Kubedog tracking timeout in seconds; `0` uses the default 300-second timeout."; "Prerequisite: Helm and helm-diff must be installed for Helmfile to delegate to Helm."; "The parallel tracking behavior applies with `--track-mode kubedog`."; "A tracker that does not return within the release timeout is treated as a failure."

### helmfile doctor analyzes diffs and gates high-risk changes (2026-06-22)
- slug: helmfile-doctor-analyzes-diffs-and-gates-high-risk-changes-e9e7e5c74346
- score: 0.95

How to use it:

Before applying planned changes, run `helmfile doctor` to review the diff; use `--output json` for a structured report. High-risk findings exit 2 unless `--force` is passed.

Examples:

```
export HELMFILE_LLM_API_KEY="<api-key>"
export HELMFILE_LLM_MODEL="<model-id>"
helmfile doctor --output json
```

```
helmfile doctor --force --output json
```

```
helmfile doctor
```

- why_it_matters: Review planned Helmfile changes in a CI pipeline before applying them.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.6.0>, <https://github.com/helmfile/helmfile/blob/v1.6.0/docs/cli.md>
- gotchas: "Version: v1.6.0"; "--output <format>: Doctor report format; `json` emits structured JSON. Default is text."; "--force: Skip the exit-2 gate when a high-severity risk is found."; "--context <N>: Diff context lines; doctor defaults to 3."; "llm.baseURL: OpenAI-compatible endpoint base URL; defaults to `https://api.openai.com/v1`."; "llm.apiKey (required): API key; required to enable LLM analysis."; "llm.model (required): Model identifier; required to enable LLM analysis."; "llm.timeout: Per-request timeout; default 60s."; "llm.maxTokens: Maximum completion tokens; default 4096."; "--llm-base-url <URL>: Set the OpenAI-compatible endpoint URL."; "--llm-api-key <key>: Set the LLM API key."; "--llm-model <id>: Set the model identifier."; "--llm-timeout <duration>: Set per-request timeout; Go duration format."; "--llm-max-tokens <N>: Set completion token cap."; "--diff-output <format>: Set helm-diff plugin output format; `--output` is reserved for doctor report format."; "--show-secrets: Ignored by doctor; secrets remain redacted."; "--suppress-secrets: Drop Secret resource structure from the diff."; "Prerequisite: LLM analysis requires `apiKey` and `model`; `baseURL` is optional. The endpoint must speak OpenAI Chat Completions protocol."; "Prerequisite: `helmfile diff` requires helm-diff plugin v2.9.0+1 or greater."; "The endpoint must be OpenAI-compatible and support Chat Completions."; "The default `--context` value is 3."; "A high risk exits with code 2 unless `--force` is passed; other errors exit with code 1."; "An LLM call failure degrades to exit code 0."; "Secrets are always redacted before any byte leaves the process; `--show-secrets` is silently ignored."; "Without LLM configuration, doctor degrades to a plain `helmfile diff` with `--show-secrets` forced off."; "Most `helmfile diff` flags are accepted for parity."

### helmfile accepts HELMFILE_NAMESPACE for the default namespace (2026-05-22)
- slug: helmfile-accepts-helmfile-namespace-for-the-default-namespace-54be40108850
- score: 0.90

How to use it:

When you want Helmfile to use a default namespace without passing it on each run, set `HELMFILE_NAMESPACE` before invoking Helmfile. An explicit `--namespace` value takes precedence over the environment variable.

Examples:

```
HELMFILE_NAMESPACE=<namespace> helmfile apply
```

- why_it_matters: Run Helmfile against a repository's default namespace without specifying it on each invocation.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.5.2>, <https://github.com/helmfile/helmfile/blob/main/docs/templating.md>, <https://github.com/helmfile/helmfile/pull/2592>
- gotchas: "Version: v1.5.2"; "HELMFILE_NAMESPACE: Sets the namespace fallback; an explicit `--namespace` overrides it. If neither is set, Helmfile uses the namespace from the Kubernetes context."

### helmfile applies defaultInherit templates to releases (2026-05-22)
- slug: helmfile-applies-defaultinherit-templates-to-releases-5bcc7376cf16
- score: 0.98

How to use it:

When releases share templates, set top-level `defaultInherit` in `helmfile.yaml` to a template name or ordered list; Helmfile applies them to every release and does not duplicate templates already explicitly inherited. Use release `inherit[].except` to omit fields.

Examples:

```
templates:
  defaults:
    namespace: kube-system
defaultInherit: defaults
releases:
- name: <release-name>
  chart: <chart>
  version: <version>
```

```
defaultInherit:
  - ns-template
  - defaults
```

```
releases:
- name: <release-name>
  chart: <chart>
  inherit:
  - template: defaults
    except:
    - values
```

- why_it_matters: Configure a Helmfile repository whose releases share one or more templates without repeating `inherit` on every release.
- before: Specify `inherit` on each release that should inherit the template.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.5.2>, <https://github.com/helmfile/helmfile/pull/2600>, <https://github.com/helmfile/helmfile/blob/v1.5.2/docs/writing-helmfile.md>
- gotchas: "Version: v1.5.2"; "defaultInherit: Top-level default template name or list of template names applied to all releases; list order determines merge order."; "inherit[].template (required): Name of the release template to inherit."; "inherit[].except: List of fields to exclude from that template."; "Prerequisite: Use Helmfile v1.5.2 or later for this feature."; "A referenced template must exist; the source mentions an error for a non-existent template."

### helmfile supports HELMFILE_* environment variables for more global flags (2026-05-22)
- slug: helmfile-supports-helmfile-environment-variables-for-more-global-flags-733813967029
- score: 0.95

How to use it:

When a workflow needs Helmfile global flag defaults, set the corresponding supported `HELMFILE_*` environment variable; for example, set `HELMFILE_NAMESPACE` before running `helmfile sync`.

Examples:

```
HELMFILE_NAMESPACE=<namespace> helmfile sync
```

```
HELMFILE_KUBE_CONTEXT=<context> helmfile sync
```

```
HELMFILE_ENVIRONMENT=<environment> helmfile sync
```

- why_it_matters: Configure Helmfile's global flags through environment variables in a repository workflow.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.5.2>, <https://raw.githubusercontent.com/helmfile/helmfile/v1.5.2/cmd/root.go>
- gotchas: "Version: v1.5.2"; "HELMFILE_NAMESPACE: Sets the default namespace; `--namespace` overrides it."; "HELMFILE_KUBE_CONTEXT: Sets the default Kubernetes context; `--kube-context` overrides it."; "HELMFILE_ENVIRONMENT: Sets the Helmfile environment name; `--environment` overrides it."; "HELMFILE_HELM_BINARY: Sets the Helm binary path; `--helm-binary` overrides it."; "HELMFILE_KUSTOMIZE_BINARY: Sets the Kustomize binary path; `--kustomize-binary` overrides it."; "HELMFILE_LOG_LEVEL: Sets the log level; `--log-level` overrides it."; "HELMFILE_QUIET: Sets quiet mode; `--quiet` overrides it."; "HELMFILE_DEBUG: Sets debug mode; `--debug` overrides it."; "HELMFILE_NO_COLOR: Disables color output; `--no-color` overrides it. The CLI also recognizes `NO_COLOR`; precedence between the environment variables is not documented here."; "Prerequisite: Use Helmfile v1.5.2 or later for the release-note change."

### helmfile environment values support mergeStrategy: fallback (2026-05-11)
- slug: helmfile-environment-values-support-mergestrategy-fallback-2bb408d47c8f
- score: 0.98

How to use it:

When an environment loads shared defaults and cluster-specific values, set `mergeStrategy: fallback` so earlier files take precedence and later files fill missing keys.

Examples:

```
environments:
  production:
    mergeStrategy: fallback
    values:
      - cluster-specific.yaml
      - shared-defaults.yaml.gotmpl
```

- why_it_matters: Configure an environment so cluster-specific values take precedence over shared defaults when loading multiple values files.
- before: By default, later files listed under `values:` override earlier files.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.5.1>, <https://github.com/helmfile/helmfile/pull/2578>, <https://github.com/helmfile/helmfile/blob/v1.5.1/docs/environments.md>
- gotchas: "Version: v1.5.1"; "mergeStrategy: Set to `fallback` to make earlier environment values files take precedence. The default is `override` behavior."; "values (required): Ordered list of environment values files to merge."; "values[] (required): File paths in order: under `fallback`, explicit non-null values in earlier files are preserved, including `false`, `0`, empty strings, and empty lists; maps are deep-merged so later files can add nested keys."; "The fallback strategy is opt-in per environment."; "Explicit non-nil values in earlier files, including false, 0, empty strings, and empty lists, are preserved against later files."; "Maps are deep-merged, allowing later files to add nested keys."

### helmfile create scaffolds deployment projects (2026-05-03)
- slug: helmfile-create-scaffolds-deployment-projects-c00309fd7b53
- score: 0.95

How to use it:

When scaffolding a Helmfile deployment project, run `helmfile create` with an optional project name; use `--output-dir` to choose the destination or `--force` to overwrite existing scaffold files.

Examples:

```
helmfile create [<NAME>] [-o <OUTPUT_DIR>] [--force]
```

- why_it_matters: Scaffold a Helmfile deployment project in a repository.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.5.0>, <https://github.com/helmfile/helmfile/pull/2574>, <https://github.com/helmfile/helmfile/blob/v1.5.0/docs/cli.md>
- gotchas: "Version: v1.5.0"; "NAME: Project name; when omitted, the scaffold is created in the current directory. Name validation rejects path separators, `.`, `..`, and whitespace-only names."; "-o, --output-dir <OUTPUT_DIR>: Output directory; defaults to NAME or the current directory."; "--force: Overwrite existing scaffold files. Without it, target paths are checked before writing to avoid partial scaffolds."; "Project names are validated against path traversal."

### helmfile passes a description to `helm upgrade` (2026-03-24)
- slug: helmfile-passes-a-description-to-helm-upgrade-85e3b157a828
- score: 0.96

How to use it:

When upgrading releases through Helmfile v1.4.3, use `helmfile apply --description <description>` to pass a description to `helm upgrade`; the CLI description applies to all releases and overrides descriptions in the Helmfile.

Examples:

```
helmfile apply --description "<description>"
```

- why_it_matters: Upgrade a Helm release with a description from a Helmfile workflow.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.4.3>, <https://github.com/helmfile/helmfile/blob/v1.4.3/cmd/apply.go>
- gotchas: "Version: v1.4.3"; "--description <description>: Sets the description for all releases; overrides descriptions in the Helmfile and is passed to `helm upgrade --description`."; "Prerequisite: Use Helmfile v1.4.3 or later for this feature."

### helmfile HCL templates add CIDR functions (2026-03-02)
- slug: helmfile-hcl-templates-add-cidr-functions-54f88d5c193c
- score: 0.97

How to use it:

When templating IP addresses or subnet ranges from HCL in Helmfile v1.4.0, use `cidrhost`, `cidrnetmask`, `cidrsubnet`, or `cidrsubnets` with the required arguments for the calculation. [HCL Functions](https://github.com/helmfile/helmfile/blob/v1.4.0/docs/hcl_funcs.md)

Examples:

```
cidrhost("10.0.0.0/8", 2)
```

```
cidrsubnet("10.0.0.0/8", 8, 2)
```

```
cidrsubnets("10.0.0.0/8", 4, 4)
```

- why_it_matters: Template static IP addresses or subnet ranges for Kubernetes resources from HCL in a Helmfile repository.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.4.0>, <https://github.com/helmfile/helmfile/pull/2426>, <https://github.com/helmfile/helmfile/blob/v1.4.0/docs/hcl_funcs.md>
- gotchas: "Version: v1.4.0"; "cidrhost(prefix, hostnum): `prefix` (required): IP network address prefix."; "cidrhost(prefix, hostnum): `hostnum` (required): Host number within the prefix."; "cidrnetmask(prefix): `prefix` (required): IPv4 address prefix in CIDR notation."; "cidrsubnet(prefix, newbits, netnum): `prefix` (required): IP network address prefix."; "cidrsubnet(prefix, newbits, netnum): `newbits` (required): Number of bits used to extend the prefix."; "cidrsubnet(prefix, newbits, netnum): `netnum` (required): Subnet number within the prefix."; "cidrsubnets(prefix, newbits...): `prefix` (required): CIDR prefix containing the consecutive ranges."; "cidrsubnets(prefix, newbits...): `newbits...` (required): One or more bit counts for the ranges to calculate."; "The release describes these functions as additions to Helmfile's supported HCL functions."

### helmfile HCL values allow overrides across imported files (2026-02-25)
- slug: helmfile-hcl-values-allow-overrides-across-imported-files-a04516521a78
- score: 0.95

How to use it:

When multiple imported `.hcl` files define the same key in `values` blocks, define the override in the later-loaded file. Maps merge per key; lists are replaced as a whole, and mixed-type overrides use the later value and type.

Examples:

```
# values1.hcl
values {
  my_var = 1
}

# values2.hcl
values {
  my_var = 2
}
```

- why_it_matters: When layering Helmfile values across imported HCL files, define the same key in a later file to override the earlier value.
- before: Avoid defining the same variable in multiple HCL `values` blocks because it caused a variable naming collision; use distinct variables and merge them instead.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.3.2>, <https://github.com/helmfile/helmfile/pull/2402>, <https://github.com/helmfile/helmfile/blob/main/docs/environments.md>
- gotchas: "Version: v1.3.2"; "values block key (required): The key to define in each imported HCL `values` block; later files override earlier files. Map values merge per key; lists are replaced as a whole; mixed types use the latest value and type."; "HCL file order (required): List the imported `.hcl` files in load order; the last file loaded wins for duplicate keys."; "Prerequisite: HCL is supported for environment values; only files suffixed `.hcl` are interpreted as HCL."

### helmfile adds helmfile unittest integration (2026-02-19)
- slug: helmfile-adds-helmfile-unittest-integration-282d669d8508
- score: 0.96

How to use it:

When a Helmfile release defines `unitTests`, run `helmfile unittest` to execute its helm-unittest tests using the release’s merged values.

Examples:

```
helmfile unittest
```

```
releases:
  - name: my-app
    chart: ./charts/my-app
    unitTests:
      - tests
```

```
helm plugin install https://github.com/helm-unittest/helm-unittest
```

- why_it_matters: Run helm-unittest tests for a Helmfile-managed chart from the Helmfile workflow.
- sources: <https://github.com/helmfile/helmfile/releases/tag/v1.3.0>, <https://github.com/helmfile/helmfile/blob/main/docs/cli.md>
- gotchas: "Version: v1.3.0"; "unitTests: Release-level list of helm-unittest test file or directory paths. When set, the release is tested; paths are relative to the chart directory. Releases without it are skipped."; "Prerequisite: Install the helm-unittest Helm plugin."; "Prerequisite: The Helmfile release must define `unitTests`; releases without it are skipped."