Show HN: Glasskube – Open Source Kubernetes Package Manager, alternative to Helm

Original Article ↗ Hacker News Discussion ↗

Relationship to Helm and Current Scope

  • Glasskube currently wraps Helm charts and raw manifests; no independent packaging format yet.
  • Maintainers say they aim for a new format (possibly OCI-based) but prioritize features like multi-namespace dependencies and simplicity for now.
  • Several commenters see this as “Helm-on-Helm” and “YAML-on-YAML,” calling it the worst of both worlds.
  • Confusion over positioning: marketed as a Helm alternative, while docs state it is not a full replacement and still relies on Helm internally.

Config, Templating, and YAML Fatigue

  • Strong dissatisfaction with Helm’s Go-template-in-YAML model: stringy, hard to type-check, and painful to author.
  • Many call for type-safe configuration languages: CUE, Pkl, Jsonnet, Starlark, KCL, Nickel, etc.
  • Debate over declarative, non–Turing-complete config vs general-purpose languages (easier reuse vs harder reasoning at scale).
  • Critics argue that adding another layer of templated YAML (Glasskube config + Helm templates) does not solve core problems.

GitOps, IaC, and Workflow Integration

  • Many users rely on GitOps (ArgoCD/Flux), Helmfile, and Terraform; want everything as code, not “update all” buttons.
  • “Update all” is widely viewed as dangerous in real environments due to nonstandard chart versioning and complex upgrade implications.
  • Glasskube exposes packages as CRDs, supports GitOps workflows, and is working on Renovate integration; Glasskube Cloud aims to comment PRs with resource diffs.

Security, RBAC, and Controllers

  • The PackageController reminds some of Helm 2’s Tiller, which had serious security concerns.
  • Glasskube plans operator-style scoping (inspired by OperatorGroups) to constrain package permissions, while the core controller remains powerful.

What a Kubernetes “Package Manager” Should Be

  • Some argue Helm already fulfills package-manager duties; Glasskube, lacking its own packaging mechanism, is seen more as a frontend/CD tool.
  • Others emphasize the need for: type-safe packages, large curated repos, CRD-aware upgrades, multicluster/fleet support, and better testing and documentation.
  • Several note that true apt/brew-like reliability would require a centrally curated ecosystem and heavy ongoing maintenance, which is hard and not obviously profitable.