Helm Chart Generator — Free Online Tool

What is Helm Chart Validator & Linter?

Helm is a package manager for Kubernetes that uses 'charts' (collections of YAML files) to define, install, and upgrade Kubernetes applications. This tool validates Helm chart structure, checks YAML syntax in Chart.yaml, values.yaml, and template files, and lints for common errors like missing required fields, invalid apiVersions, or template syntax issues. It helps catch chart errors before deploying to a cluster.

• YAML syntax validation: Parses Chart.yaml, values.yaml, and templates to detect syntax errors (indentation, invalid keys, malformed YAML).
• Chart.yaml validation: Checks required fields (apiVersion, name, version), validates version format (SemVer), and ensures appVersion is present.
• values.yaml validation: Ensures values file is valid YAML and checks for common issues like reserved keywords or invalid structure.
• Template linting: Validates Go template syntax in templates/*.yaml files. Checks for undefined variables, invalid functions, or rendering errors.
• Best practices checking: Lints for Helm/Kubernetes best practices: resource limits, liveness/readiness probes, security contexts, etc.

Why use Helm chart validator?

Helm charts with errors fail deployment or cause runtime issues in Kubernetes clusters. Validating charts before deployment saves time and prevents production outages.

• Catch errors early: Detect YAML syntax errors, missing fields, or template issues before running helm install. Faster than trial-and-error in a cluster.
• Learn Helm best practices: The linter explains what is wrong and why. Great for learning proper chart structure and Kubernetes patterns.
• No cluster required: Validate charts offline without access to a Kubernetes cluster. Perfect for CI/CD pipelines or local development.
• Prevent deployment failures: Charts with invalid YAML or template errors fail during helm install. Catch these issues in seconds, not minutes.
• Improve chart quality: Linting enforces best practices (resource limits, security contexts, labels). Produces production-ready charts.
• Fast feedback: Instant validation in the browser. No need to install Helm CLI or run helm lint commands manually.

When to use Helm chart validator

Use when creating or modifying Helm charts.

• Writing a new Helm chart from scratch to ensure correct structure.
• Debugging helm install or helm upgrade failures caused by chart errors.
• Validating charts before committing to version control or publishing to a chart repository.
• Checking charts in CI/CD pipelines as a pre-deployment validation step.
• Learning Helm by seeing real-time feedback on chart structure and syntax.
• Reviewing third-party charts to verify quality before installing in your cluster.
• Ensuring charts follow Kubernetes best practices (resource limits, probes, security).

How to use Helm chart validator

Upload chart files or paste YAML, see validation results.

1. Upload Chart.yaml: Paste or upload the Chart.yaml file. This defines chart metadata: name, version, appVersion, description, dependencies.
2. Upload values.yaml (optional): Paste or upload values.yaml. This contains default configuration values referenced in templates.
3. Upload templates (optional): Upload template files (deployment.yaml, service.yaml, etc.). The tool checks Go template syntax and Kubernetes resource structure.
4. View validation results: The tool parses YAML, checks required fields, validates SemVer versions, and lints templates. Errors show line numbers and descriptions.
5. Fix errors: Correct the issues listed (syntax errors, missing fields, invalid template functions). Re-validate until no errors remain.
6. Check best practice warnings: Review warnings (missing resource limits, no readiness probe). These are not errors but recommended fixes for production.

Key features

• Chart.yaml validation: Checks apiVersion (v1 or v2), name, version (SemVer), appVersion, description. Ensures required fields are present.
• values.yaml parsing: Validates YAML syntax. Checks for reserved keywords or malformed structures.
• Template syntax checking: Parses Go templates ({{ .Values.image }}). Detects undefined variables, invalid functions, or rendering errors.
• Kubernetes resource validation: Checks that rendered templates produce valid Kubernetes YAML (Deployment, Service, ConfigMap, etc.).
• Best practices linting: Warns about missing resource limits, liveness/readiness probes, security contexts, or deprecated apiVersions.
• Error line numbers: Shows exact line numbers for syntax errors or validation issues. Makes fixing fast.
• Instant feedback: Browser-based validation. No Helm CLI or cluster required.

Common use cases

• New chart creation: Validate Chart.yaml and values.yaml structure when creating a new chart from scratch.
• Debugging failed deployments: Identify why helm install fails with syntax or template errors.
• Pre-commit validation: Check charts before committing to Git. Prevents broken charts in version control.
• CI/CD integration: Run validation in CI pipelines (GitHub Actions, GitLab CI) to block merges with invalid charts.
• Learning Helm: Experiment with chart structure and see instant feedback on errors.
• Third-party chart review: Validate charts from Artifact Hub or Helm repositories before installing.

Examples

Validation results for common Helm chart issues.

apiVersion: v2
name: my-app
version: 1.0.0
appVersion: "1.16.0"
description: A Helm chart for my app

✓ Valid. All required fields present. SemVer version format correct.

apiVersion: v2
name: my-app
description: A Helm chart

✗ Error: Missing required field 'version'. Chart.yaml must include version in SemVer format (e.g., 1.0.0).

apiVersion: v1
kind: Deployment
metadata: name: {{ .Values.appName }}
spec: replicas: {{ .Values.replicaCount }}

✗ Error: Template references .Values.appName, but this key is not defined in values.yaml. Add appName: my-app to values.yaml.

apiVersion: v1
kind: Deployment
spec: template: spec: containers: - name: nginx image: nginx:1.21

⚠ Warning: Container 'nginx' has no resource limits. Add resources: {requests: {cpu: 100m, memory: 128Mi}, limits: {cpu: 200m, memory: 256Mi}}.

apiVersion: v2
name: my-app
version: v1.2.3
appVersion: "1.0"

✗ Error: version 'v1.2.3' is not valid SemVer. Remove the 'v' prefix. Use '1.2.3' instead.

Technical reference

Helm chart structure and validation rules:

Chart.yaml required fields

apiVersion (v1 or v2), name, version (SemVer), appVersion (recommended). Optional: description, keywords, home, sources, maintainers.

Chart API versions

v1 (Helm 2), v2 (Helm 3). Helm 3 charts use apiVersion: v2 and support dependencies in Chart.yaml.

Version format

SemVer (Semantic Versioning): MAJOR.MINOR.PATCH. Example: 1.2.3, 0.1.0. No 'v' prefix.

values.yaml structure

Any valid YAML. Typically nested objects: image: {repository: nginx, tag: 1.21}. Referenced in templates as {{ .Values.image.repository }}.

Template syntax

Go templates with Helm functions. {{ .Values.key }}, {{ .Release.Name }}, {{ include 'template' . }}. Sprig functions supported.

Template files

Located in templates/ directory. Common files: deployment.yaml, service.yaml, configmap.yaml, _helpers.tpl (reusable templates).

Best practices

Resource limits (requests/limits), liveness/readiness probes, security contexts (runAsNonRoot), labels (app.kubernetes.io/name).

Deprecated apiVersions

extensions/v1beta1 Deployment (use apps/v1). networking.k8s.io/v1beta1 Ingress (use v1). Check Kubernetes deprecation notices.

Common errors

YAML indentation (use 2 spaces), undefined template variables, missing required fields, invalid SemVer, malformed templates.

Comparison to kubectl validate

Helm validates chart structure and templates. kubectl validate checks rendered Kubernetes YAML against cluster API. Both are complementary.

Common mistakes to avoid

Using invalid SemVer in Chart.yaml version field (e.g., v1.0, 1.0, latest)

Why it happens: Helm requires strict Semantic Versioning (MAJOR.MINOR.PATCH) for the version field. v1.0 has a 'v' prefix (invalid). 1.0 is missing PATCH (must be 1.0.0). latest is not a version number. If the version is invalid, helm install fails with 'invalid chart: version is not valid SemVer'.

How to avoid it: Use strict SemVer: 1.0.0, 2.3.1, 0.1.0. No 'v' prefix, no 'latest', no build metadata (+build123). For pre-releases, use 1.0.0-alpha, 1.0.0-beta.1. Update version for every chart change (increment PATCH for bug fixes, MINOR for features, MAJOR for breaking changes).

Referencing .Values.key in templates without defining it in values.yaml

Why it happens: Helm templates use {{ .Values.key }} to reference values from values.yaml. If .Values.replicaCount is used but values.yaml does not have replicaCount:, the template fails to render with 'map has no entry for key replicaCount'. This is the most common Helm error.

How to avoid it: For every {{ .Values.key }} in templates, add key: value to values.yaml. Example: if templates use {{ .Values.image.tag }}, values.yaml must have image: {tag: '1.0'}. Or use default values in templates: {{ .Values.image.tag | default '1.0' }}.

Using deprecated Kubernetes apiVersions (extensions/v1beta1, apps/v1beta2)

Why it happens: Kubernetes removes old apiVersions in newer versions. extensions/v1beta1 Deployment was removed in v1.16. apps/v1beta2 was removed in v1.16. If your chart uses these, it fails to install on modern Kubernetes clusters (v1.25+) with 'no matches for kind Deployment in version extensions/v1beta1'.

How to avoid it: Update to current apiVersions: apps/v1 for Deployment, StatefulSet, DaemonSet. networking.k8s.io/v1 for Ingress (not v1beta1). batch/v1 for Job/CronJob. Check Kubernetes API deprecation guide for your cluster version.

Forgetting to set resource limits in Deployment templates, causing cluster resource issues

Why it happens: Without resource requests and limits, Kubernetes cannot properly schedule pods or prevent resource contention. A pod without limits can consume all node CPU/memory, crashing other pods. Without requests, the scheduler may place the pod on an overloaded node, causing poor performance or eviction.

How to avoid it: Always add resources to containers: resources: {requests: {cpu: 100m, memory: 128Mi}, limits: {cpu: 200m, memory: 256Mi}}. Set requests based on typical usage, limits slightly higher. For production, make these configurable via values.yaml: resources: {{ toYaml .Values.resources | nindent 10 }}.

Not validating charts locally before committing to Git, pushing broken charts

Why it happens: If you commit a chart with YAML syntax errors or missing required fields, the chart breaks for all users. Teammates cannot install it, CI/CD fails, and rollbacks are required. This wastes time and blocks deployments. Common in teams without pre-commit validation.

How to avoid it: Run helm lint before committing: helm lint ./my-chart. Or use this tool for instant validation. Set up a pre-commit hook or CI check (GitHub Actions, GitLab CI) that runs helm lint on every push. Block merges if lint fails.

Frequently asked questions

What is the difference between Helm v1, v2, and v3 charts?

Helm v2 charts use apiVersion: v1 and define dependencies in requirements.yaml. Helm v3 charts use apiVersion: v2, define dependencies in Chart.yaml, and remove Tiller (server-side component). Helm v3 is current; use apiVersion: v2 for new charts. Helm v2 is deprecated.

What is SemVer and why does Helm require it?

Semantic Versioning (SemVer) is a version format: MAJOR.MINOR.PATCH (e.g., 1.2.3). MAJOR = breaking changes, MINOR = new features, PATCH = bug fixes. Helm requires SemVer for version field to ensure predictable upgrades and rollbacks. Use helm upgrade to move from 1.0.0 to 1.1.0 (safe), but 1.x to 2.0.0 may break (major change).

How do I validate Helm templates without a Kubernetes cluster?

Use helm template ./my-chart to render templates locally and see the output YAML. Or use this tool to validate Chart.yaml, values.yaml, and template syntax in the browser. Both work offline without a cluster.

What are common required fields in Chart.yaml?

apiVersion (v2 for Helm 3), name (chart name), version (SemVer, e.g., 1.0.0). Recommended: appVersion (app version, e.g., '1.16.0'), description. Optional: keywords, home, sources, maintainers, dependencies.

Why does helm install fail with 'version is not valid SemVer'?

The version field in Chart.yaml is not strict SemVer. Remove 'v' prefix (v1.0.0 → 1.0.0). Use MAJOR.MINOR.PATCH (1.0 → 1.0.0). Avoid 'latest' or non-numeric values. Helm requires exact SemVer format.

Can I use this tool in CI/CD pipelines?

This tool runs in the browser. For CI/CD, use helm lint or helm template in your pipeline scripts (GitHub Actions, GitLab CI). Example: helm lint ./my-chart || exit 1. This validates charts before deployment.

What is the difference between helm lint and kubectl validate?

helm lint validates chart structure, YAML syntax, and templates. kubectl validate checks rendered Kubernetes YAML against the cluster API (verifies resources exist and match schema). Use both: helm lint before install, kubectl apply --dry-run=client -f to validate against cluster.

References

• Helm official documentation
• Helm Chart.yaml schema
• Helm best practices
• Kubernetes API deprecation guide