Installing Argo Rollouts: Helm vs kubectl — Which Method Should You Choose?

Q: 2. Does Helm handle CRD upgrades better than kubectl?

No, and this is a common pitfall. The Catch: By default, Helm does not upgrade CRDs (Custom Resource Definitions) if they already exist in the cluster to prevent accidental data loss. The 2026 Standard: Most teams using Helm for Argo Rollouts now use a "crds-only" manifest or a dedicated job to ensure the Rollout and AnalysisRun schemas stay in sync with the controller version. When using kubectl apply, CRDs are updated automatically, which is simpler but riskier.

Q: 3. Can I switch from kubectl to Helm later?

Yes, but it requires care. The Process: You cannot simply run helm install over a kubectl installation without causing resource conflicts. You typically have to "adopt" the existing resources into the Helm release by adding specific labels and annotations to the existing Argo Rollouts deployment and service accounts. The Tip: If you're just starting and think you'll want Helm eventually, start with Helm now to avoid the migration headache later.

Q: 4. Is there a performance difference between the two?

No. Once installed, the Argo Rollouts controller behaves identically regardless of how the YAML was delivered to the API server. The difference is entirely in Operational Overhead (how hard it is to upgrade) and Configuration Management (how hard it is to change settings).

Introduction

When setting up Argo Rollouts in a Kubernetes environment, one of the first decisions you’ll face is whether to install it using Helm or kubectl. Both methods are widely used, but each comes with its own advantages depending on your workflow, automation needs, and production requirements.

Helm offers a more structured and scalable approach, making it ideal for teams managing complex environments or multiple clusters. On the other hand, kubectl provides a straightforward and lightweight installation method that works well for quick setups and manual deployments. Understanding the differences between these two approaches helps you choose the best option for your infrastructure and deployment strategy.

In this guide, we’ll compare installing Argo Rollouts using Helm vs. kubectl, highlight the pros and cons of each method, and help you decide which installation approach best fits your Kubernetes environment.

Why Your Install Method Matters

When you first adopt Argo Rollouts, it is tempting to treat installation as a one‑off task: apply whatever manifest the docs recommend, confirm that the controller is running, and move on to writing Rollout specs. In practice, how you install and upgrade Argo Rollouts shapes the stability, repeatability, and security of your progressive delivery setup.

Most teams end up choosing between two primary approaches:

Applying the official manifests directly with kubectl.
Using a Helm chart to manage Argo Rollouts as a versioned release.

Both options are supported by the project and widely used in production. The right choice depends on how you currently manage Kubernetes infrastructure, how strictly you need to track versions, and how quickly you want to experiment. This article walks through both approaches, compares their trade‑offs, and helps you decide which one best fits your organization.

Quick Refresher: What Argo Rollouts Brings to Your Cluster

Before comparing install methods, it helps to restate what you are actually deploying. Argo Rollouts extends Kubernetes with a controller and a set of Custom Resource Definitions (CRDs) that introduce new resource types such as Rollout and AnalysisRun. Those resources let you implement canary, blue‑green, and other progressive delivery strategies without inventing your own control loops.

From an operations perspective, that means you are adding:

Cluster‑wide CRDs that must be kept in sync with the controller version.
A controller deployment that needs RBAC, service accounts, and configuration.
Optional components such as a metrics adapter and user interface.

Any installation method must handle these building blocks reliably and make it easy to reason about which version is running where.

Installing Argo Rollouts with kubectl Manifests

The simplest way to get started is to apply the project’s official install.yaml manifest directly with kubectl. This approach is ideal for quick evaluations, local development clusters, or environments where you do not yet have standardized tooling for managing cluster‑level add‑ons.

How the kubectl manifest approach works

In this model, installation is essentially a two‑step process:

Create a namespace such as argo-rollouts to host the controller.
Apply the published manifest that defines CRDs, roles, role bindings, and the controller Deployment.

The commands typically look like this:

kubectl create namespace argo-rollouts

kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

The manifest bundles everything Argo Rollouts needs. Once it is applied, the API server knows about the new resource types and the controller is scheduled into the namespace.

Pros of installing with kubectl

The direct manifest approach is attractive because it is straightforward and visible. You can open the install.yaml file, see exactly what is being created, and reason about it like any other Kubernetes YAML. For local experiments, this is often the fastest way to get something working.

This method also avoids introducing extra tooling into your workflow. If your team already relies on GitOps or plain kubectl to manage cluster add‑ons, applying a manifest for Argo Rollouts can fit naturally into that existing pattern.

Cons and operational caveats

The trade‑off is that you take on more manual responsibility for versioning and upgrades. When a new Argo Rollouts release appears, it is up to you to:

Update the manifest URL or file reference.
Confirm that CRD versions change as expected.
Coordinate controller upgrades across clusters.

Without a higher‑level tool to track releases, it is easier to end up with slightly different versions in staging and production or to forget which commit introduced a specific upgrade.

Installing Argo Rollouts Using Helm

Helm wraps Kubernetes YAML into versioned charts, giving you a clear unit called a “release” that can be installed, upgraded, and rolled back. Managing Argo Rollouts as a Helm release introduces an extra layer of indirection, but it also brings discipline to versioning and configuration.

Typical Helm installation flow

In a Helm‑based setup, you start by adding the chart repository and choosing a release name and namespace. A minimal example might look like this:

helm repo add argo https://argoproj.github.io/argo-helm

helm repo update

helm install argo-rollouts argo/argo-rollouts \

–namespace argo-rollouts \

–create-namespace

Helm will render the chart templates into concrete manifests and apply them to your cluster. Behind the scenes, it records the release metadata so subsequent upgrades and rollbacks know which resources belong to this release.

Benefits of Helm for Argo Rollouts

Using Helm for Argo Rollouts aligns well with teams that already manage other cluster‑level components as charts. The advantages show up in several areas:

Version tracking: You can pin a specific chart version in Git, making it unambiguous which Argo Rollouts version runs in each environment.
Upgrades and rollbacks: helm upgrade and helm rollback give you controlled, auditable transitions between versions.
Configuration overrides: Values files let you customize settings such as resource limits, RBAC nuances, or metrics adapter configuration without forking the chart.

In multi‑cluster or multi‑environment setups, Helm helps ensure that your progressive delivery controller is configured consistently everywhere.

Potential downsides and complexities

The primary cost of using Helm is the additional tool and abstraction. Teams that prefer plain manifests may find values.yaml indirection and templating harder to reason about at first. You also depend on the chart maintainers to expose configuration options cleanly; in some cases, very custom setups still require you to fork or extend the chart.

Comparing Helm vs kubectl for Different Use Cases

Once you understand how each method works, the decision often comes down to your team’s maturity and the role Argo Rollouts plays in your platform.

For quick local trials, direct kubectl installs shine. You can spin up a kind or minikube cluster, apply the manifest, and start experimenting with Rollout resources in minutes. If you break something, tearing the cluster down and recreating it is trivial.

In long‑lived staging and production clusters, Helm’s release model becomes more compelling. It gives you a clear, repeatable path for upgrades, and it fits nicely into environments where infrastructure changes are gated by pull requests and change management.

For GitOps setups using Argo CD, the picture is more nuanced. You can manage Argo Rollouts either as a raw manifest (tracked in Git and synced by Argo CD) or as a Helm chart rendered through Argo CD’s Helm integration. Both patterns work; the right choice depends on whether you already standardize on “Helm‑as‑the‑source” or prefer to keep everything as plain YAML in the repo.

Practical Recommendations

In practice, many teams end up with a hybrid story. They start with the manifest approach to become comfortable with Argo Rollouts concepts and then migrate to Helm once they decide to keep it as a permanent part of their platform.

If you are in an early exploration phase, using kubectl apply against the official install.yaml is perfectly reasonable. Just be intentional about documenting which commit or release you used so that future upgrades are not guesswork.

If Argo Rollouts is already central to how you ship changes, investing in a Helm‑based installation usually pays off. The extra structure around versions, values, and rollbacks mirrors the discipline you’re probably applying to your applications themselves.

Choosing a Path Forward

Ultimately, there is no single “correct” way to install Argo Rollouts. The key is to align your installation method with how you manage the rest of your Kubernetes platform. If Helm is already your standard for cluster‑level components, bringing Argo Rollouts into that ecosystem keeps things consistent. If your team leans on GitOps with plain YAML and minimal tooling, direct kubectl installs can stay simple and transparent.

Whichever path you choose, treat Argo Rollouts as infrastructure with a lifecycle, not as a one‑time install. Document your chosen method, versioning strategy, and upgrade process so that future changes remain predictable and safe.

FAQ: Installing Argo Rollouts Using Helm vs. kubectl

1. Which method is better for GitOps (Argo CD)?

While both work, Helm is generally preferred for GitOps in 2026.
The Reason: Helm charts allow you to define a Chart.yaml with a specific version. Argo CD can then monitor that version and alert you if the upstream chart is updated.
The Alternative: If you use kubectl, you are essentially managing “Flat YAML.” While simple, you lose the ability to easily toggle features (like the Dashboard or High Availability mode) via a single values.yaml file.

2. Does Helm handle CRD upgrades better than kubectl?

No, and this is a common pitfall. The Catch: By default, Helm does not upgrade CRDs (Custom Resource Definitions) if they already exist in the cluster to prevent accidental data loss.
The 2026 Standard: Most teams using Helm for Argo Rollouts now use a “crds-only” manifest or a dedicated job to ensure the Rollout and AnalysisRun schemas stay in sync with the controller version. When using kubectl apply, CRDs are updated automatically, which is simpler but riskier.

3. Can I switch from kubectl to Helm later?

Yes, but it requires care. The Process: You cannot simply run helm install over a kubectl installation without causing resource conflicts. You typically have to “adopt” the existing resources into the Helm release by adding specific labels and annotations to the existing Argo Rollouts deployment and service accounts.
The Tip: If you’re just starting and think you’ll want Helm eventually, start with Helm now to avoid the migration headache later.

4. Is there a performance difference between the two?

No. Once installed, the Argo Rollouts controller behaves identically regardless of how the YAML was delivered to the API server. The difference is entirely in Operational Overhead (how hard it is to upgrade) and Configuration Management (how hard it is to change settings).

5. What is the “Values.yaml” advantage?

In 2026, Argo Rollouts has many optional “knobs.” Using Helm’s values.yaml, you can easily:
Enable High Availability (HA) replicas.
Set specific CPU/Memory limits for the controller.
Configure Service Mesh integrations (Istio/Linkerd) via simple flags. Doing this with raw kubectl manifests requires manually editing long, complex YAML files.

Latest Post: