Shipping a solution made of several Helm-based products (platform add-ons, operators, integrations) usually means bespoke glue code, fragile ordering, and configs that fall apart between a demo cluster and production. Helmet is a reusable Kubernetes installer framework that treats dependency topology, integration wiring, and configuration as first-class concerns so teams can focus on their charts—not one-off installers.

This session introduces Helmet’s core ideas: chart annotations that drive install order and namespace placement, integration secrets coupled to products via declarative rules, embedded installer bundles, and CLI/MCP workflows that stay consistent from first deploy onward. We will walk through how the same artifact and patterns support a quick demo, a PoC on a shared cluster, and a production rollout—where the main differences are configuration depth and operational gates, not a rewrite of your installer.

You will leave with a mental model of when Helmet fits, how multi-product composition works in practice, and what to plan for as you harden from demo to production (validation, topology inspection, integration lifecycle).

Audience / level: Platform engineers, Kubernetes admins, and teams shipping internal platforms or ISV-style installers; intermediate Kubernetes + Helm familiarity assumed.

Takeaways:

• How Helmet resolves deployment order and integration dependencies from chart metadata.
• How one installer can evolve from demo → PoC → production through config and process, not new code each time.
• Where extensions (integrations, templating, automation/MCP) fit in the lifecycle.
• How you can end up with a production ready gitops repo for day two operation.