Thanks for the thoughtful feedback — these are all fair concerns.

The app doesn’t access your production clusters. Previews run in managed, isolated clusters, and each preview gets its own namespace with deny-all NetworkPolicies, quotas, and automatic teardown. That said, if the concern is about installing charts into any external K8 cluster at all, then I agree this won’t be a fit — and that’s a reasonable constraint.

It’s GitHub-first today simply because that’s where I personally hit the problem. GitLab is supported via the REST API using a personal access token that you can scope as tightly as you want, so you can trigger previews from GitLab CI today.

Native GitLab App integration (auto-triggering on MRs, status updates, etc.) is something I’ve thought about, but I wanted to validate the core workflow first.

It is intentionally Helm-only for now. The specific pain I was trying to solve was reviewing Helm changes — values layering, dependencies, and template changes — by seeing them running in a real environment, rather than trying to generalise across all deployment models.

I’m not trying to replace or compete with Flux or Argo CD. The idea is to validate Helm changes before they land in a GitOps repo or get promoted through environments — essentially answering the question of “does this look OK and actually work when deployed, so should be safe to merge?”

It doesn’t expose rendered manifest diffs today, but I agree that would be valuable — especially a readable “what changed after Helm rendering” view tied back to the PR. I’m still thinking through the cleanest way to do that without adding a lot of complexity to the workflow.

Appreciate you taking the time give your feedback. Thanks.