Configure Helm hook weights and hook deletion policies to run database schema migrations before a chart upgrade and clean up Jobs on success
domain: helm.sh · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Annotate the migration Job manifest with helm.sh/hook: pre-upgrade,pre-install so it runs before main resources are applied
Set helm.sh/hook-weight: "-5" to control ordering if multiple hooks exist; lower weights run first
Add helm.sh/hook-delete-policy: hook-succeeded to delete the Job automatically after it completes successfully, preventing accumulation across upgrades
Set spec.backoffLimit: 0 on the Job so a failed migration fails the hook immediately rather than retrying; this causes the helm upgrade to fail and roll back
Run helm upgrade --atomic --timeout 5m myrelease ./chart so that hook failures trigger automatic rollback to the previous release revision
Inspect hook execution with helm status myrelease and kubectl get jobs -n <namespace> -l helm.sh/chart=<chart>
Known gotchas
hook-delete-policy: hook-succeeded means a failed Job is retained for debugging; if you use hook-delete-policy: before-hook-creation instead, the previous Job is deleted before the new one runs, losing failure logs
Hooks are not managed by Helm's diff or rollback for resource state — if a migration Job mutates the database schema and then the chart rollback is triggered, the database schema is not automatically reverted
A hook Job that hangs will block the helm upgrade for the full --timeout duration; always set spec.activeDeadlineSeconds on the Job as a safety net
Give your agent this knowledge — and 15,600+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?