Configuration

jhelm uses Spring Boot @ConfigurationProperties for all configuration. Properties can be set in application.yaml, application.properties, environment variables, or system properties.

The section below is the practical "how do I set this" guide for operators; the property reference tables further down list every available setting.

The repository, registry, and kubeconfig paths default to Helm’s own locations and honor Helm’s HELM_* environment variables, so a Helm setup drops in with no jhelm configuration. See Shared configuration with Helm for the full mapping.

1. Configuring jhelm (for operators)

The jhelm CLI is a Spring Boot application, so it reads the settings on this page from three sources — no Spring knowledge required. Pick whichever fits your environment; they can be combined, and later ones in this list win:

  1. a config file (application.yaml or .properties),

  2. an environment variable,

  3. a JVM system property (-D).

The command line itself is reserved for helm-style subcommands and flags (jhelm install …, -n, --set). Do not pass settings as --jhelm.config-path=… on the command line — that is a Spring option, not a jhelm flag, and the CLI rejects it as unknown. Use one of the three sources below.

1.1. 1. A YAML (or properties) file

Put an application.yaml next to where you run jhelm (the current directory, or a config/ subdirectory) and it is picked up automatically:

jhelm:
  config-path: /etc/jhelm/repositories.yaml
  insecure-skip-tls-verify: false
  kubernetes:
    kubeconfig-path: /home/deploy/.kube/config

The same settings in application.properties form:

jhelm.config-path=/etc/jhelm/repositories.yaml
jhelm.kubernetes.kubeconfig-path=/home/deploy/.kube/config

To keep the file anywhere else, point at it with an environment variable (trailing slash for a directory, or give the full file path):

export SPRING_CONFIG_ADDITIONAL_LOCATION=/etc/jhelm/
jhelm list -n production

1.2. 2. Environment variables

Every property maps to an environment variable: uppercase it and replace . and - with _. This is usually the simplest option for CI and containers:

export JHELM_CONFIG_PATH=/etc/jhelm/repositories.yaml
export JHELM_KUBERNETES_KUBECONFIG_PATH=/home/deploy/.kube/config
jhelm list -n production
Property Environment variable

jhelm.config-path

JHELM_CONFIG_PATH

jhelm.registry-config-path

JHELM_REGISTRY_CONFIG_PATH

jhelm.insecure-skip-tls-verify

JHELM_INSECURE_SKIP_TLS_VERIFY

jhelm.template-cache-enabled

JHELM_TEMPLATE_CACHE_ENABLED

jhelm.template-cache-max-size

JHELM_TEMPLATE_CACHE_MAX_SIZE

jhelm.kubernetes.kubeconfig-path

JHELM_KUBERNETES_KUBECONFIG_PATH

1.3. 3. JVM system properties (-D)

When you launch the jar directly, pass -D<property>=<value> before -jar:

java -Djhelm.config-path=/etc/jhelm/repositories.yaml -jar jhelm.jar list -n production

If jhelm is a wrapper or alias (so you cannot control the java arguments), put the same -D flags in the standard JVM environment variable instead — the JVM applies them and they never reach the command parser:

export JAVA_TOOL_OPTIONS="-Djhelm.config-path=/etc/jhelm/repositories.yaml"
jhelm list -n production

1.4. Profiles (environment-specific config)

A profile is a named set of overrides — one file per environment (dev, staging, prod) layered on top of the base application.yaml. Create application-prod.yaml beside your base file, then activate it by name:

# application-prod.yaml — only used when the "prod" profile is active
jhelm:
  config-path: /etc/jhelm/prod-repositories.yaml
  insecure-skip-tls-verify: false
export SPRING_PROFILES_ACTIVE=prod          # or: java -Dspring.profiles.active=prod -jar jhelm.jar …
jhelm list -n production

You can also keep every environment in a single file, separated by ---, gating each block with spring.config.activate.on-profile:

jhelm:
  template-cache-enabled: true      # shared by all profiles
---
spring:
  config:
    activate:
      on-profile: prod
jhelm:
  insecure-skip-tls-verify: false

1.5. Spring Boot references

These external pages cover the mechanics in more depth (jhelm uses them unchanged):

2. Core Properties (jhelm.*)

Provided by JhelmCoreAutoConfiguration when jhelm-core is on the classpath.

Property Type Default Description

jhelm.config-path

String

null

Path to the Helm repository configuration file. Bound at the jhelm root as jhelm.config-path (not jhelm.core.config-path); jhelm.core.config-path is also accepted as a relaxed alias. Defaults to the operator’s Helm location ($HELM_REPOSITORY_CONFIG, else ~/.config/helm/repositories.yaml) when unset — which jhelm reads and writes (see the embedding note below).

jhelm.registry-config-path

String

null

Path to the OCI registry auth configuration file. Uses a platform-specific default location when not set.

jhelm.insecure-skip-tls-verify

boolean

false

Skip TLS certificate verification when downloading charts over HTTP.

jhelm.template-cache-enabled

boolean

true

Enable caching of parsed template ASTs in an LRU cache. Improves rendering performance for repeated chart renders.

jhelm.template-cache-max-size

int

256

Maximum number of parsed templates to keep in the LRU cache. Only applies when template-cache-enabled is true.
Repository config path: property name and the embedded-vs-CLI default

The repository config path binds at the jhelm root — the property is jhelm.config-path, not jhelm.core.config-path — because it lives on JhelmCoreProperties (@ConfigurationProperties(prefix = "jhelm")), alongside the sibling jhelm.rest. / jhelm.security. / jhelm.plugins. groups. Because the jhelm.core. form is the natural guess, jhelm also accepts jhelm.core.config-path as a relaxed alias (resolved in JhelmCoreAutoConfiguration); either name works, and the same alias applies to jhelm.repository-cache-path.

When neither name is set, the path is implicitly defaulted to the operator’s real Helm location ($HELM_REPOSITORY_CONFIG, else the per-OS Helm default such as ~/.config/helm/repositories.yaml), which jhelm both reads and writes (for example, helm repo add). That default is convenient for the CLI, but surprising when embedding jhelm-core as a library in a long-running server — it silently mutates the operator’s Helm repositories. When embedding, set jhelm.config-path (or jhelm.core.config-path) explicitly to an application-owned location. The resolved config-path and cache-path are logged at INFO on startup, and a WARN is emitted when the path was left to the implicit default.

3. Kubernetes Properties (jhelm.kubernetes.*)

Provided by JhelmKubeAutoConfiguration when jhelm-kube is on the classpath.

Property Type Default Description

jhelm.kubernetes.kubeconfig-path

String

null

Path to the kubeconfig file. When not set, uses standard Kubernetes auto-detection: ~/.kube/config or in-cluster credentials.

jhelm.kubernetes.backend

String

auto

Which Kubernetes client backend to use — auto, client-java, or fabric8. See Choosing a Kubernetes client backend.

4. Choosing a Kubernetes client backend

jhelm can talk to the cluster through either of two Kubernetes client libraries, and picks the backend based on which one is on the classpath. jhelm-kube declares both as optional dependencies, so it ships neither transitively — the consumer puts exactly one on the classpath (the jhelm CLI bundles the official client by default):

Backend Dependency to add

client-java (default)

io.kubernetes:client-java — the official Kubernetes Java client.

fabric8

io.fabric8:kubernetes-client — the Fabric8 Kubernetes client.

Both backends are behaviorally identical from a chart’s point of view: they store releases in the same sh.helm.release.v1.* Secret format (a release written by one backend is readable by the other), apply and delete with the same semantics, and expose the same lookup/kubeVersion template data.

jhelm.kubernetes.backend selects the backend:

  • auto (default) — use the backend whose client library is present; if both are on the classpath, prefer client-java (jhelm’s historical default).

  • client-java / fabric8 — force that backend. The named client library must be present, otherwise no Kubernetes backend is configured.

Selection is deterministic — exactly one backend activates regardless of configuration order — so having both libraries on the classpath is well-defined rather than a conflict.

jhelm:
  kubernetes:
    backend: fabric8   # requires io.fabric8:kubernetes-client on the classpath

5. Precedence

When the same setting is supplied in more than one place, Spring Boot resolves it in this order (highest wins): JVM system properties (-D) > environment variables > profile-specific file (application-<profile>.yaml) > base application.yaml. So a -D flag or an environment variable always overrides a value baked into a config file — handy for a one-off override in CI without editing the file.