FAQ

Why use this instead of writing my own chart?

Writing a chart from scratch means reinventing resource naming, label conventions, checksum annotations, HPA wiring, test hooks, and multi-environment override patterns. This chart has all of that tested and maintained. You focus on your application's values, not on Helm boilerplate.

Why use this instead of Kustomize?

Kustomize patches raw YAML files — you need a working base manifest to start from. This chart generates the manifests from values, so you never maintain base YAML files. You also get the Helm release lifecycle: helm diff, rollback, hook jobs, and release history. The base-chart pattern gives you the same "shared base + environment overlay" workflow that Kustomize offers, with type-safe values and templating on top.

Does this work with ArgoCD or Flux?

Yes. Both support Helm charts natively. Sealed Secrets make secret management GitOps-safe — encrypt secrets at rest in your repository, decrypt in-cluster. The checksum annotations ensure pods roll automatically when config changes are pushed.

Why use Sealed Secrets instead of passing secrets through CI?

Injecting secrets at deploy time (via --set or CI variables) means secrets are stored in Helm release history (Kubernetes secrets), CI logs, and pipeline variables. Sealed Secrets are encrypted at rest in the Git repository, decrypted only inside the cluster, and never touch CI. They also survive cluster recreation without re-injecting values.

How do I see what the chart will generate before deploying?

helm template my-release hosst/standard -f values.yaml
# Or with debug output:
helm template my-release hosst/standard -f values.yaml --set debug=true

How do I use this for multiple environments (staging, production)?

Create an application chart with standard as a dependency. Put shared config in the chart's values.yaml. Put environment-specific overrides in separate files:

helm upgrade --install my-app ./my-chart -f values.staging.yaml
helm upgrade --install my-app ./my-chart -f values.production.yaml

Can I add resources the chart doesn't support (NetworkPolicy, ExternalSecret, etc.)?

Yes — use extraManifests. Dict mode auto-injects name, namespace, and labels:

extraManifests:
  allow-monitoring:
    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    spec:
      podSelector: {}
      ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: monitoring

Can I use this for databases or stateful applications?

Not yet. StatefulSet support is the top item on the roadmap. Until then, use a database-specific chart (e.g. Bitnami PostgreSQL) alongside this chart for your application layer.

My helm upgrade silently lost PVC data after changing nameOverride or the release name — what happened?

PVC names are derived from the fullname (<release>-<nameOverride>-<key>). When the fullname changes, Helm sees a new PVC to create and an old one to delete — it does both without any warning, and helm upgrade exits successfully. Kubernetes's pvc-protection finalizer delays the actual deletion until pods stop mounting the old PVC, but once the new Deployment is running the old PVC is gone.

If you caught it before the old PVC was fully deleted:

1. Immediately scale the new Deployment to zero: kubectl scale deployment <new-name> --replicas=0 -n <namespace>
2. This releases the finalizer lock on the old PVC — stop here, do not delete it.
3. Set claimName: <old-pvc-name> in your persistence: config to pin the chart to the existing PVC name going forward.
4. Restore the old nameOverride / release name, or keep the new one with claimName set, and helm upgrade again.

If the old PVC is already gone, restore from your most recent Velero snapshot or volume backup.

To prevent this in future: always set claimName: explicitly in persistence: for any PVC that holds data you cannot afford to lose. This pins the PVC name regardless of chart naming changes. A helm.sh/resource-policy: keep annotation on all generated PVCs is on the roadmap to make this safe by default.

How do I debug unexpected rendering output?

Add debug: true to your values. The rendered manifests will include comments showing internal template state. You can also run helm template locally and inspect the output before deploying.