# Helmify turns kustomize output into a chart, with a name prefix you have to opt out of

> Helmify is a Go CLI that reads Kubernetes manifests from stdin or from files and writes a Helm chart directory. It was built for operator-sdk and kubebuilder projects, but the generated resource names carry the release name prefix unless you pass a flag, which is the first thing to check in the output.

**arttor/helmify** — Creates Helm chart from Kubernetes yaml

- Repository: https://github.com/arttor/helmify
- Stars: 1,744 · Forks: 165
- Language: Go
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/arttor-helmify

## stdin is the primary interface, files are the fallback

Helmify reads a list of supported Kubernetes objects and converts it into a chart directory. The primary shape is a pipe, because that lets it sit at the end of whatever already produces manifests:

```shell
cat my-app.yaml | helmify mychart
```

That writes a directory named after the argument. The same works for kustomize output, which is the case the project was designed around:

```shell
kustomize build <kustomize_dir> | helmify mychart
```

From the filesystem, -f takes a directory or a single file, several sources can be chained, and -r makes a directory scan recursive:

```shell
helmify -f ./first_dir -f ./second_dir/my_deployment.yaml -f ./third_dir  mychart
```

The chart name argument is optional and defaults to chart, and it can be a nested path such as deploy/charts/mychart. That default is why the operator integration documents a chart directory called chart.

If you are combining several flat files with shell tools instead, the README's awk one-liner inserts document separators between files before piping:

```shell
awk 'FNR==1 && NR!=1  {print "---"}{print}' /<my_directory>/*.yaml | helmify mychart
```

## The Makefile integration is the real adoption path

The project is aimed at operator-sdk and kubebuilder projects, and the documented integration is a Makefile target, not a manual command. For operator-sdk older than v1.23.0, the go-get-tool pattern pins the binary:

```makefile
HELMIFY = $(shell pwd)/bin/helmify
helmify:
	$(call go-get-tool,$(HELMIFY),github.com/arttor/helmify/cmd/helmify@v0.3.7)

helm: manifests kustomize helmify
	$(KUSTOMIZE) build config/default | $(HELMIFY)
```

Note the version in that snippet is v0.3.7, older than the current v0.4.20. If you copy it as printed you are pinning an old tool.

For operator-sdk v1.23.0 and newer the pattern changes to install into the local bin directory:

```makefile
HELMIFY ?= $(LOCALBIN)/helmify

.PHONY: helmify
helmify: $(HELMIFY) ## Download helmify locally if necessary.
$(HELMIFY): $(LOCALBIN)
	test -s $(LOCALBIN)/helmify || GOBIN=$(LOCALBIN) go install github.com/arttor/helmify/cmd/helmify@latest
```

The `test -s` guard means an existing binary is kept rather than refreshed, which is convenient locally and a trap in CI where you would rather pin. Either way, make helm regenerates a chart named chart in a chart directory.

## Every resource name gets the release name in front of it

This is the default that surprises people. Generated resource names are prefixed with the chart's release name, which is correct for a Helm chart but breaks anything that refers to those objects by literal name outside the release: an external ServiceMonitor, a NetworkPolicy in another chart, a kubectl command in a runbook, a CI check on a Deployment.

The -original-name flag switches to the object's original name instead of adding the release name prefix. If your manifests carry names that other systems reference, add this flag before you commit the output.

Two other defaults are worth knowing. -crd-dir places custom resource definitions in their own folder, following the Helm 3 docs on letting Helm manage CRDs, and the flag carries an explicit caveat that CRD templating is not supported by Helm, so a templated CRD is not something this layout can give you. -image-pull-secrets lets existing secrets be referenced as imagePullSecrets instead of the chart defining its own.

## What the flags actually control

Beyond the source flags there is a plain verbosity ladder: -v prints WARN and INFO, -vv adds DEBUG, -version prints the version, and -h prints help. There is no output flag, no template override, no values schema and no dry run.

What that absence means is that Helmify generates structure, not design. It decides which files land in templates and which land in crds, but it does not create a values.yaml with knobs, it does not add labels or selectors, and it does not validate that the result installs. The README asks for an issue when a feature is missing for a use-case, which is an honest description of the scope.

The repository layout reflects a normal Go project: cmd/ holds the entry point, internal/ and pkg/ hold the logic, examples/ holds charts generated by the tool including an app and an operator case, and test_data/ holds the fixtures the converter is exercised against.

## Where the generated chart will not work as is

The first limitation is that Helmify converts objects it supports. The README refers to a status table of supported Kubernetes objects, and it says to submit an issue for gaps, which means unsupported kinds are dropped rather than reported loudly. Run with -vv on a first pass and diff the output against your input to see what went missing.

The second is the CRD caveat above. If your CRDs contain substitutions that vary per environment, Helm will not template them, and the crds/ layout commits you to whatever Helm's CRD install behaviour is on your cluster.

The third is name prefixing, already covered, and the fourth is dependency versions. The go.mod pins Go 1.21 and builds against helm.sh/helm/v3 v3.11.2 with the Kubernetes libraries at v0.26.2. Those are compile-time dependencies for parsing, not a claim about your cluster, but a very old Kubernetes API version can mean manifests using newer fields are not recognised.

## How it compares to kustomize overlays and to writing the chart

The alternative approaches are keeping kustomize as the deployment tool, or hand-writing the chart.

Writing the chart directly instead requires creating and maintaining its structure by hand. Helmify is the middle: it skips the mechanical part, where every Deployment becomes a template file, and leaves the design decisions, where the interesting work is. For an operator, where the same chart has to be released and consumed by other teams, a generated starting point that you then review is usually faster than either extreme.

It is also worth noting the release history: v0.4.18 on 2025-03-05, v0.4.19 on 2025-11-06, v0.4.20 on 2026-05-07, and the last push was on 2026-05-07. Patch releases on a 0.x line mean the API can move between minors, so pin the version in CI.

## Conclusion

Adopt Helmify when your source of truth is raw manifests or kustomize output and you want a chart skeleton in one command, especially inside an operator-sdk or kubebuilder Makefile. Do not adopt it expecting a finished, reviewed chart: it generates structure, not design, and the release name prefix, the CRD placement and any values wiring are decisions you still have to make by hand. Before running it in CI, add -original-name if your resources are referenced by name elsewhere, check -crd-dir against how your cluster upgrades CRDs, and confirm your Helm is at least v3.6.0, which is the stated support floor.

## FAQ

### How do I install Helmify?

On macOS or Linux you can use Homebrew with brew install arttor/tap/helmify. Otherwise download a binary for your system from the Releases page, unpack it and add it to your PATH.

### Can Helmify read kustomize output?

Yes. The README documents kustomize build <kustomize_dir> | helmify mychart, which is the case the project was designed around, and the operator-sdk integration pipes $(KUSTOMIZE) build config/default into it.

### Why are my generated resource names prefixed with the release name?

That is the default, because the names have to be unique per release. Pass -original-name to keep the object's original name instead of adding the chart's release name as a prefix.

### What Helm version does Helmify need?

The README states support for Helm >=v3.6.0. The tool is written in Go 1.21 and builds against helm.sh/helm/v3 v3.11.2.

### Does Helmify create a values.yaml with configuration knobs?

The README documents no output, templating or values options, so the generated chart is structure rather than a designed chart. It also offers -crd-dir to keep CRDs in their own folder, with the caveat that Helm does not support templating CRDs.

## Sources

- [arttor/helmify on GitHub](https://github.com/arttor/helmify)
- [Issues](https://github.com/arttor/helmify/issues)
- [License: MIT](https://github.com/arttor/helmify/blob/main/LICENSE)
- [README](https://github.com/arttor/helmify/blob/main/README.md)
- [Releases](https://github.com/arttor/helmify/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/arttor-helmify