Standard Helm Chart

Generic universal Helm chart easy to configure and extend to be used as standard for most applications and use cases.

See the values.yaml for all configuration options.

Requirements

• Helm 3

Install

Add the helm repository

$ helm repo add hosst https://hosstio.github.io/helm-charts

Install the standard Helm chart

$ helm install example hosst/standard

Upgrade

Update the helm chart

$ helm repo update

Check the differences

$ helm diff upgrade example hosst/standard

Upgrade the installation

$ helm upgrade example hosst/standard

Configure

Check values.yaml for all configuration options

Limitations

This chart only supports Deployment workloads. StatefulSets (databases, message queues, any app needing stable network identity or per-pod storage) and DaemonSets (node agents, log shippers) are not yet supported. StatefulSet support is the top priority on the roadmap.

Troubleshooting

Sealed secrets: pods failing on first install

When you set sealedSecrets or mountedSealedSecretFiles, this chart renders a SealedSecret custom resource, not a Secret. A SealedSecret is just an encrypted blob. The actual Secret your pods consume is created asynchronously by the sealed-secrets controller running in the cluster: it watches for SealedSecret objects, decrypts them, and creates a matching Secret with an owner reference.

Helm applies the SealedSecret during install but does not wait for the controller to materialize the real Secret. This creates a race on first install of a release: the Deployment's pod may be scheduled before the Secret exists.

Symptoms:

• Volume-mounted sealed secrets (mountedSealedSecretFiles) or secretKeyRef with optional: false: pod stuck in ContainerCreating / CreateContainerConfigError.
• Env-var references (envFrom, secretKeyRef): the kubelet keeps retrying, so the pod self-heals once the Secret appears; it just looks like a transient failure.
• helm install --wait may time out, because it blocks on pods that are themselves blocked on the missing Secret.

This race is bounded and usually resolves within seconds (and does not recur on helm upgrade, since the Secret already exists). If a pod stays broken:

• Check the controller is running and healthy in its namespace (commonly kube-system or sealed-secrets).
• Check for decryption failures: a rotated or mismatched key is a permanent failure, not a race, and the Secret will never appear. Inspect status:

  kubectl get sealedsecret <release>-sealed-secrets -o jsonpath='{.status}'

• Confirm the derived Secret exists:

  kubectl get secret <release>-sealed-secrets

Mitigations: use a generous --timeout (or avoid --wait with a tight timeout) on first install; in GitOps, order the SealedSecret ahead of the Deployment (Argo CD sync-waves, Flux dependsOn) so the controller can reconcile first.