Helm is the most widely used package manager for Kubernetes. It allows Kubernetes administrators to manage deployments (also known as releases) of applications on a cluster, assigning resources and constraints to the deployed components.

At Qovery, Helm has been part of our platform’s foundation from the beginning. Our engine automatically pulls your code, builds a container image, and generates a custom Helm chart to deploy it seamlessly onto your Kubernetes cluster. This behind-the-scenes use of Helm was ideal for enabling automation without exposing its complexity to users. It aligned perfectly with our mission to eliminate the burden of managing infrastructure and configurations that would otherwise require advanced knowledge or a dedicated DevOps team.

A few years ago, we didn’t offer the possibility to deploy external Helm charts directly on a cluster due to the complexity and challenges involved:

• Secrets and sensitive values need to be passed securely and managed across environments.
• Custom Resource Definitions (CRDs) require careful handling and shouldn’t be managed freely by all users.
• Kubernetes version upgrades can break running applications if Helm charts are not kept up to date.
• Deeply nested configuration values in values.yaml files can become hard to manage and prone to errors.

Despite these challenges, there are situations where deploying a Helm chart directly is the only practical option. Many commercial or open source tools are distributed exclusively as Helm charts, making this method essential for installation. Examples include monitoring and observability tools like Datadog, Prometheus, and others.

That’s why we decided to make Helm a first-class citizen in Qovery and empower every developer to deploy their own Helm charts easily and safely.

This required us to rethink Helm integration from the ground up, with a strong focus on user experience: simple configuration, transparent deployment, safe updates, and full lifecycle management. No DevOps intervention needed.

In this article, we’ll walk through the challenges of managing Helm charts and the design decisions we’ve made to deliver on that promise.

Making Helm deployment easy

Below, we’ll walk through some of the key design decisions we made to reduce friction and make life easier for our users 👇

Helm sources management

One of the first challenges when dealing with Helm is managing the list of authorized sources from which charts can be pulled. By default, Helm lets you install anything from anywhere. While that power is great, it also introduces risks and opens the door to misconfigurations or unauthorized deployments.

To complicate things further, Helm supports multiple source types:

• Classic Helm repositories
• Git repositories
• OCI registries

Each of these behaves slightly differently, which can make integration messy and error-prone.

When designing our Helm integration, we studied how other platforms handled source management and decided to go all-in. Qovery supports all standard Helm source types, including Helm repositories, Git repositories, and OCI registries.

To ensure security and governance, only organization admins can define the list of whitelisted Helm sources.

This means:

• You have full control over what can be deployed.
• You can include access credentials and secrets for private sources.
• Developers don’t need to worry about source setup, they just select from a pre-approved list.

Once a source is registered, using it is easy. The interface retrieves for you the list of charts and versions available within the selected repository, reducing to zero the risk of selecting a non-existing chart of version.

Helm values management

(This was the part that drove us crazy.)

Helm charts are typically distributed with a values.yaml file, which defines configuration parameters and includes default values.

These values can be overridden via the Helm CLI to customize the deployment. The official Helm documentation outlines how this process works, but in practice, it can quickly become a mess, especially when managing multiple environments or dealing with deeply nested configuration trees. To give you an idea, you can look at the ~2500 lines Datadog values file here.

We focused on simplifying three critical pain points of this process:

1) Viewing and defining overrides

Understanding what configuration parameters you can override isn’t always obvious. You usually have to dig through the values.yaml file manually, often navigating layers of nested values.

To improve this, we integrated the default values.yaml directly into the resource creation UI. This gives users a clear side-by-side view of both the default values and the custom overrides they’re applying.

2) Dynamic values override

Often, Helm value overrides vary depending on the environment in which a chart is deployed. For instance, you might deploy the same chart across different clusters, each requiring unique settings.

To support this use case and instead of multiply the values override files, we extended Qovery’s environment variable system and introduced support for dynamic value resolution using Qovery macros.

You can define overrides using macros like qovery.env.QOVERY_KUBERNETES_CLUSTER_NAME, which will be automatically resolved at deployment time based on the target environment.

3) Testing Helm charts easily

We also wanted Helm deployments to feel as simple and fast as deploying application code from a Git repository.

You can choose between two options for managing your override values:

• Store in Git: Ideal for versioning and collaboration, especially in production scenarios.
• Store in the Qovery Control Plane: Useful for rapid iteration and testing changes quickly, without needing a full GitOps setup. Learn more about the control plane here.

In addition, we’ve added parameter-level overrides using the --set, --set-string, and --set-json options. This is perfect for quick tests where you only want to tweak a single value without modifying the whole values.yaml.

Improved security with self-service

Helm charts are a powerful way to deploy applications and services on Kubernetes, but they are not inherently safe for self-service usage, especially in shared or production environments.

Without proper permissions in place, anyone could deploy resources that affect the entire cluster, such as DaemonSets, CRDs, or other cluster-wide components. This poses a serious risk to cluster stability and security.

To strike the right balance between flexibility and control, we introduced a strict security boundary: by default, resources can only be deployed within the namespace associated with the Qovery environment where the Helm chart is defined.

Note: Each Qovery environment maps directly to a Kubernetes namespace.

If a Helm chart tries to deploy resources outside of its assigned namespace, the deployment is automatically blocked and the operation is aborted.

This approach ensures that Helm deployments remain safe and isolated, giving developers the ability to deploy confidently without compromising cluster integrity.

Of course, we also recognize that advanced users and platform engineers sometimes need to install cluster-wide resources. In these cases, Qovery administrators can override the namespace restriction by enabling the “Allow cluster-wide resources” option in the Helm settings of the Qovery console.

This opt-in mechanism allows full flexibility, but only under strict access control, keeping your clusters safe while still enabling power users when needed.

Exposing a service publicly

Out of the box, most Helm charts do not include everything needed to make deployed services accessible over the internet. Typically, they configure services with a ClusterIP, which restricts access to within the Kubernetes cluster. As a result, developers often need to use kubectl port-forward to access these services locally, far from ideal in a modern developer workflow.

On Qovery, exposing a service publicly is straightforward. When deploying a standard application, you can simply define the port and check the “Publicly exposed” option. Qovery takes care of the rest. On the next deployment, it will:

• Assign a domain name to the service and handle DNS configuration
• Automatically generate and apply an SSL certificate
• Create and manage the necessary Kubernetes Ingress resources

More info on public exposure settings

When it came to Helm deployments, we wanted to offer the exact same simplicity.

Once your Helm chart is deployed with Qovery, you can go to the chart’s settings and select directly from a dropdown:

• The service name you want to expose
• The port on which that service is running

Qovery will then automatically provision and deploy all the required infrastructure to make that service available on a secure, publicly accessible URL, no manual Ingress setup, no external DNS configuration, and no certificate management required.

Monitoring and logging

Monitoring the health of applications deployed via Helm charts can quickly become challenging. A single chart might spin up dozens of pods across different services, making manual tracking and log access nearly impossible, especially at scale.

At Qovery, we wanted to offer the same level of visibility and observability for Helm-based deployments as we do for applications deployed through our standard workflows.

To achieve this, we developed a dedicated Kubernetes controller that watches for resources created by Helm charts. This controller automatically injects specific labels and annotations into the deployed resources.

These labels allow the Qovery platform to:

• Identify which resources belong to which Helm deployment
• Monitor their real-time status
• Collect and surface logs directly in the Qovery console

This way, developers gain immediate access to pod logs and health metrics, even for complex Helm deployments, without any extra setup or configuration.

Last but not least: Kubernetes version upgrades

Everything might run smoothly, until you receive a notification from your cloud provider that it’s time to upgrade your Kubernetes cluster.

While clicking an “Upgrade” button may sound simple, the reality is often far from it. Kubernetes upgrades are notoriously painful, and one of the main reasons is Helm chart compatibility. Many charts are only compatible with specific Kubernetes versions, and upgrading without validation can lead to broken deployments and application downtime.

At some point, the Helm chart you’re relying on may no longer be compatible with a newer Kubernetes version. Proceeding with the upgrade without verifying this can result in your application failing post-upgrade.

To address this, we’ve integrated a proactive compatibility check into our Managed Kubernetes Cluster offering.

Before performing a cluster upgrade, Qovery automatically checks all Helm charts deployed on the cluster for compatibility with the target Kubernetes version. If any potential issues are detected, the upgrade is blocked and a clear warning is displayed in the UI. This includes:

• A list of incompatible Helm charts
• Details on the resources that may fail post-upgrade
• Recommendations for resolving the issues before retrying

This safety mechanism ensures your applications stay online and stable, even as your infrastructure evolves.

Helm deployment in action

Have a look at the video below showing the first version we delivered 👇

Conclusion

Helm is a powerful tool, but with that power comes complexity, especially when scaling across teams, environments, and use cases. At Qovery, we didn’t just want to “support” Helm. We wanted to redefine what using Helm could look like for developers: intuitive, secure, and frictionless.

From source management and dynamic value overrides to monitoring, access control, and upgrade safety, we built Helm support that works seamlessly in real-world environments and frees developers from the burden of infrastructure

If you want to know more about our Helm deployment feature, have a look at this material:

• Official documentation
• Blog announcement
• Tutorial on how to deploy Datadog and Kubecost

Ready to give it a try?

• Sign-up
• Book a demo