If you’re familiar with Helm and use several Helm charts to deploy everything on your stack, you certainly already have felt about missing lifecycles. By default, Helm provides Hooks to manage lifecycles. This is excellent when you’re the chart owner, as you can control it.
But something is missing. How do you manage lifecycles when you’re using a community chart? You have to fork the original Chart, add your hooks and maintain them over time (more or less depending on how customized your Hooks are). Quite boring, right?
Also, Hooks require a container to run your code as a job, so you have to create a container only for this purpose, store it on a registry, etc.
Finally, how do you handle exceptions, fallbacks, ensure your app works as expected (in addition to Kubernetes lifecycles)? There are no familiar ways to do that with Helm.
That’s why we decided to build something on top of Helm directly in the Engine, to add a common lifecycle mechanism.
Terraform Helm provider based
In another article, I was talking about why we removed Helm from Terraform. Even if the move was required, the way the Helm provider requested Chart configuration, was pretty good. So we decided to use something close to it with a struct.
Compared to the Helm chart, you can note some differences we support:
Direct YAML content in yaml_files_content, which is sometimes super convenient.
last_breaking_version_requiring_restart: allowing us to uninstall a chart before installing it once again when some major breaking changes are required by community charts (and for sure there are no data associated)
We then decided to create defaults values as it’s very frequent to have common ones:
check_prerequisites: ensuring everything is ok before doing any action
pre_exec: run pre exec code before running any action on a chart
exec: perform an action (deploy/delete) on a chart
on_deploy_failure: run code when an action failed
post_exec: run code after helm action
validate: ensure deployed applications are working as expected
Lifecycles
Let’s dig into what those lifecycles contain.
check_prerequisites
By default, we simply check the prerequisites, like the file permissions on helm values override files:
fn check_prerequisites(&self) -> Result
pre_exec
Pre exec is really useful for some charts, to pre-check/validate/update stuff before going further. Super useful for example for already deployed applications without Helm, and you want to give ownership to Helm by updating annotations (like AWS CNI). by default, nothing is done:
Obviously, this has to be adapted for any deployed solution.
Example of usage
Let’s try with a real use case. Here it’s the Prometheus Operator where we need to change the exec method to be able to manage lifecycle with CRDs (the uninstall phase):
We’ve been using this for production usage at Qovery for more than five months now. From an experienced Kubernetes point of view (+6y of XP on the Kubernetes ecosystem), I finally feel confident on helm chart deployments.
We don’t know if we will move out to a dedicated library. If we receive requests, we’ll consider it.
Alerting with guided troubleshooting in Qovery Observe
Get alerted and fix issues with full context. Qovery Observe notifies you when something goes wrong and guides you straight to the metrics and signals that explain why, all in one place.
Alessandro Carrano
Head of Product
DevOps
Developer Experience
minutes
December 17, 2025
Top 10 Terraform Cloud Alternatives: The DevOps Guide to Escaping "State File Nightmares"
Tired of rising licensing costs and complex state management? Discover the top 10 alternatives to modernize your Infrastructure as Code, empower developers, and regain control of your cloud spend.
Mélanie Dallé
Senior Marketing Manager
DevOps
minutes
December 15, 2025
Top 10 Jenkins Alternatives: The DevOps Guide to Escaping "Plugin Chaos"
Tired of Jenkins maintenance and broken pipelines? Discover the top 10 alternatives to modernize your CI/CD, automate environments, and reduce operational toil.
Mélanie Dallé
Senior Marketing Manager
DevOps
minutes
December 15, 2025
10 DigitalOcean Alternatives for Scaling DevOps Teams
Top DigitalOcean alternatives for scaling teams. Compare Qovery (Multi-cloud automation), AWS, GCP, and Vultr to find the best fit for performance and scale.
Mélanie Dallé
Senior Marketing Manager
DevOps
minutes
December 15, 2025
Top 5 Vercel Alternatives: Escape Cost, Lock-in, and Frontend Constraints
Stop paying Vercel overages and battling lock-in. Compare Qovery (full-stack automation on your cloud), Render, Netlify, and Fly.io to find the best alternative for DevOps and enterprise scaling.
Mélanie Dallé
Senior Marketing Manager
DevOps
minutes
December 15, 2025
Top 8 OrbStack Alternatives: Choosing the Right Tool for DevOps & Production Parity
Top OrbStack alternatives for developers and teams. Compare Qovery, Rancher Desktop, Podman, and Colima to find the best tool for performance, cross-platform stability, and K8s integration.
Mélanie Dallé
Senior Marketing Manager
Heroku
AWS
Cloud Migration
13
minutes
December 14, 2025
How to Migrate from Heroku to AWS: A Strategic Blueprint for Mid-Market Teams
Outgrowing Heroku? Stop the manual DevOps grind. Migrate to AWS in <7 days using AI to generate Terraform, EKS configs, and a seamless developer experience.
Mélanie Dallé
Senior Marketing Manager
DevOps
Platform Engineering
9
minutes
December 14, 2025
10 Best CI/CD Platforms for DevOps Teams: Automate Pipelines at Scale
Stop managing complex YAML and plugin hell. Compare the top 10 CI/CD platforms for DevOps, from Jenkins to Qovery, and learn how to build high-velocity, automated pipelines on your own cloud.