[Sandbox] HelmForge

[mberlofa]

Project summary

HelmForge is an open-source Helm chart ecosystem for running production-oriented Kubernetes applications with official upstream images, explicit values contracts, built-in operational patterns, and verifiable releases.

Project description

HelmForge provides production-ready Helm charts for self-hosted applications and platform workloads on Kubernetes. The project focuses on a practical gap in the cloud-native ecosystem: operators need maintained charts that use official upstream container images, keep configuration contracts understandable, and include day-2 operational concerns such as backup, observability, security defaults, schema validation, and signed releases.

HelmForge currently maintains 62 charts across databases, messaging, identity, AI tooling, automation, CMS, analytics, networking, monitoring, and self-hosted applications. The charts are designed around the application domain rather than raw Kubernetes primitives. For example, database charts model standalone, replication, sentinel, or cluster topologies explicitly, while application charts expose product-oriented settings for ingress, persistence, databases, credentials, SMTP, metrics, backup, and restore workflows.

The project deliberately uses official upstream images instead of proprietary rebuild layers, pins image tags, publishes to both a standard HTTPS Helm repository and OCI registry, signs releases with GPG provenance and Sigstore Cosign, validates all charts with Helm lint, Helm unit tests, kubeconform, Artifact Hub linting, and maintains a public documentation website with chart pages, playground tooling, roadmap, changelog, and comparison guidance.

HelmForge is needed because the community has a growing need for open, transparent, Kubernetes-native packaging that remains vendor-neutral and operationally useful after installation.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/helmforgedev

Project repo URL in scope of application

• https://github.com/helmforgedev/charts

Additional repos in scope of the application

Website URL

https://helmforge.dev

Roadmap

https://helmforge.dev/roadmap

Roadmap context

HelmForge's public roadmap is organized around four workstreams:

• Foundation: completed core database charts, S3-compatible backup CronJobs, GPG provenance, Cosign-signed OCI artifacts, automated semantic versioning, release notes, and Artifact Hub integration.
• Growth: completed broad application coverage, including databases, identity, automation, networking, AI/ML, content platforms, and a website with docs, playground, and stack builder.
• Resilience and scale: planned HA and multi-region deployment patterns, deeper monitoring and alerting integrations, operator-based lifecycle management, Terraform and Pulumi modules, and policy/compliance templates for OPA and Kyverno.
• Ecosystem: planned GitOps-native install flows for Argo CD and Flux, chart dependency graph, compatibility matrix, community chart contribution pipeline, cloud marketplace listings, and interactive tutorials.

The roadmap direction is to evolve HelmForge from a chart repository into a neutral cloud-native packaging and operations layer for teams that want standard Helm, standard Kubernetes APIs, official images, reproducible releases, and documented operational tradeoffs.

Contributing guide

https://github.com/helmforgedev/charts/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/helmforgedev/.github/blob/main/CODE_OF_CONDUCT.md

Adopters

https://github.com/helmforgedev/charts/blob/main/ADOPTERS.md

Maintainers file

https://github.com/helmforgedev/charts/blob/main/MAINTAINERS.md

Security policy file

https://github.com/helmforgedev/.github/blob/main/SECURITY.md

Standard or specification?

N/A.

HelmForge does not define a new standard or specification. It packages cloud-native workloads using existing standards and APIs: Helm chart API v2, Kubernetes stable APIs, OCI registries, Sigstore Cosign, GPG provenance, JSON Schema for values validation, Prometheus Operator CRDs where optional metrics integration is enabled, and standard S3-compatible object storage APIs for backup targets.

Business product or service to project separation

This project is unrelated to any commercial product or paid service. HelmForge is developed as an open-source project under the helmforgedev GitHub organization and is distributed under the Apache License 2.0.

The project does not currently have an open-core edition, hosted commercial control plane, proprietary chart tier, or enterprise-only feature set. All charts, documentation, CI workflows, tests, examples, release automation, and repository metadata are public. The project publishes standard Helm packages through an HTTPS chart repository and OCI artifacts through GHCR, allowing users to deploy without dependency on a commercial service.

If accepted into CNCF, the project should be prepared to align governance, trademarks, repository ownership, domains, and accounts with CNCF requirements.

Why CNCF?

HelmForge is directly aligned with CNCF's mission to make cloud-native computing ubiquitous, sustainable, open, and vendor-neutral. The project exists at the intersection of Kubernetes packaging, application delivery, supply chain security, platform operations, and self-hosted infrastructure: all areas where CNCF projects and working groups already provide critical foundations.

Joining CNCF would provide HelmForge with:

• Neutral governance for a project intentionally positioned as vendor-neutral infrastructure packaging.
• A broader community of maintainers, reviewers, users, and adopters beyond the current founding maintainers.
• Better alignment with CNCF projects that HelmForge already complements, including Helm, Kubernetes, Prometheus, Argo CD, Flux, cert-manager, OpenTelemetry, Kyverno, OPA, Sigstore, Falco, and storage projects used by Kubernetes clusters.
• A venue for collaboration with TAG App Delivery, TAG Security, TAG Storage, and TAG Runtime around packaging standards, supply chain trust, backup/restore expectations, and operational maturity for Helm-based software distribution.
• Increased user trust for organizations evaluating HelmForge as a replacement or complement to vendor-managed chart ecosystems.

HelmForge chose CNCF because the project is fundamentally about helping users run cloud-native workloads with open tooling and standard Kubernetes primitives. CNCF is the natural home for a community chart ecosystem that emphasizes neutrality, transparency, verifiability, and production operations.

Benefit to the landscape

HelmForge benefits the Cloud Native Landscape by filling a practical and timely gap: a broad, open chart ecosystem that uses official upstream images, avoids vendor-specific runtime layers, and treats operational readiness as part of the chart contract.

The differentiators are:

• Official upstream images: charts prefer the images published by the application maintainers, reducing the supply chain middle layer and preserving compatibility with upstream documentation.
• Pinned image versions: chart defaults use explicit image tags instead of floating tags.
• Product-oriented values: values are designed around application concepts such as database mode, domain, admin settings, SMTP, backup, replication, metrics, and ingress instead of only exposing raw Kubernetes knobs.
• Built-in backup: 38 charts include optional S3-compatible backup CronJobs, providing a consistent backup starting point across applications and databases.
• Schema validation: every chart includes values.schema.json, making configuration errors easier to catch before deployment.
• Verifiable releases: charts are published through both HTTPS Helm repository and OCI registry, with GPG provenance for Helm verification and Cosign signatures for OCI artifacts.
• CI-backed quality gates: chart changes are validated with Helm lint, strict linting, template rendering across CI values, helm-unittest, kubeconform, and Artifact Hub lint.
• Public docs and operator guidance: chart READMEs and site docs document supported architectures, limits, non-goals, backup/restore behavior, and production notes.

The landscape already has Helm as a package manager and many individual charts, but there is room for a CNCF-aligned chart distribution that is explicitly open, application-aware, signed, tested, and designed for operators who want to avoid lock-in to commercial image rebuild ecosystems.

Cloud native 'fit'

HelmForge is cloud-native by design:

• It packages Kubernetes workloads as Helm charts using standard Kubernetes APIs.
• It supports declarative configuration through values.yaml, JSON Schema, examples, and CI scenario files.
• It embraces OCI distribution for charts and standard HTTPS Helm repositories for existing workflows.
• It integrates with Kubernetes primitives such as Deployments, StatefulSets, DaemonSets, Jobs, CronJobs, Services, Ingress, Gateway API HTTPRoutes, RBAC, NetworkPolicy, PodDisruptionBudget, HPA, VPA, KEDA ScaledObjects, ConfigMaps, Secrets, PersistentVolumeClaims, and ServiceAccounts.
• It supports observability patterns through optional metrics sidecars, ServiceMonitor, PodMonitor, PrometheusRule, and Grafana-related resources in applicable charts.
• It supports day-2 operations through backup CronJobs, documented restore guidance, persistence controls, resource presets, securityContext, podSecurityContext, topology spread, anti-affinity, and chart-specific operational boundaries.
• It reinforces supply chain trust with signed chart packages, OCI signatures, pinned images, release notes, and deterministic publishing workflows.

HelmForge fits primarily in the App Definition and Development / Application Definition and Image Build / Package Management areas of the landscape, with strong adjacency to Platform, Observability, Security and Compliance, and Database categories.

Cloud native 'integration'

HelmForge complements and integrates with several CNCF projects:

• Kubernetes: primary runtime target and API substrate for all charts.
• Helm: core packaging format and installation workflow.
• Artifact Hub: chart discovery and metadata publication.
• Sigstore Cosign: keyless signing for OCI chart artifacts.
• Prometheus and Prometheus Operator: optional ServiceMonitor, PodMonitor, PrometheusRule, and metrics integration in applicable charts.
• OpenTelemetry: roadmap-aligned observability integration opportunity for traces, metrics, and logs.
• Argo CD and Flux: GitOps-native installation is on the roadmap, and HelmForge charts are already suitable for GitOps deployment.
• cert-manager: commonly used with HelmForge ingress and TLS workflows.
• Envoy Gateway and Gateway API: HelmForge includes an Envoy Gateway chart and the generic chart supports Gateway API HTTPRoutes.
• OPA and Kyverno: policy/compliance templates are on the roadmap.
• Falco: runtime security policy and detection alignment opportunity.
• KEDA: supported by the generic chart for event-driven scaling.
• Rook, Longhorn, OpenEBS, and Kubernetes CSI implementations: relevant for persistence-backed charts and backup/restore workflows.
• Velero: HelmForge includes a Velero chart and complements cluster-level backup with application-level backup CronJobs.

Cloud native overlap

HelmForge overlaps with Helm only in the sense that it uses Helm's packaging format; it does not replace Helm. HelmForge is a chart ecosystem and operational distribution, while Helm is the package manager.

HelmForge overlaps with Artifact Hub only as a publisher of chart metadata; it does not replace chart discovery.

HelmForge overlaps with Flux and Argo CD as an input source for GitOps workflows, not as a reconciler or deployment controller.

HelmForge overlaps with operators such as CloudNativePG, Strimzi, and other domain-specific operators only for some workload categories. The project explicitly documents where a Helm chart should not pretend to be an operator. For example, PostgreSQL replication is documented as fixed-primary asynchronous read scaling and operational recovery support, not automatic failover or cluster management.

HelmForge overlaps with existing community and vendor chart repositories, especially Bitnami charts, but differentiates through official upstream images, Apache-2.0 licensing, GPG + Cosign signing, values schema on every chart, built-in backup across many charts, and documented operational boundaries.

Similar projects

Similar or related projects include:

• Bitnami Charts: broad chart catalog, but tied to Bitnami-maintained images and commercial image distribution changes.
• TrueCharts: community chart ecosystem, especially for self-hosted and homelab use cases.
• Delivery Hero public Helm charts and other organization-specific chart repositories.
• Individual upstream charts maintained by application projects.
• Helm's stable/incubator chart history, which demonstrated the need for shared chart ecosystems but is no longer maintained in that form.
• Operator-based projects such as CloudNativePG, Strimzi, Zalando Postgres Operator, RabbitMQ Cluster Operator, and others. HelmForge complements these and intentionally recommends operators when reconciliation, failover, or lifecycle automation requires a controller.

Landscape

HelmForge is not currently listed on the CNCF Cloud Native Landscape.

Insights

HelmForge is not currently listed on LFX Insights.

Trademark and accounts

• If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

IP policy

• If the project is accepted, I agree the project will follow the CNCF IP Policy

Will the project require a license exception?

No.

Current project code is Apache-2.0 licensed. HelmForge has migrated project code and chart metadata to Apache-2.0 to align with the CNCF IP Policy. Documentation licensing can be further aligned with CNCF onboarding guidance if required.

Dependencies and packaged upstream software should also be reviewed against the CNCF allowed third-party license policy. HelmForge charts package metadata and Kubernetes manifests, while the deployed application images retain their upstream licenses and are not redistributed as HelmForge-owned project code unless explicitly maintained in HelmForge support repositories.

Project "Domain Technical Review"

No TAG review has been completed yet.

Recommended outreach before or shortly after submitting:

• TAG App Delivery: Helm chart ecosystem, application packaging, GitOps compatibility, values contracts, release/distribution workflows.
• TAG Security: signed releases, supply chain provenance, security policy, image pinning, vulnerability response boundaries.
• TAG Storage: database charts, persistence, backup/restore patterns, application-level backups, restore documentation.
• TAG Runtime: Kubernetes runtime assumptions, pod security defaults, runtime compatibility, deployment patterns.

Application contact email(s)

• berlofa@helmforge.dev
• maicon.berloffa@gmail.com

Contributing or sponsoring entity signatory information

Submitting as an individual:

Name	Country	Email address
Maicon Berlofa	Brazil	berlofa@helmforge.dev / maicon.berloffa@gmail.com

CNCF contacts

No CNCF TOC/TAG contacts are currently confirmed as familiar with the project.

Additional information

Current project signals as of April 27, 2026:

• Public project website: https://helmforge.dev
• Organization scope: https://github.com/helmforgedev
• Primary repository: https://github.com/helmforgedev/charts
• Public Helm repository: https://repo.helmforge.dev
• Artifact Hub package listing: https://artifacthub.io/packages/search?repo=helmforge
• OCI registry namespace: ghcr.io/helmforgedev/helm
• Artifact Hub repository metadata: https://github.com/helmforgedev/charts/blob/main/artifacthub-repo.yml
• Repository license: Apache-2.0
• Chart count: 62
• Stable charts: 58
• Backup-capable charts: 38
• Primary language: Go Template
• Repository topics include: helm, helm-charts, kubernetes, oci, production-ready, self-hosted, cosign, devops, k8s, open-source
• Recent activity: more than 1,200 commits in the local repository history, active releases, and recent successful CI/publish workflows.

Repository quality and governance signals:

• Every chart includes values.schema.json.
• Every chart has a tests/ directory and ci/ scenarios.
• CI validates changed charts with Helm lint, strict linting, default rendering, CI scenario rendering, helm-unittest, kubeconform, and Artifact Hub lint.
• Publishing calculates semantic versions from Conventional Commits per chart.
• Published charts are signed with GPG provenance and OCI artifacts are signed with Sigstore Cosign.
• Chart releases create GitHub Releases with generated release notes and install commands.
• The project documents contributor workflow, required validation, release automation, and local k3d testing.
• Security policy defines supported versions, reporting path, response expectations, and security scope.