Production-ready Helm charts for self-hosted and platform workloads.

Website · Documentation · Helm Repository · Support · Contributing · Governance

HelmForge publishes charts through both a standard HTTPS Helm repository and an OCI registry on GHCR. Use the HTTPS repository when you want classic helm repo workflows, and OCI when you prefer registry-native pulls and signatures.

helm repo add helmforge https://repo.helmforge.dev
helm repo update
helm search repo helmforge/
helm install <release-name> helmforge/<chart-name> --version <version> -f values.yaml

helm install <release-name> oci://ghcr.io/helmforgedev/helm/<chart-name> --version <version> -f values.yaml

# Show default values
helm show values oci://ghcr.io/helmforgedev/helm/<chart-name> --version <version>

Check each chart's README and git tags for available versions.

Every published chart package is signed with GPG provenance, and OCI artifacts are signed with Cosign by the release workflow. Import the HelmForge public key before using Helm provenance verification.

# HTTPS repository provenance verification
helm pull helmforge/<chart-name> --version <version> --verify

# OCI signature verification
cosign verify \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-identity-regexp 'https://github.com/helmforgedev/charts/.github/workflows/publish.yml@refs/heads/main' \
  ghcr.io/helmforgedev/helm/<chart-name>:<version>

HelmForge is built on a simple principle: use what upstream ships, make the Kubernetes contract explicit, and keep releases verifiable.

• Official upstream images — charts prefer images published by the application maintainers. No proprietary rebuild layer or vendor-specific runtime wrapper.
• Pinned version tags — charts reference explicit, immutable image tags. No :latest, no floating tags, no surprises after a pull.
• Apache-2.0 licensed — the charts, tests, and docs use a CNCF-aligned permissive license. No open-core, no paid tiers, no license traps.
• GPG + Cosign signed — every release includes GPG provenance files for Helm verification and Sigstore Cosign keyless signatures on OCI artifacts.
• No vendor lock-in — standard Helm, standard Kubernetes APIs, standard images. If you stop using HelmForge tomorrow, nothing breaks.
• Explicit values contracts — product-oriented values.yaml files map directly to application and Kubernetes configuration, with schemas and validations where they prevent bad releases.
• HelmForge-native dependencies — charts that need databases, caches, queues, or coordination services use HelmForge subcharts when available. This keeps dependency behavior consistent across the catalog.
• Operator-first docs — chart READMEs, site docs, examples, and test values are kept close to the release surface.

HelmForge is maintained in the open and funded by practical community signals: stars, issues, reviews, and direct support.

If HelmForge helps your cluster or saves maintenance time, please give the repository a star. Stars help track real adoption, make the project easier to discover, and guide where maintenance time should go next. For direct support, use Buy Me a Coffee.

60+ production-ready charts covering databases, authentication, CMS, analytics, automation, AI tooling, observability, and platform infrastructure.

Browse the full catalog with descriptions, install commands, and playground configs at helmforge.dev/docs/charts.

Common categories include:

• Databases and data stores — PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Valkey, Kafka, ZooKeeper, RabbitMQ, Elasticsearch, and Druid.
• Identity and access — Keycloak, Authelia, and application charts with ingress/auth integration patterns.
• Automation and operations — n8n, Cronicle, FastMCP Server, Cloudflared, Velero, DDNS Updater, and Envoy Gateway.
• Content and community apps — WordPress, Ghost, Drupal, Gitea, Wallabag, Castopod, Komga, OpenWebUI, and more.

The generic chart is the reusable platform chart for workloads that need a Kubernetes contract instead of an application-specific chart. It is useful for internal services, workers, batch releases, sidecar-based apps, and platform integration tests where a full bespoke chart would add more maintenance than value.

It supports:

• Deployments, StatefulSets, DaemonSets, Jobs, and CronJobs.
• Multiple containers, init containers, global env/envFrom, probes, rollout checksums, and explicit restarts.
• Primary and additional Services, headless Service mode, Ingress, and Gateway API HTTPRoutes.
• RBAC, NetworkPolicy, ServiceMonitor, PodMonitor, PrometheusRule, VPA, HPA, and KEDA.
• Safer validation for disabled-Service routing and KEDA ScaledObject targets.

The repository is governed by a comprehensive suite of GitHub Actions workflows that enforce quality, security, and operational intelligence automatically.

Charts are automatically tested and published via GitHub Actions.

PR        --> ci.yml            --> [Dependency Build] [Strict Lint] [Template] [Unit Test] [Kubeconform] [Artifact Hub Lint]
          --> code-quality.yml --> [Markdown Lint] [Values Quality] [License Headers]
          --> security-scan.yml --> [Kubescape MITRE+NSA+SOC2]
          --> pr-governance.yml --> [Conventional PR Title] [Scope Labels]
Push main --> publish.yml      --> Detect --> Semver --> Package --> Sign --> Publish --> Git tag
Weekly    --> upstream-watch.yml --> Scan all charts --> Create issues for outdated images

PR workflows (ci.yml, code-quality.yml, security-scan.yml) dynamically detect which charts changed and run jobs only for affected charts using a matrix strategy. Changes to docs (README.md, examples/, docs/) are ignored. Scheduled workflows run against the full repository.

The Tests workflow runs for pull requests and pushes to main that affect chart templates, chart metadata, tests, or the workflow itself. The Publish workflow runs on pushes to main and publishes chart releases. Documentation-only changes are intentionally excluded from chart tests and release publishing.

Quality gates include:

• helm dependency build for every changed chart, including HelmForge OCI subcharts.
• helm lint --strict.
• helm template with default values and every ci/*.yaml scenario.
• helm unittest when a chart has a test suite.
• kubeconform against Kubernetes schemas and CRD schemas from the Datree CRDs catalog.
• ah lint -p for Artifact Hub metadata.
• Kubescape security compliance scanning (MITRE, NSA, SOC2 frameworks).
• Markdown linting, values quality checks, and SPDX license header enforcement on changed YAML, template, and shell files.
• Signed package publishing to GHCR and the HTTPS Helm repository.

Local validation should use the repository helper:

# Static validation matching the current PR gates
./test.sh <chart-name>

# Validate a runtime scenario on the local k3d cluster
kubectl config current-context
./test.sh <chart-name> --runtime -f charts/<chart-name>/ci/<scenario>.yaml

# Validate every chart without runtime installs
./test.sh --all --skip-runtime

test.sh intentionally does not use kubeconform --ignore-missing-schema. If a chart renders a CRD-backed resource, install the CRD locally and make sure schema validation can resolve the API. The helper checks the tools needed by the selected gates before running. Missing helm, kubectl, kubeconform, ah, and kubescape binaries are installed into ~/.local/bin by default, and the helm-unittest plugin is installed when selected charts include tests. Set HELMFORGE_TOOLS_DIR to use a different tool directory, or pass --no-install to fail fast on missing tools.

Every chart PR should have a linked GitHub issue, complete PR checklist evidence, passing CI, and no unresolved review comments before merge.

Versions are calculated automatically from Conventional Commits affecting each chart.

Tags follow the format {chart}-v{version} (for example generic-v1.2.3).

Every chart release automatically creates a GitHub Release with categorized notes generated from Conventional Commits:

• Breaking Changes — commits with !: or BREAKING CHANGE
• Features — feat(...):
• Bug Fixes — fix(...):
• Other Changes — docs, refactor, ci, etc.

Each release includes install instructions for both OCI and Helm repository.

Each chart can include a ci/ directory with test values files. The pipeline runs helm template and kubeconform against every ci/*.yaml file automatically, in addition to default values, lint, Artifact Hub lint, and chart unit tests when present.

For local chart work:

# For charts with HelmForge OCI subcharts, authenticate to GHCR if your environment is not already logged in
echo "$GHCR_TOKEN" | helm registry login ghcr.io -u "$GHCR_USERNAME" --password-stdin

./test.sh <chart-name>

For runtime validation, use the local k3d-helmforge-tests-wsl cluster instead of any production Kubernetes context. Helm installs should use --wait --timeout 120s. Validation must check pod readiness, recent namespace events, and pod logs before the namespace is removed.

All charts require Helm 4 (apiVersion: v2) and target Kubernetes 1.26+.

The Tests workflow validates rendered manifests with kubeconform against the default Kubernetes JSON schemas. Local runtime validation uses k3d clusters.

Charts use standard stable APIs (apps/v1, batch/v1, networking.k8s.io/v1) and avoid alpha/beta API versions to maximize compatibility.

Contributions are welcome. Please read the contributing guide for branch flow, validation requirements, commit conventions, and chart standards.

Community and project governance documents:

• Code of Conduct
• Governance
• Maintainers
• Adopters
• Security Policy

Apache License 2.0