Glasskube

Glasskube is an open-source package manager for Kubernetes that brings the simplicity of Homebrew and npm to cluster workload management. It replaces the fragmented, error-prone workflow of Helm charts and raw manifests with a unified interface that handles installation, configuration, dependency resolution, and safe updates in a single cohesive system.

At its core, Glasskube introduces two Kubernetes Custom Resource Definitions—Package and PackageInfo—that represent installed workloads as first-class cluster objects. This means every deployment is version-controlled, GitOps-compatible by default, and reconcilable by any controller like Argo CD or Flux without additional tooling or adapters.

The tool ships with both a terminal CLI and a web-based GUI served locally via glasskube serve. The GUI lets platform teams browse the full package catalog, inspect dependency trees, configure typed values injected from ConfigMaps or Secrets, and review pending updates before applying them. The interactive CLI questionnaire mirrors this experience for engineers who prefer the terminal.

Glasskube supports public repositories including Artifact Hub and private repositories for internal services, with Secret-backed authentication baked into the CRD model. It integrates with Renovate for automated dependency update PRs, and is listed in the CNCF Landscape.

What You Get

• Web GUI Package Browser - A locally-served web interface built with HTMX and Bootstrap that lets you discover, install, configure, and monitor Kubernetes packages with visual dependency trees and real-time reconciliation status—no Helm repository searching required.
• Typesafe Package Configuration - Interactive CLI questionnaires and UI forms with validated, schema-driven input fields that replace untyped values.yaml files, supporting injection of values from ConfigMaps and Kubernetes Secrets.
• Automatic Dependency Resolution - A graph-based dependency manager that resolves, validates, and installs transitive dependencies in the correct namespaces before applying the requested package, preventing silent breakage from unresolved requirements.
• Previewable, Test-Validated Updates - All package updates are pre-tested by the Glasskube test suite and displayed as previews before applying; updates are performed in a single click or CLI command with full version control.
• Native GitOps CRDs - Package and PackageInfo custom resources integrate directly with Argo CD, Flux, and Renovate, enabling fully declarative, pull-request-driven cluster management without any adapter layers.
• Multi-Repository and Private Package Support - Configure public repositories via Artifact Hub or host private package repositories for internal services, with Secret-backed authentication managed directly in the Kubernetes API.
• Renovate Integration - Automatic update PRs for package versions via Renovate, allowing teams to adopt a GitOps-first update strategy with automated dependency bump pull requests.

Common Use Cases

• Platform team managing shared infrastructure - A platform team bootstraps Glasskube in a shared cluster and uses it to centrally manage cert-manager, ingress-nginx, and the Kube Prometheus Stack for multiple development teams, ensuring consistent versions and applying safe updates cluster-wide with one command.
• Internal service distribution at scale - An engineering organization publishes private Glasskube packages for internal databases and APIs, giving developers a one-command install experience without needing to clone and template Helm charts or write custom deployment manifests.
• GitOps-driven cluster upgrades - A DevOps team commits Glasskube Package CRs to their Git repository and lets Renovate automatically open PRs for version bumps; Argo CD applies the changes to staging and production clusters after review, with Glasskube handling dependency resolution automatically.
• Kubernetes onboarding for development teams - New engineers install full monitoring stacks like Kube Prometheus through the Glasskube GUI in minutes, without needing deep knowledge of Helm flags, Kustomize overlays, or namespace management.
• Dependency-aware multi-package deployments - An operator installs a complex application that depends on CloudNativePG and cert-manager; Glasskube automatically resolves, orders, and installs all transitive dependencies in the correct namespaces before deploying the top-level package.

Under The Hood

Architecture Glasskube follows a clear layered architecture with three distinct execution contexts: a Cobra-based CLI that validates user inputs and writes Kubernetes CRs, a web server that serves the GUI and mirrors CLI operations via HTTP handlers, and a Kubernetes operator that runs in-cluster and reconciles Package, PackageInfo, and PackageRepository custom resources. These three layers share a common pkg/ library but remain independently deployable. The dependency graph lives in internal/dependency/graph, the manifest fetching and repository authentication in internal/repo, and the Kubernetes reconciliation loop in internal/controller. Separation of concerns is enforced at the package boundary: internal packages are not importable from outside the module, and the adapter pattern isolates the controller from the Kubernetes client implementation, enabling mock-based testing.

Tech Stack The entire backend is written in Go 1.23 with CGO disabled, producing statically-linked binaries packaged in distroless containers for minimal attack surface. Kubernetes integration is built on controller-runtime and kubebuilder, with CRDs, RBAC manifests, and webhook configurations auto-generated via controller-gen annotations. The web GUI is served directly from the Go binary using embedded templates and assets compiled via esbuild from JavaScript and CSS sources; the frontend uses HTMX for server-driven interactivity and Bootstrap for styling. Build automation runs through Goreleaser for multi-arch binary releases, Renovate for automated dependency updates, and GitHub Actions for CI. The Masterminds semver library handles constraint resolution, and FluxCD’s helm-controller and source-controller APIs are used for Helm-backed package deployments.

Code Quality The codebase has extensive BDD-style test coverage using Ginkgo and Gomega, including realistic Kubernetes client mocks for controllers and validating webhooks. Core logic in dependency resolution, semver comparison, manifest value validation, and package reconciliation all have dedicated test suites. Type safety is strong throughout: API types are explicitly defined with JSON struct tags and kubebuilder markers, custom error types wrap domain failures, and interface-based dependency injection in the adapter layer makes units independently testable. Naming follows Kubernetes conventions consistently. Some test suites use environment-bootstrapped test clusters via envtest but have limited assertion density; the overall testing posture is solid for a young project.

What Makes It Unique Glasskube’s core innovation is treating every installed workload as a Kubernetes Custom Resource rather than an external package manager artifact, which means the full cluster state is expressible as Git-versionable YAML without any separate lock files or state databases. The automatic dependency graph resolution operates at the cluster level, aware of what is already installed and in which namespace, preventing the duplicate-install and version-conflict problems common with Helm umbrella charts. The Secret-backed repository authentication model integrates credential management directly into the Kubernetes API, avoiding out-of-band credential stores. The combination of a locally-hosted GUI with deep in-cluster awareness—showing live reconciliation status, dependency trees, and one-click YAML clipboard export—gives operators a self-hosted management plane that stays current without requiring any cloud connectivity.

Self-Hosting

Glasskube is released exclusively under the Apache License 2.0, a permissive open-source license with no copyleft implications. Organizations can use, modify, distribute, and run Glasskube commercially without any obligation to open-source their own code or pay licensing fees. There is no dual-licensing, open-core model, or feature-gated enterprise edition—every capability in the repository is available to every user under the same terms.

Running Glasskube yourself requires access to a Kubernetes cluster and the ability to install CRDs and deploy an in-cluster operator. The glasskube bootstrap command handles the initial installation of the Glasskube operator and required resources. After that, operators are responsible for the Kubernetes cluster itself—availability, node scaling, backups, and API server uptime all fall on the self-hosting team. The GUI is served from the local machine via glasskube serve rather than running as a persistent in-cluster workload, which means it is only available when a team member is actively running it. There is no built-in authentication for the GUI beyond Kubernetes RBAC, so network exposure must be managed externally.

As of early 2025, a Glasskube Cloud offering was launched for teams that prefer a managed experience, but the open-source tool itself remains fully functional without it. The self-hosted path gives complete control over package versions, private repositories, and GitOps workflows, with no telemetry or call-home requirements beyond optional PostHog analytics that can be disabled. Teams evaluating the trade-off should account for the operational overhead of managing the underlying cluster and the lack of a persistent web UI—aspects that the managed cloud tier addresses for organizations prioritizing reduced operational burden.