🎉 DevOps Interview Prep Bundle is live — 1000+ Q&A across 20 topicsGet it →
All Fixes
Today I Fixed

Helm upgrade accidentally deployed production values to staging

helmJul 1, 20265 minutes to fixhelmcicdtroubleshooting

Ran helm upgrade my-app ./chart in the staging cluster and noticed the replica count jumped to 10 and resource limits were much higher than expected. It had silently used the production values from the last deployment instead of the staging ones.

Root cause: helm upgrade without a -f flag reuses the values from the previous release stored in the cluster. I had previously deployed production values to this release name during a test, and never overrode them with the staging config. One missing flag, wrong environment.

Fix:

Always be explicit with the values file:

bash
# Wrong — reuses last deployed values
helm upgrade my-app ./chart
 
# Right — always specify the environment values file
helm upgrade my-app ./chart -f values-staging.yaml

To prevent this permanently, added a Makefile that enforces the correct file:

makefile
deploy:
ifndef ENV
	$(error ENV is not set. Use: make deploy ENV=staging or ENV=prod)
endif
	helm upgrade --install my-app ./chart \
	  -f values-$(ENV).yaml \
	  --namespace $(ENV) \
	  --atomic

Now the only valid way to deploy is make deploy ENV=staging or make deploy ENV=prod. Running bare helm upgrade in CI is blocked by the Makefile wrapper.

Lesson: Never run helm upgrade without -f values-<env>.yaml — Helm silently reuses previous values, and there's no warning when it does.