← Back to Blog
ANALYSIS

The 20 Most Common Helm Values (And Why They Matter)

January 24, 2026•8 min read

After analyzing 1,589 Helm charts from Artifact Hub, we discovered clear patterns in how charts are structured. These 20 values appear most frequently—and for good reason.

The Data

We parsed values.yaml files from the most popular charts on Artifact Hub, extracting every value path and tracking their usage across charts. The results reveal a strong consensus on naming conventions and structure.

1. image.repository (78.5%)

Used in nearly 4 out of 5 charts, image.repository is the de facto standard for specifying container images. The pattern is simple:

image:
  repository: nginx
  tag: 1.25.3
  pullPolicy: IfNotPresent

Why it matters: Separating repository from tag makes it trivial to update versions. Tools like Renovate and Dependabot expect this structure.

2. image.tag (75.7%)

Almost always paired with image.repository. Common values include semantic versions (1.0.0), latest, and stable.

Best practice: Default to a specific version tag, not latest. Users can override to track latest if they want unpredictability.

3. service.type (71.0%)

The most common service configuration value. Defaults are almost always ClusterIP:

service:
  type: ClusterIP
  port: 80

Why ClusterIP? It's the safest default—internal only. Users explicitly opt into LoadBalancer or NodePort when they need external access.

4. replicaCount (68.0%)

Top-level value controlling pod replicas. The overwhelming favorite default is 1.

Why one replica? It works for development and testing. Production deployments override it. Starting with 3 replicas by default would be expensive and unexpected.

5. resources.limits.cpu (64.0%)

Resource limits follow Kubernetes conventions exactly:

resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

Common values: 100m, 200m, 500m for CPU. The "m" suffix means milli-cores (1000m = 1 core).

6. resources.limits.memory (63.9%)

Memory limits in Mi or Gi. Most common: 128Mi, 256Mi, 512Mi.

Pattern to follow: Set limits equal to requests unless you have a specific reason not to. This gives predictable scheduling.

7. service.port (62.1%)

The port the service listens on. Overwhelmingly 80 for HTTP, 443 for HTTPS, or 8080 for applications that avoid privileged ports.

8. image.pullPolicy (59.5%)

Controls when Kubernetes pulls the image. Common values:

  • IfNotPresent (567 charts) — Pull only if not cached locally
  • Always (278 charts) — Pull on every pod start
  • Never (100 charts) — Never pull, must exist locally

Best practice: Use IfNotPresent with specific version tags. UseAlways only with latest or similar floating tags.

9. ingress.enabled (58.1%)

Boolean flag to create an Ingress resource. Almost always defaults to false.

ingress:
  enabled: false
  hosts:
    - host: chart-example.local
      paths: [/]

Why disabled by default? Ingress requires a controller and external configuration. It's opt-in infrastructure.

10. resources.requests.cpu (57.4%)

CPU requests guarantee minimum resources. Same format as limits. Most charts set requests equal to limits.

11. resources.requests.memory (57.3%)

Memory requests. Setting requests = limits prevents the pod from being OOMKilled due to node pressure.

12. nameOverride (53.9%)

Overrides the name template. Usually empty by default:

nameOverride: ""

When set, it replaces the chart name in resource names. Useful for migrating from one chart to another while keeping resource names stable.

13. fullnameOverride (52.5%)

Complete override of the full name template (which typically includes release name + chart name).

Use case: When you absolutely must control every resource name, regardless of Helm release name.

14. serviceAccount.create (49.7%)

Boolean controlling whether to create a ServiceAccount. Defaults to true in most charts:

serviceAccount:
  create: true
  name: ""
  annotations: {}

Why create by default? Pods need a service account. Better to create a specific one than use the default.

15. autoscaling.enabled (47.6%)

Controls HorizontalPodAutoscaler creation. Almost always false by default.

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 80

16. persistence.enabled (46.2%)

For stateful applications. Creates PersistentVolumeClaims when enabled:

persistence:
  enabled: false
  storageClass: ""
  accessMode: ReadWriteOnce
  size: 8Gi

Default is false because most web applications are stateless. Databases and similar apps default to true.

17. ingress.hosts (44.1%)

Array of host configurations for the Ingress. Usually includes one example:

hosts:
  - host: chart-example.local
    paths:
      - path: /
        pathType: Prefix

18. podAnnotations (43.4%)

Annotations to add to pods. Empty object by default, users add their own:

podAnnotations: {}
# Example usage:
# podAnnotations:
#   prometheus.io/scrape: "true"
#   prometheus.io/port: "9090"

19. nodeSelector (41.3%)

Node selection constraints. Empty by default:

nodeSelector: {}
# Example:
# nodeSelector:
#   kubernetes.io/os: linux
#   node-type: compute

20. tolerations (39.2%)

Pod tolerations for tainted nodes. Empty array by default:

tolerations: []
# Example:
# tolerations:
#   - key: "key1"
#     operator: "Equal"
#     value: "value1"
#     effect: "NoSchedule"

Patterns and Takeaways

1. Nested Structure is Standard

Notice how values are organized hierarchically: image.repository, service.type,resources.limits.cpu. This groups related configuration together.

2. Safe Defaults

Most values default to the safest, simplest option:

  • One replica (not three)
  • ClusterIP service (not LoadBalancer)
  • No ingress, no autoscaling, no persistence
  • ServiceAccount created (security)

3. Override Everything

Every common value is exposed for override. This is critical—users need control without editing templates.

4. Follow Kubernetes Conventions

The structure mirrors Kubernetes resources. resources.limits.cpu matches the exact path in a Pod spec. This makes values.yaml feel familiar.

Building Your Chart?

If you're creating a new Helm chart, start with these 20 values. You'll cover 80%+ of what users expect. Your chart will feel familiar, documentation will be minimal, and integration with tools will be seamless.

Use our search tool to explore all 847 values we've discovered, see usage percentages, and find examples from real charts.

← Back to Blog