carvel VS helmfile

You should take a look at Carvel maybe something in it could match with your needs.

There's a third option that's quickly rising in popularity, which is Carvel, works great for smaller teams, and allows progressive adoption since it can start as CLI for newer teams learning about gitops concepts.

Carvel (carvel.dev) — featured in opening keynotes.

Huge fan of Carvel tools, it's a whole bunch of them that can help with a wide array of use cases, grab one or two of them for a given scenario, or adopt a bunch that string together to solve larger problems.

+1 been using ytt and kapp, the Carvel stuff in its entirety is a much better experience than helm (it can keep helm to help migration, or deal with the fact everyone still distributes in helm).

Creating Carvel Community which :

https://carvel.dev (and especially the [KAPP](https://carvel.dev/kapp/) piece) is a set of excellent tools to level up on Kubernetes.

Take a look at Kapp on https://carvel.dev/ for this, possibly.

Hopefully this post has helped you make install process smoother, smarter, and made you discover CARVEL tools.

sudo wget https://github.com/helmfile/helmfile/releases/download/v0.159.0/helmfile_0.159.0_linux_amd64.tar.gz sudo tar -xxf helmfile_0.159.0_linux_amd64.tar.gz sudo rm helmfile_0.159.0_linux_amd64.tar.gz sudo mv helmfile /usr/local/bin/

Installation: https://github.com/helmfile/helmfile/releases

What are the benefits over using helmfile? https://helmfile.readthedocs.io/

Helm charts and Helmfile

And now I can just run dudo -l "https://github.com/helmfile/helmfile/releases/download/v{{ version }}/helmfile_{{ version }}_{{ os }}_{{ arch }}.tar.gz" -i /tmp/helmfile.tar.gz -p $HELMFILE_VERSION

I might be misunderstanding your question but we use https://github.com/helmfile/helmfile along with Argo, so essentially between eks and those I could rebuild our entire cluster in minutes.

I am asking which do you choose, Flux or Helmfile. edit: and what criteria do you use to select.

do you publish your own helm chart for your internal services and use it in every environment? if so, you could try to use helmfile within the service's repo itself and store values in a helm/$env directory. then enhance your ci to deploy to dev after the merge/image build phase directly. to try and cut out what sounds like a "deployment/config repo" step you have in the middle that's making everything a pain.

I've used helmfile before to declaratively manage multiple helm charts. It's a higher-level tool, and still uses helm under the hood.