skip to content

What does Helm's --no-hooks flag do, and when is reaching for it dangerous?

level: middleimportance: should knowfreq 38%

answer

  1. One operation, not a setting
  2. You cannot pick which hook
  3. Subcharts are included too
  4. Skipped work is never rescheduled
  5. The history looks completely ordinary

basics

~20 s

It makes one Helm operation skip every hook that operation would have fired, including subchart hooks. It is all-or-nothing and skipped hooks are never queued for later, so any invariant a hook maintained silently does not hold.

solid answer

~40 s

`--no-hooks` is accepted by `helm install`, `helm upgrade`, `helm rollback` and `helm uninstall`, and it suppresses every hook for that single operation — there is no way to skip one hook and keep the others, and hooks in subcharts are skipped along with the parent's. Nothing is deferred: a skipped `pre-upgrade` migration does not run later, it simply never ran. The legitimate use is a break-glass one, such as getting an upgrade through after you have already run the migration by hand, or installing into a cluster where a hook's prerequisites do not exist yet. The danger is that the release looks completely normal afterwards — `helm history` shows an ordinary revision — while the schema, seed data or credential the chart's Pods assume was never created.

code

bash · 4 lines
bash
helm upgrade telemetry-gateway ./gateway --version 4.11.2 -n ingest-eu --no-hooks

helm get values telemetry-gateway -n ingest-eu
helm history telemetry-gateway -n ingest-eu

go deeper

for a junior

Recall that the flag exists and what it means: this one command runs without the chart's hooks. Do not treat it as a way to make a failing deploy succeed; it makes the deploy skip work, not fix it.

for a middle

Explain that it is unselective, applies to a single operation, covers subchart hooks, and defers nothing. Be able to name a legitimate use — the migration was already run by hand — and the value-gated alternative for making a hook optional by design.

for a senior

Show the operational judgement: what you verify by hand afterwards, how you record that the release's invariants were not established by Helm, and why a flag that leaves no trace in helm history is the one you audit pipelines for.

for a principal

Decide the policy: whether operators may use it at all, what evidence a break-glass deploy must leave, and whether charts in your estate are required to make optional lifecycle work a value rather than something an operator suppresses at the command line.

### What the flag does `--no-hooks` tells Helm to run the operation with its hook phases removed. On `helm install` no install hooks fire, on `helm upgrade` no upgrade hooks, on `helm rollback` no rollback hooks, on `helm uninstall` no delete hooks. The chart's own resources are applied exactly as usual, so the operation is not a dry run — it is the real thing minus the lifecycle Jobs. Three properties matter more than the definition: 1. **It is all or nothing.** There is no flag that skips one named hook. If a chart's `pre-upgrade` phase contains a broken migration Job and a working permissions-fixup Job, `--no-hooks` skips both. 2. **It reaches into subcharts.** A parent chart with an optional bundled database subchart usually relies on that subchart's own `pre-install` hook to initialise the database. `--no-hooks` on the parent's install skips it too, because hooks are collected across the whole rendered chart, not per chart. 3. **Nothing is deferred.** Helm does not remember that hooks were skipped and does not run them at the next opportunity. The work simply did not happen. ### When it is the right lever It is an operator's break-glass tool, and the honest uses have a common shape: *the hook's work is already done, or cannot be done here.* - A `pre-upgrade` migration Job crashes on a bug in the migrator image, you run the migration by hand against the database, and you need the upgrade to proceed. - You are installing a chart into a namespace where the hook's prerequisite — a database that has not been provisioned yet, an external endpoint that is firewalled — does not exist, and you intend to complete the setup afterwards. - You are reproducing a release locally and do not want a hook to touch a shared system. In each case the person typing the flag is holding the missing work in their head. That is precisely the risk. ### Why it is dangerous The release that comes out the other side is indistinguishable from a healthy one. `helm history` shows a `deployed` revision with the new chart version and no marker that its hooks were skipped; `helm status` reports the release deployed. Every invariant the chart's hooks maintained — the schema migrated, the seed rows written, the bootstrap Secret created, the lease taken — is now an assumption instead of a fact, and the next person to read the history has no way to see it. When the workload fails days later, the cause is a flag that appeared once in someone's shell. The compounding failure is automation. A pipeline that had one bad night and got `--no-hooks` pasted into its deploy step keeps skipping hooks on every deploy forever, and the chart's migrations quietly stop running across the whole fleet. On `helm uninstall` the risk points the other way: `pre-delete` and `post-delete` hooks are a chart's only chance to deregister from a discovery service, drain a queue or snapshot state. Skipping them removes the release and leaves those side effects behind. ### The chart-authoring alternative If a hook legitimately needs to be optional per install, that is a chart design decision, not an operator flag. Gate the hook manifest on a value: ```yaml {{- if .Values.migrations.enabled }} apiVersion: batch/v1 kind: Job metadata: name: {{ include "gateway.fullname" . }}-schema annotations: "helm.sh/hook": pre-install,pre-upgrade {{- end }} ``` Now the choice is expressed in values, which are stored with the release and visible in `helm get values` — an auditable record of the decision, in exactly the place `--no-hooks` leaves nothing. ### Answering the question well Say what it does in one line, say that it is unselective and reaches subcharts, and then spend your time on the after-care: what you run by hand, how you record that hooks were skipped, and why the flag must never end up in a pipeline definition.

  • Can you skip one hook and keep the rest?
    Not with the flag — it suppresses every hook of the operation, parent chart and subcharts alike. Selectivity is a chart-authoring concern: wrap the hook manifest in a condition on a value, so a caller disables that one Job with `--set migrations.enabled=false`. The choice is then stored with the release and readable through `helm get values`, instead of living only in someone's shell history.
  • You got a stuck upgrade through with --no-hooks. What do you owe the release afterwards?
    Run the skipped work yourself and verify it, because Helm will not: nothing is queued for the next upgrade. Record on the release what was skipped and why — a values change, a ticket, an annotation on the change record — since the history shows an ordinary revision. Then make sure the flag went into a one-off command and not into the pipeline's deploy step.
  • What does --no-hooks change about helm uninstall?
    It skips the `pre-delete` and `post-delete` hooks, which are the chart's only opportunity to act on the way out — deregistering from a discovery service, snapshotting state, releasing a lease. The release's resources are still removed, so you get the deletion without the cleanup, which is usually the opposite of what someone reaching for the flag during an incident wants.

saying these in an interview costs you the question

  • Thinks --no-hooks skips only the failing hook
  • Believes skipped hooks run at the next upgrade
  • Says the flag leaves subchart hooks running
  • Assumes helm history marks a hook-free revision
  • Keeps the flag in the pipeline's deploy step
  • Expects it to delete hook resources already in the cluster

context

resolving links…