What does helm create scaffold under templates/, and which file is new in Helm 4?
answer
- Eight entries, one of them a directory
- Three of them render nothing by default
- One partial file, one notes file
- A second routing option arrived recently
- A first draft, not a standard
basics
~10 sIt writes deployment.yaml, service.yaml, serviceaccount.yaml, ingress.yaml, hpa.yaml, NOTES.txt, _helpers.tpl and tests/test-connection.yaml. Helm 4 adds httproute.yaml beside ingress.yaml, giving the scaffold a second routing option that is off until its values toggle is set.
solid answer
~40 s`helm create <name>` produces a working chart, and its `templates/` directory is a fixed starter set: `deployment.yaml`, `service.yaml`, `serviceaccount.yaml`, `ingress.yaml`, `hpa.yaml`, `NOTES.txt`, `_helpers.tpl` and a chart test at `templates/tests/test-connection.yaml`. Helm 4 adds `httproute.yaml` next to `ingress.yaml`, so the scaffold now offers two mutually exclusive ways to expose the workload, each guarded by its own values toggle and neither switched on by default. The set is a teaching aid, not a standard: it demonstrates the underscore-partial convention, the one-object-per-file layout, a conditional file that renders to nothing when disabled, and a subdirectory being rendered recursively. Most real charts delete two or three of these files on day one, and nothing about a chart depends on them existing.
code
bash · 2 lineshelm create platform-transcoder-euw-workers
find platform-transcoder-euw-workers/templates -type f | sortgo deeper
Be able to run helm create and name what it wrote: a Deployment, Service and ServiceAccount, optional routing and autoscaling files, the partials file, the notes file and a chart test in a subdirectory.
Explain what each scaffolded file is demonstrating — the underscore partial, the conditional file that renders to nothing, the subdirectory that still renders — and name httproute.yaml as the Helm 4 addition beside ingress.yaml.
Say what you delete and why. Disabled files are cognitive load and an invitation to enable something nobody sized; the partials are the part worth keeping because naming and labelling mistakes are expensive to unwind later.
Decide whether teams start from the stock scaffold at all. A pruned house starter chart with your own labels and conventions removes a repeated pruning decision and makes charts across the estate readable by the same rules.
## The starter set `helm create platform-transcoder-euw-workers` writes a chart that installs and runs without a single edit. Under `templates/` it contains: - **`deployment.yaml`** — the workload, wired to the image, replica count, probes, resources and service-account values. - **`service.yaml`** — a Service selecting the pods through the small selector-label partial. - **`serviceaccount.yaml`** — created by default, with a values switch to turn it off and a name that falls back to `default` when it is. - **`ingress.yaml`** — off by default; renders nothing until its values toggle is enabled. - **`httproute.yaml`** — added in Helm 4, beside `ingress.yaml`, likewise gated behind its own toggle. It is the one genuinely new file in the scaffold. - **`hpa.yaml`** — an autoscaler, off by default. - **`NOTES.txt`** — rendered, but its output is the post-install notes rather than a manifest. - **`_helpers.tpl`** — the partials: `name`, `fullname`, `chart`, `labels`, `selectorLabels`, `serviceAccountName`. - **`tests/test-connection.yaml`** — a chart test, in a subdirectory to show that subdirectories render. Outside `templates/` the same command writes `Chart.yaml`, `values.yaml`, an empty `charts/` directory and `.helmignore`. ## Why the scaffold looks like this Every file in the list is carrying a lesson. `_helpers.tpl` demonstrates that a leading underscore keeps a file's output out of the manifests. `ingress.yaml`, `httproute.yaml` and `hpa.yaml` demonstrate that a file rendering to nothing but whitespace is dropped rather than posted as an empty document — which is why a scaffolded chart installs cleanly with three of its eight template files switched off. `tests/test-connection.yaml` demonstrates the recursive walk. `deployment.yaml` and `service.yaml` demonstrate the one-object-per-file layout and the two-tier label helpers. That framing matters for the interview: the right answer to "what does the scaffold give you" is not just the file list but *what it is illustrating*. An engineer who treats the list as a standard tends to keep files they do not need — a disabled autoscaler and two disabled routing files in a chart for an internal service that is never exposed — because deleting scaffolding feels like deviating from a convention. It is not a convention; it is a demo. ## The Helm 4 delta `httproute.yaml` is the only addition to the template set in Helm 4, and it is there because the scaffold now presents both routing styles instead of assuming one. It sits alongside `ingress.yaml` rather than replacing it, and both stay disabled until their values are set — so a chart created under Helm 4 and one created under Helm 3, both left at defaults, install the same objects. Anyone answering that Helm 4 renamed commands, changed the chart layout or moved `templates/` is confusing the scaffold with the release-time changes: the top-level command set is identical to Helm 3, and the chart directory layout is unchanged. ## What to do with it Treat `helm create` as a first draft. Read every file, delete the ones your service does not need, and be deliberate about the partials — the `name`, `fullname` and label helpers are the parts most worth keeping, because they encode the naming and labelling rules that are painful to get wrong later. If your organisation ships many charts, the productive move is a house starter chart derived from the scaffold once, with the unused files removed and your own labels added, rather than each team pruning the same generated files in a slightly different way. ## A common misreading The scaffold is often mistaken for the minimum a valid chart needs. A chart needs a `Chart.yaml`; everything else, `templates/` included, is optional. A library chart has no rendered templates at all, and a chart that ships only CustomResourceDefinitions has an empty `templates/` directory. Knowing that the starter set is generous rather than minimal is what separates someone who has written a chart from someone who has only run the command.
- How many of the scaffolded template files actually produce objects on a default install?Four: the Deployment, the Service and the ServiceAccount, plus the chart test manifest, which is only created when `helm test` runs. `ingress.yaml`, `httproute.yaml` and `hpa.yaml` are off by default and render to nothing, `_helpers.tpl` is skipped by name, and `NOTES.txt` becomes the post-install notes rather than a manifest.
- Is a templates/ directory required for a chart to be valid?No. Only `Chart.yaml` is required. A library chart declares partials and renders nothing; a chart that ships only CustomResourceDefinitions can have an empty `templates/`. The scaffold is a generous starting point that demonstrates the conventions, not a definition of the minimum a chart must contain.
- Would you keep the scaffolded files you do not use?No — delete them. Every disabled file is something a future reader has to open and rule out, and a disabled autoscaler or routing file invites someone to enable it without understanding the service. If many teams ship charts, prune the scaffold once into a house starter chart rather than having each team make the same edits differently.
saying these in an interview costs you the question
- Treating the scaffolded file set as a chart standard
- Believing a chart must have a templates/ directory
- Saying Helm 4 changed the chart directory layout
- Thinking the scaffolded routing files are enabled by default
- Claiming helm create writes no chart test
- Assuming every scaffolded file produces an object