Skip to main content
In this lesson we cover how Glasskube’s multi-repository feature improves package lifecycle management by enabling discovery, testing, and governance across public and private registries. You will learn how to list repositories, add public or private repositories, and configure authentication for private backends. By default, Glasskube points to the Glasskube Hub — a public, curated package repository maintained by the Glasskube team on GitHub.
This image shows a GitHub repository page for "glasskube/packages," displaying files, commit messages, and repository statistics like stars and forks.
Glasskube’s multi-repository capability lets you connect additional repositories (public or private). Typical scenarios include hosting organization-specific packages, creating team registries, or isolating dev/test/staging package flows before promoting to production.
The image shows two gradient-colored squares labeled "Public" and "Private." The left square is blue, and the right square is orange.
Common use cases
  • Host organization-specific packages in a private repository.
  • Create team-level repositories for independent development and controlled sharing.
  • Maintain dev/test/staging registries and promote to production once validated.
Quick repository overview Use the CLI to view repositories Glasskube currently knows about and the number of packages each exposes:
How Glasskube discovers packages Glasskube expects a raw YAML index file (commonly index.yaml or packages) containing metadata for each package: name, latest version, short description, and optionally an icon URL. Point Glasskube at the raw file URL (for example, https://raw.githubusercontent.com/user/repo/branch/path/index.yaml) so it can parse package metadata directly. Avoid pointing to GitHub HTML pages or directory URLs. Example index YAML (trimmed):
Glasskube parses the raw YAML index directly. Use the repository’s raw file URL (for example, https://raw.githubusercontent.com/.../index.yaml) — do not use GitHub UI or directory URLs since those return HTML, not the raw YAML.
Add a public repository To add a public, no-auth repository use:
After adding a repository, verify it is listed and that Glasskube detected packages:
UI behavior with multiple repositories When multiple repositories are configured, the Glasskube UI and CLI will show packages from all configured backends and allow selecting a specific repository/version when installing.
The image shows a webpage interface for installing "ingress-nginx," an Ingress controller for Kubernetes using NGINX. It includes options to select a repository and version for installation.
If only the default repository is configured, some UI package views will not show a repository selector since there is only one backend configured.
The image shows a user interface for Glasskube, displaying various Kubernetes-related packages available for installation, some of which are already installed.
Authentication for private repositories Glasskube supports three authentication methods for private repositories: If you run glasskube repo add without an --auth value when one is expected, the CLI will return usage help:
Example: add a private GitHub repository using a bearer token Non-interactive (supply token on CLI):
Interactive (Glasskube prompts for token):
Creating a GitHub personal access token
  1. In GitHub, go to Settings → Developer settings → Personal access tokens.
  2. Create a token with the minimum scope required (prefer repository-read access or fine-grained tokens scoped to the packages repository).
  3. Use that token with --token or enter it interactively when prompted.
The image shows a GitHub page for creating a new personal access token, with options to set a note, expiration date, and select access scopes.
After adding a private repository with valid credentials, glasskube repo list will include the AUTH column and show the detected package count:
Installation selection and workflows Once multiple repositories are configured, you can explicitly choose which repository to install a package from in the Glasskube UI or specify it via CLI. This supports workflows such as installing a package from a staging repository for testing before promoting it to the production registry. Summary Glasskube’s multi-repository support gives you the flexibility to:
  • Aggregate public and private package sources,
  • Segregate dev/test/staging registries,
  • Implement team or org-level package governance,
  • Promote packages between repositories as part of your release workflows.
Try adding a public and a private repository to see package discovery, authorization behavior, and the UI repository selector in action.
Always protect access tokens and follow least-privilege principles. Prefer fine-grained tokens or repository-scoped access when possible, and avoid embedding tokens in shared scripts or version control.
Links and references

Watch Video

Practice Lab