Thanks for your input, let me comment on your points one by one. > However things like helmfile with renovate paired with a pipeline is my personal preference

Thanks for your input, let me comment on your points one by one. > However things like helmfile with renovate paired with a pipeline is my personal preference even if just for ensuring things remain consistent in a repo. Glasskube packages can also be put inside a GitOps repository as every package is a CR (custom resource). (They can even be configured via the CLI using the `--dry-run` and `--output yaml` flags and than put into git. In addition we are working on pull request to support package updates via Renovate: https://github.com/renovatebot/renovate/issues/29322 https://github.com/renovatebot/renovate/issues/29322 > The package controller reminds me a lot of Helm tiller with older versions of helm, and it became a big security issue for a lot of companies, so much so that helm3 removed it and did everything clientside via configmaps. Curious how this project plans on overcoming that. As helm3 is now a client side tool only, that means that it can't enforce any RBAC by itself. OLM introduced Operator Groups (https://olm.operatorframework.io/docs/advanced-tasks/operator-scoping-with-operatorgroups/ https://olm.operatorframework.io/docs/advanced-tasks/operato...) which introduces a permissions on an operator level. We might introduce something similar for Glasskube packages. Glasskube itself will still require be quite powerful, but we can than scope packages and introduce granular permissions.