Kubernetes Helm charts and operators share a little in common – starting with the fact that both terms are poster children for non-self-explanatory jargon. Even for folks with programming experience, the term operator in the context of Kubernetes might not make a lot of sense because it has nothing to do with operators in coding.

As for Helm charts, you literally need to speak Greek – or at least know that Kubernetes is derived from a Greek word meaning navigator – and you have to have an appreciation for cheeky, self-referential jargon to have any idea why a Helm chart is called what it is. (In case it's still not clear, the answer is that a Helm chart helps "steer" Kubernetes, just as a Helm steers a ship.)

But beyond their shared affinity for being terms that don't make a lot of sense to the uninitiated, operators and Helm charts don't share much in common. True, they both serve the same basic goal of helping to install and configure apps in Kubernetes. But they do so in different ways. Depending on factors like how much control you want and how important ongoing application lifecycle management is, an operator might be better than a Helm chart, or vice versa.

With that reality in mind, keep reading for a detailed comparison of Kubernetes operators and Helm charts, along with tips on which solution to use and when.

What is a Kubernetes operator?

In Kubernetes, an operator is a type of controller that can install and manage applications using Kubernetes custom resources. To explain what that means in a bit more detail, let's unpack two keywords from that definition: Controller and customer resource.


A controller in Kubernetes is a routine that monitors the state of Kubernetes configurations, as well as the actual state of Kubernetes cluster resources. When it detects a deviation between the desired and actual states of a given resource – which may occur either because an admin modified the configuration or due to some kind of failure inside your Kubernetes clusters – the controller attempts to bring the desired and actual states back into alignment.

So, if you deploy a configuration that describes how you want an application to behave, a controller will detect the configuration and then apply it (assuming it's possible to apply given the state of your Kubernetes clusters as a whole).

Custom resources

A custom resource in Kubernetes is an extension of the Kubernetes API that makes it possible to add functionality to a Kubernetes cluster that is not available by default. You can do this by creating a custom resource definition, or CRD.

If you want to install or manage an app using Kubernetes operators, you can create a CRD that implements whichever functionality the app needs to support. If you then accompany the CRD with a controller as part of an operator, the Kubernetes controller routine will detect and deploy it.

Kubernetes operators example

For those looking for a basic Kubernetes operator example, the hello-operator2 code (courtesy of Deepak Sharma) is a good sample. We won't copy all of it here, but let's show some of the key components.

First, the operator defines some basic contextual parameters:

Then, it implements a function that checks the deployment status:

And then it creates a new deployment:

If you want more Kubernetes operator examples, check out OperatorHub.io, which hosts hundreds of freely available Kubernetes operators for popular apps.

What is a Helm Chart?

Now that we know all about Kubernetes operators, let's talk about Helm and what Helm charts enable.

A Helm chart is a package that contains the resources necessary for deploying an application on Kubernetes using a packaging format called charts. You can install Helm charts with (you guessed it!) Helm, an application package manager and configuration management tool for Kubernetes.

Helm charts and the Helm package manager are similar to Debian packages and apt-get on Ubuntu, or RPM packages and DNF on Red Hat, with just one key difference: Unlike application packages for operating systems, Helm charts usually don't contain application binaries. Instead, they contain files that point to the container image or images that need to be installed to deploy an application.

Helm chart example

You can find an example Helm chart for a basic "hello world" app in the Helm project's GitHub repository. The repo contains two key files.

First, there is Chart.yaml, which contains configuration data for the Helm chart:

Then, there is values.yaml, which defines the application itself:

To use a Helm chart like this, you'd first add install the helm CLI tool on your system. Then, you add a repository that contains the Helm chart you want to install using a command like:

helm repo add repo-name https://some-domain.com/path/to/repo

Then update your repository list with:

Finally, install the app with:

You can also use Helm to update and remove applications, but we'll save a comprehensive guide to using Helm for another post.

Kubernetes operator vs Helm: 11 key differences

If you've read this far, you know that Kubernetes operators and Helm charts are both means to the same end: Installing and managing applications. Both can also be used to deploy tools that assist with Kubernetes troubleshooting and Kubernetes monitoring.

But Kubernetes operators and Helm charts enable these goals in somewhat different ways. Here's a breakdown of the key differences between operators and Helm charts.

#1. Scope and functionality

In general, Helm charts have a narrower scope. The main purpose of Helm charts is to install standard applications, meaning those that can run based on existing container images. Helm isn't a great solution if you need to run a custom app that depends on special Kubernetes API extensions, for example, although you could use an operator for that purpose.

Similarly, Helm offers less flexibility in terms of configuration. You can pass parameters to Helm while installing a chart to configure an application, but only if the chart was designed to support those parameters.

In contrast, with Kubernetes operators, the sky – or, more specifically, the code you write – is the limit when it comes to customizing your app.

#2. Complexity and flexibility

The tradeoff for operators' increased flexibility as compared to Helm is that operators are also more complex. Creating an operator requires the ability to write a CRD, whereas you can create a Helm chart based on some relatively simple YAML code.

Plus, from the perspective of installation, Helm is less complex because you can install it with just one command. Installing operators typically involves running long kubectl commands.

#3. Customization

As we mentioned, operators offer more room for customization because you can implement any functionality that is supported by a CRD. Some aspects of Helm chart configurations are possible to customize, but only if the developers who created the Helm chart implemented configuration options when building the chart.

The difference here is a bit like the distinction between building a standard application from source code and installing one using a package. When you build from source, you can modify the source to customize the app however you want. But if you install using a package, you can only modify whichever configuration options are supported by your package management system and environment.

#4. Cloud cost considerations

Because charts are generally not as customizable as operators, they have a greater tendency to impose bloat on your environment. A Helm chart may install and run application features that you don't strictly require, and unless you rewrite the entire chart, there may be no way to turn those features off. In contrast, with an operator, you have finger-grained control over exactly what runs.

As a result, Helm may increase cloud costs because apps installed using charts are more likely to consume a greater amount of resources. In general, this issue will have less of an overall impact on your cloud spending than problems like memory leaks or buggy code that wastes CPU, but it's still something worth thinking about if you want to optimize for cost.

#5. Learning curve

It's a safe bet that almost everyone will find it easier to learn how to work with Helm than with operators. Charts work in a pretty similar fashion to any type of software package, so if you have experience working with packages in other contexts, you should be able to pick up Helm quite quickly.

In contrast, operators are based on concepts that are unique to Kubernetes. You shouldn't expect to understand how operators work – let alone how to create or modify one – until you've wrapped your head around key Kubernetes concepts, like controllers and CRDs.

#6. Automation

Operators and charts both help to automate application installation and management tasks, which you'd otherwise have to perform by hand. However, Helm doesn't offer as much automation functionality because (as noted above) its scope is limited to managing standard applications.

You can use Helm to automate the installation or updating of an application based on a container image, but you can't automate bespoke application configuration changes that fall outside the scope of Helm's native functionality. With operators, however, you can automate any operation that is supported by the Kubernetes API and controllers.

#7. Lifecycle management

Operators and charts both support application lifecycle management in the sense that you can install, update, and delete applications using them. With Helm, however, lifecycle management is a bit blunter and less fine-tuned.

To manage application lifecycles using Helm, you're limited to built-in commands like install, upgrade, and uninstall. You can rip-and-replace one application version with a new one, or remove an application entirely. But you can't make slight modifications to an existing app, without upgrading the entire thing, in the way you could by modifying an application's operator.

#8. Maintenance

Similarly, operators provide more flexibility and control when it comes to application maintenance. If you just want to upgrade or delete an app, you can do it with Helm. But if you want to perform other application maintenance tasks, like modifying the storage configuration of an app, Helm won't help unless you create a new Helm chart and use it to reinstall your app. With operators, though, you can make finer-grained maintenance changes.

#9. Use cases

All in all, operators support a wider range of use cases than Helm. The latter excels only at application installation, upgrades, and removal. Operators can do those things, but they also support use cases like application backups.

#10. Suitability for GitOps

Illustration explaining GitOPs in a nutshell, where the configurations of your app data can be automatically pushed to production

GitOps means managing changes to application deployments and infrastructure using code stored in Git repositories. If you store configuration data for your apps and infrastructure in Git, you can automatically push the configurations to production from there. You can also track changes to your resources based on the version history of your code in Git.

Since you can store the code for operators as well as charts in Git, both solutions are compatible with a GitOps methodology. That said, you could argue that GitOps provides more benefits when used with operators because the changes you could make to operators are broader in scope. In that sense, there is more value in being able to track changes in a granular fashion. With GitOps, a change to just a single line of code in an operator would be easy to track – which might be useful if, for instance, you change the operator, something breaks and you want to figure out which change triggered the problem.

#11. Community and ecosystem

Strong communities and ecosystems exist for both operators and Helm. It's easy to find publicly available operators and Helm charts on sites like OperatorHub.io and Artifact Hub. Plenty of documentation about both solutions is also freely available.

That said, one important difference between operators and Helm with regard to community engagement is that Helm is an open source project with its own set of official resources, whereas there is no specific project dedicated to operators (although the Kubernetes project maintains documentation on them). In that sense, there is a specific "official" community for Helm, but not for operators.

Kubernetes operator vs Helm: Which one to choose?

There are two ways to approach the question, "Should I choose operators or Helm?" They depend on whether you're distributing an application to other users, or simply want to install one.

Application distribution

Consideration          What to choose           
Stateless app Helm charts
App requires customization Operators
Users have limited Kubernetes experience Helm charts
Need to support complex maintenance Operators

If you're distributing an app, choose Helm charts if:

  • Your app is straightforward.
  • The configuration is relatively simple (or you don't need to support many configuration options at installation time).
  • You want to provide your users with the simplest possible installation experience.
  • Your app is stateless and does not otherwise require special configurations.

Operators are a better choice for distribution if:

  • Your app requires special functionality or configurations (like complex stateful storage) that are difficult or impossible to implement without CRDs.
  • You want to automate additional processes (like application backups) beyond app installation or lifecycle management.

Application installation

Consideration      What to choose    
No Helm chart is available Operator
Simple installation is a priority Helm chart
Your Kubernetes experience is limited Helm chart
You want to customize the app Operator

If you're a user looking to install an app on Kubernetes, you should first check whether operators and/or Helm charts for the app exist. Many projects offer both, but if only one or the other is available, that answers the question about how to install the app: Use whatever exists.

If you can find both operators and charts, opt for Helm if:

  • You want a simple installation experience.
  • You don't need to customize the app.

A Kubernetes operator makes more sense if you're already familiar with operators, and/or you need to customize the app in ways that aren't possible using Helm.


Sometimes, there's no clear advantage to using operators instead of Helm, or vice versa. After all, both solutions support most of the same use cases.

But under the hood, operators are more complex and customizable, which is an advantage for advanced application installation or maintenance tasks. For simpler needs, Helm charts are typically the better solution.

Sign up for Updates

Keep up with all things cloud-native observability.

We care about data. Check out our privacy policy.

We care about data. Check out our privacy policy.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.