Nelm is a Helm 4 alternative built on a rewritten Helm codebase

It is a fork of Helm with the same chart format

Nelm is a Helm 4 alternative, a Kubernetes deployment tool that manages Helm Charts and deploys them to Kubernetes, and it is also the deployment engine of werf. The implementation detail that matters is that it is based on an improved and partially rewritten Helm codebase, which is why the chart and release formats stay compatible while the behaviour changes. The stated goal is to provide a modern alternative to Helm with long-standing issues fixed and many new major features introduced, and the README is explicit that the focus remains on Helm Chart and Release compatibility to ease migration. The claim of production readiness is grounded in the same way: as the werf deployment engine it was battle-tested across thousands of projects for years.

What the rewrite actually adds

The feature list is long and specific, and it reads as a list of things that are awkward in Helm rather than a list of nice-to-haves. There are `terraform plan`-like capabilities with two-stage deployment support, so you can see what would change before anything changes. CRD management is improved, and out-of-the-box secrets management is included rather than left to a separate tool. There are advanced resource ordering capabilities and advanced resource lifecycle capabilities, which together decide what order resources are applied in and what happens to them afterwards. Resource state and error tracking is improved, and there is continuous printing of logs, events, resource statuses and errors during the deployment, so a failed apply tells you what it was doing at the time. The README also claims hundreds of Helm bugs fixed, with the example of the no matches for kind Deployment in version apps/v1beta1 error.

Ordering and lifecycle live in annotations on the resources

This is the mechanism that distinguishes Nelm from a plain apply, and it is documented as a long list of annotation names. The ordering annotations are `werf.io/weight` for the relative order of a resource, `werf.io/deploy-dependency-<id>` to say a resource must be deployed after another, and `werf.io/delete-dependency-<id>` to order deletions. Lifecycle is expressed with `werf.io/ownership` to say which release owns a resource, `werf.io/deploy-on` for a condition on when to deploy, `werf.io/delete-policy` and `werf.io/resource-policy` for what may be deleted, and `werf.io/delete-propagation` for how deletions cascade. There are also failure related annotations, `werf.io/fail-mode`, `werf.io/failures-allowed-per-replica` and `werf.io/no-activity-timeout`, which decide what counts as a failed workload. The advantage of putting this in annotations is that it travels with the resource, so the rules are visible in the manifests rather than in a separate policy file.

Log collection is configured per resource too

The log and metadata annotations are the other large group, and they are what make a deploy log readable. There is `werf.io/log-regex` to filter the collected output, with per-container variants, and `werf.io/log-regex-skip` with a per-container variant to exclude lines. `werf.io/skip-logs` and `werf.io/skip-logs-for-containers` turn collection off entirely for a resource or for named containers. `werf.io/show-logs-only-for-number-of-replicas` and `werf.io/show-logs-only-for-containers` limit what is shown, and `werf.io/show-service-messages` covers the events the service itself emits. The `werf.io/sensitive` and `werf.io/sensitive-paths` annotations mark content that must be redacted, which is the part that matters when a deploy log ends up in a CI artifact. The set is long enough that the README links each one to its own reference section.

Secrets come in two forms

The usage section documents encrypted values and encrypted arbitrary files separately. The template functions section lists the helpers available in values and templates, and the debug-related ones are worth noting: `werf_secret_file` for referencing a secret file, `dump_debug`, `printf_debug`, `include_debug` and `tpl_debug` for diagnostics. A `dump_debug` function in a template engine is the kind of thing that ends up in a commit by accident, so the list of helpers is as much a warning as a reference. The claim that secrets management is out of the box means the encrypted values path is built into the tool rather than requiring a plugin, and the fact that there is a separate encrypted arbitrary files path tells you the scope covers more than values keys.

Feature gates keep the moving parts switchable

Several capabilities sit behind environment variables rather than being on by default, and the README names them. `NELM_FEAT_PREVIEW_V2` turns on the preview of the next major version. `NELM_FEAT_REMOTE_CHARTS` relates to charts being computed remotely. `NELM_FEAT_NATIVE_RELEASE_LIST` and `NELM_FEAT_NATIVE_RELEASE_UNINSTALL` enable the native release list and uninstall behaviour. `NELM_FEAT_PERIODIC_STACK_TRACES` turns on periodic stack trace collection, and `NELM_FEAT_MORE_DETAILED_EXIT_CODE_FOR_PLAN` makes the plan command return a more specific exit code. This is a reasonable pattern for a tool that wants to move quickly, and it is also a way for a user to stay on the older behaviour of a specific area while taking the newer behaviour elsewhere.

A quickstart that shows the two stage flow

The quickstart walks through a chart with a dependency, which is the most realistic shape. You create a directory, write a `Chart.yaml` naming a dependency and its repository, download the dependencies to produce a `Chart.lock`, write a `values.yaml`, and then install the first release:

mkdir mychart
cd mychart

apiVersion: v2
name: mychart
version: 1.0.0
dependencies:
- name: cert-manager
  version: 1.13.3
  repository: https://charts.jetstack.io

nelm chart dependency download

nelm release install -n myproject -r myproject

The final step in the quickstart is planning the second release, which is the two stage workflow in its simplest form: install once, then plan, then apply. The `nelm release install` form with a namespace and a release name is the vocabulary to get used to, and the README notes that Nelm moves fast.

The repository and the release line

The repository is a Go project with a `cmd/` directory, a `pkg/` directory, a `docs/` directory, `resources/` for the images, and `scripts/`. The build is driven by a `Taskfile.dist.yaml` and the releases are managed with release-please, given the `.release-please/` directory and the release-please config file, and there is a `trdl.yaml` with a channels file. The module path is `github.com/werf/nelm/v2` and it requires Go 1.25.0. The dependency list shows the lineage: the Helm-derived libraries such as the sprig template functions, the semver library, the OCI distribution libraries, the Kubernetes client libraries, and a set of smaller utilities. The release history is the thing to look at. The most recent tags are v2.0.1-alpha.3 and v2.0.0-alpha.2 from October 2026, and even the v1.31.1 tag carries an alpha marker, so the current line is prerelease work, and the licence is a custom one GitHub cannot classify with the terms in the LICENSE file.

Editorial conclusion

Adopt Nelm if you are already on Helm and want the two stage deploy, the secrets handling and the resource ordering rules without rewriting your charts, since chart and release compatibility is the stated focus. Do not adopt it while a stable release is what your pipeline needs, because the current tags are alpha versions. Verify first which version you are installing, that the annotations you rely on are not behind a feature gate, and that the encrypted values handling matches how your secrets are produced today.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. werf/nelm on GitHub