Vienna DevOps Meetup 01/2025: Auto-Updating Dependencies & Building a Kubernetes Packet Manager

Thanks for hosting, and thanks to KECH for providing the venue.

My talk today is about one year of building a package manager for Kubernetes.

Before we dive in, a quick question—who here has either created an open-source project and maintains it actively or regularly contributes to one?

[A few hands go up]

Okay, cool. Nice! Now, let’s go over the story of how we created this open-source project and what we learned after a year of development.

[Background]

For those who don’t know me, my name is Philli. I’m one of the co-founders of Glass Cube, the company behind the open-source project I’ll be talking about today. I have a traditional background in computer science, having studied at the Vienna University of Technology. Before founding Glass Cube, I was the CEO of an alerting company that built systems for firefighter organizations and emergency alerting in enterprise environments.

Glass Cube started two years ago out of an interest in DevOps tooling and open-source projects. But before diving into Kubernetes and deployment challenges, let’s talk about Helm, the de facto package manager for Kubernetes. I think everyone here has used Helm at some point, right?

[Audience nods]

Great! Now, a little history of Helm that I found interesting:

• Helm was created in 2015 by Deis Labs during a hackathon.
• The original name had an alcohol theme, but they later changed it.
• In 2016, Google’s Deis Deployment Manager merged with Helm, and Helm 2.0 was released with a server-side component.
• In 2018, Helm 3.0 was released, removing the server-side component, citing security concerns and custom resource management issues.
• In 2022, Helm started supporting OCI images.
• Recently, I attended the Helm 4.0 kickoff at KubeCon in Salt Lake City, where the Helm community (led by enterprises like SUSE and Red Hat) discussed upcoming changes. However, they agreed not to introduce major breaking changes, which is great for stability but limits the ability to fix long-standing issues.

[Our Experience with Helm]

When we first started working with Helm charts, we assumed it would be straightforward. Instead, we found:

• Go templating was overly complex.
• Dependencies across multiple namespaces often failed.
• Helm charts frequently got stuck in weird states.

Frustrated, we wrote a blog post about Helm’s pitfalls and published it on Hacker News. It received 133 upvotes and sparked a discussion with 180+ people commenting about Helm’s downsides.

We thought, wait a minute—we’re working on an app marketplace, but this package management problem is clearly something many people care about. So we made a bold decision:

💡 We decided to go all in on building a better package manager.

[Building Glass Cube]

When we started, we had some big challenges:

• None of us had written Go code before.
• We had no internal knowledge of Helm’s history or contributors.
• We had never managed massive, multi-tenant, high-security Kubernetes clusters.

Still, we believed in our core ideas:

1. A better dependency system
2. A GUI for easier management
3. A centralized package repository

Six months later, we launched our first MVP. It had many limitations:

• Only cluster-scoped packages
• No multi-namespace support
• No package configuration options

Despite this, we released it, and it gained traction fast. Glass Cube started trending on GitHub, people joined our Discord, and the community grew quickly.

[Lessons from Open Source]

One of the biggest takeaways from launching an open-source project is community engagement. To build momentum:

✅ Have good first issues for contributors. ✅ Write clear contribution guidelines. ✅ Organize community calls.

By doing this, we attracted contributors who helped improve Glass Cube.

[Technical Challenges & Solutions]

To solve dependency management and automated updates, we built an automated CI/CD workflow:

1. Glass Cube Scout: A CLI tool that scans for new package versions.
2. GitHub Actions for CI/CD: Runs Minikube tests before merging updates.
3. Renovate Integration: We contributed to Renovate so it natively supports Glass Cube packages.
4. Package Controller: Manages dependencies and reconciles installations in Kubernetes.

[Adoption and Challenges]

After a year, Glass Cube is running in major cloud providers and large enterprise clusters. However, open-source adoption is tricky:

• Large enterprises fork the project for internal use but rarely contribute back.
• Companies want package management + support, leading to business opportunities.

[The Future of Glass Cube]

Are we as big as Helm? Not yet.

A key realization: Kubernetes is no longer a greenfield technology. Most companies already have existing deployment pipelines. This makes it harder to introduce a completely new package manager.

However, for greenfield projects, Glass Cube is gaining traction. New Kubernetes users want a clean package management approach, and that’s where we fit in.

[Lessons for Open-Source Developers]

1. Make noise early – Generate interest and engagement.
2. Users ≠ Contributors – Some contribute for learning, but adoption requires enterprise features.
3. Open-source monetization is tricky – Multiple corporate sponsors are ideal for long-term sustainability.

We love developer tooling and open source, and we’re launching our next big tool tomorrow!

While Helm remains dominant, we believe there’s room for alternative solutions. Glass Cube isn’t replacing Helm—it complements it. The Kubernetes ecosystem is big enough for multiple package managers, and we’re excited about the future.

Thank you!

[Applause]