I don’t fully understand the problem this is trying to solve. Or at least, if this solves your problem then it feels like you have bigger problems?
If you have staging/production deployments in CI/CD and have your Kubernetes clusters managed in code, then adding feature deployments is not any different from what you have done already. Paying for a third party app seems (to me) both a waste of money and a problem waiting to happen.
How we do it: For a given helm chart, we have three sets of value files; prod, staging and preview. An Argo application exists for each prod, staging and preview instance.
When a new branch is created, a pipeline runs that renders a new preview chart (with some variables based on branch/tag name), creates a new argo application and commits this to the kubernetes repo. Argo picks it up, deploys it to the appropriate cluster and that’s it. Ingress hostnames get picked up and DNS records get created.
When the branch gets deleted, a job runs to remove the argo application and done.
It’s the same for staging and production, I really wouldn’t want a different deployment pipeline for preview environments - that just increases complexity and the chances of things going wrong.
Thanks for the feedback. I agree your setup sounds solid.
What you're describing - different values, Argo apps per branch, pipelines that create and clean up - absolutely works. In my experience though, getting to that point involves a lot of work: Argo setup, application generation per branch, DNS and ingress wiring, and ongoing maintenance. It's reliable once built, but non-trivial to design and keep running.
The scope of what I'm trying to solve is narrower. In my case, Helm chart changes (often from external contributors) were hard to review because validating them meant manually standing up environments or spinning up short-lived clusters. Many reviewers couldn't realistically run the pipeline themselves, so reviews often stalled. That was the core motivation.
This isn't aimed at teams that already have a mature GitOps setup like yours — I agree Chart Preview probably won't add much value there. It's for teams that don't have that infrastructure yet, or don't want to invest in building and maintaining it, and want to get to the same outcome with less effort.
I appreciate you taking the time to describe your approach — it's a good reference point for where many teams eventually end up.