Skip to content

Comparison to alternatives

Some comparisons may be outdated as we don't check every release. If any of the tools have improved, please open a PR.

As table

🌊 Helmwave Helmfile Helmsman
Syntax YAML + sprig/gomplate YAML + sprig TOML/YAML
Code style snake_case camelCase camelCase
Requirements No kubectl, helm
helm-diff (optional: helm-secrets, helm-s3, helm-git)		 kubectl, helm
helm-diff
Helm execution function call of bundled helm os.Exec os.Exec
helm diff function call of bundled helm-diff os.Exec os.Exec
Live-tracking k8s resources Kubedog No No
Get application logs Kubedog No No
Get k8s events Kubedog and helm progress No No
Automatically rollback based on metrics monitors No No
Labels tags labels ?
Manage kube-context via iac Yes Yes Yes
Parallel releases Yes Yes Releases with the same priority can be executed in parallel.
Parallel limitations Smart DAG goroutine count with concurrency limitation concurrent helm processes max number of concurrent helm releases to run
Releases dependencies depends_on needs Kind of (priority)
Dependencies cross namespaces via @ via / No
Manage pending strategy Yes No No
Explain graph dependencies Yes No No
Latest image size
Compatible with helm v2 No Yes Yes
OCI registries option in repositories only pull, not login
Lifecycle Hooks Yes (pre_up, post_up, pre_down, post_down, pre_rollback, post_rollback, pre_build, post_build) Yes (prepare, preapply, presync, preuninstall, postuninstall, postsync, cleanup) No
Sub-main config No Yes ?
manage render values renderer option and options for setting delimiters by file extension ?
Remote values HTTP/HTTPS only go-getter ?
Planfile Yes No No
Vault / AWS SSM via gomplate datasources custom functions ?

Why not bare Helm?

Managing multiple environments

Imagine you have multiple environments for same release (e.g. dev, stage, production, etc.). You likely have different settings.

You will likely have bunch of bash scripts that run helm with different values files. It is quite hard to support and improve.

Set up helmwave.yml.tpl to include different values for different environments.

Check out the example

Passing generated values

For example, you need to pass docker image tag.

Either you template values file (e.g. with ansible/jinja2 or any other templater) or you pass every individual value via --set.

Every values file are templated via sprig or gomplate which allows you to generate any values even with external commands.

Check out the example

Install multiple releases

Imagine you need to deploy more than 1 release (e.g. deploy 10+ microservices to dynamic feature environment).

Either deploy releases one-by-one or create an umbrella chart (we think it is bad pattern).

All releases are deployed in parallel with a dependency mechanism.

Check out the example

Managing dependencies between releases

Imagine you need to deploy some DBMS and an app that uses it. While DBMS is provisioning (or scheduling) your app already starts failing probes. It may lead to failing app release.

Manually deploy releases one-by-one.

Use depends_on to set up explicit dependencies between releases.

Release stuck in pending state

If your CI for some reason killed helm process your next helm upgrade will fail because release is in pending-upgrade state.

You need to either do helm rollback (doesn't work for pending-install) or helm delete (destructive in production) and try upgrade one more time.

Use pending_release_strategy to automatically do rollbacks or delete before upgrade if required.

Live-tracking release

You can enable debug logs which will provide you logs of what helm does.

Use kubedog to show status progress.

Check out the example

Why not Helmfile GitHub Repo stars?

We don't consider helmwave as a helmfile killer. Helmfile is an awesome project that really inspired us to implement the same in a bit different way with some other features. Probably there would be no helmwave if there was no helmfile.

Helm execution

Helmfile runs helm via os.Exec. It means that:

  • You need helm binary as well as a lot of other dependencies (e.g. libc). Helmfile's official docker image requires for around 300MB.
  • Helmfile collects, parses and outputs helm stdout/stderr. Any helm backward incompatibility (even occasional) may be a big pain in the ass.
  • os.Exec is not the fastest way to run helm. If 10ns of overhead does really matter to you.

Helmwave runs helm as an internal bundled library. It means that:

  • Helmwave already contains builtin specific (we try to keep it up to date) helm version.
  • There are no helmwave dependencies at all - it can be completely static binary. Official docker image requires for around 30MB. And it can run both in musl and glibc environments.
  • We constantly check out new helm features and try to enhance them in helmwave.

Live-tracking release

Only helm progress is available although there is a discussion about kubedog integration.

Use kubedog to show status progress.

Check out the example

Release stuck in pending state

If your CI for some reason killed helm process your next helm upgrade will fail because release is in pending-upgrade state.

The same as for helm

Use pending_release_strategy to automatically do rollbacks or delete before upgrade if required.

Templating engine

By templating engine we understand collection of builtin functions for default golang templates.

Helmfile only supports sprig as a template engine.

Every values file can be templated via sprig or gomplate (or even non-templated at all). Gomplate is an awesome huge engine that has a lot of features.