Both approaches ultimately create the same Kubernetes resources (Deployments, Services, PVCs, ConfigMaps, etc.). The main difference is how those resources are configured, deployed, upgraded, and managed.
1. Helm vs traditional Kubernetes YAML
Feature | Traditional YAML ( | Helm Charts |
|---|---|---|
Configuration | Hardcoded in YAML files | Parameterized using |
Deployment |
|
|
Environment support | Separate YAMLs or Kustomize overlays | Separate values files |
Reusability | Manual duplication | Templates and reusable charts |
Versioning | Git-based | Git + Helm release revisions |
Rollback | Manual or workload-specific |
|
Dependencies | Managed separately | Helm chart dependencies |
Complexity | Simple | Requires learning templating |
Best suited for | Small, static deployments | Multi-environment applications |
2. Example: Deployment using both approaches
Traditional Deployment YAML
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-core
spec:
replicas: 2
template:
spec:
containers:
- name: ai-core
image: myapp/ai-core:1.0.0
Helm Deployment template
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-core
spec:
replicas: {{ .Values.aiCore.replicas }}
template:
spec:
containers:
- name: ai-core
image: "{{ .Values.aiCore.image }}"
Helm values.yaml
aiCore:
replicas: 2
image: myapp/ai-core:1.0.0
Helm substitutes the values into the template and generates ordinary Kubernetes YAML, which Kubernetes then processes.
3. How deployment commands differ
Traditional Kubernetes
kubectl apply -f kubernetes/Helm — Minikube
helm upgrade --install myapp ./helm/myapp \
-f ./helm/myapp/values-minikube.yamlHelm — Production
helm upgrade --install myapp ./helm/myapp \
-f ./helm/myapp/values-production.yamlThe same Helm templates can be used in both environments, with different image tags, storage settings, resource limits, and network configurations.
4. Important: Helm doesn't replace Kubernetes YAML
Your Helm chart still contains Deployment, Service, StatefulSet, PVC, and other Kubernetes YAML definitions.
The structure typically looks like:
helm/myapp/
├── Chart.yaml
├── values.yaml
├── values-minikube.yaml
├── values-production.yaml
└── templates/
├── deployment.yaml
├── service.yaml
├── statefulset.yaml
├── pvc.yaml
└── httproute.yamlYou can inspect the exact YAML Helm will generate:
helm template myapp ./helm/myapp \
-f ./helm/myapp/values-production.yamlThis is particularly useful for debugging Helm charts.
5. Which should you use?
For your application, Helm is the better choice because you have Docker Compose for development, Minikube for testing, and a self-managed production Kubernetes cluster.
Helm also helps with your offline release bundles, upgrades, and rollback procedures.
One limitation: helm rollback restores Kubernetes resource configuration, but does not automatically roll back PostgreSQL schema changes or persistent data.
A useful way to think about it:
Traditional YAML = Define Kubernetes resources.
Helm = Package, configure, deploy, and manage those Kubernetes resources across environments.
