How to Install Argo Rollouts with GitOps (Argo CD Integration)

Table of Contents

Why Combine Argo Rollouts with Argo CD

Argo Rollouts shines when used consistently across environments as part of a repeatable delivery pipeline. Argo CD excels at keeping Kubernetes clusters in sync with Git, treating manifests as the single source of truth. When you combine the two, you get a powerful GitOps‑driven progressive delivery setup in which both your applications and the rollout controller are declared in Git and continuously reconciled.

Instead of manually applying manifests for Argo Rollouts and hoping every cluster matches, you let Argo CD manage the installation and lifecycle of the controller. That way, changes to Argo Rollouts, such as version upgrades or configuration tweaks, flow through the same review, approval, and audit process as your application changes.

This guide walks through installing Argo Rollouts using GitOps with Argo CD, so that the controller is treated as part of your declarative platform.

What is Prerequisites and High‑Level Architecture

Before you start wiring the pieces together, make sure a few fundamentals are in place.

Argo CD is installed in the target cluster and you can access its UI or CLI.
You have a Git repository where cluster configuration lives. This might be a dedicated “cluster‑infra” repo or a section within a broader platform repo.
You have permissions to create namespaces, CRDs, and cluster‑level resources, either directly or through Argo CD’s service account.

The mental model is simple: Git holds the desired manifests for Argo Rollouts; Argo CD watches that repo and applies changes; Argo Rollouts then manages Rollout resources inside the same or other namespaces as your applications.

Step-by-Step Guide to Installing Argo Rollouts with Argo CD

Step 1: Decide Where Argo Rollouts Manifests Live in Git

The first decision is purely organizational: where will the Argo Rollouts manifests live in your Git structure? Common patterns include:

A dedicated platform/argo-rollouts/ directory inside a cluster‑config repo.
Environment‑specific folders like clusters/staging/argo-rollouts/ and clusters/prod/argo-rollouts/ when versions differ.

Choose a layout that mirrors how you already manage other controllers like Argo CD, ingress controllers, or metrics stacks. Consistency makes it easier for future maintainers to navigate.

Once you have decided, create the directory and prepare to add manifests.

Step 2: Add Argo Rollouts Manifests or a Helm Chart Reference

You can manage Argo Rollouts in Git either as plain manifests or as a Helm chart rendered by Argo CD. Both approaches work well in a GitOps flow.

Option A: Plain manifests

If you prefer to keep everything as YAML, you can download the official install.yaml file for the desired version and commit it into your repo. For example:

curl -Lo argo-rollouts-install.yaml \
https://github.com/argoproj/argo-rollouts/releases/<version>/install.yaml

Place this file under your chosen directory, such as platform/argo-rollouts/argo-rollouts-install.yaml, and commit it. Later upgrades will be as simple as updating this file to a new version.

Option B: Helm chart managed by Argo CD

If your organization already embraces Helm within Argo CD, you can configure an Argo CD Application that references the official Argo Rollouts Helm chart. In Application spec terms, you would use a helm source pointing at the Argo Helm repo with a specific chart version, and optionally a values file stored alongside the Application manifest in Git.

This approach keeps chart upgrades explicit and allows more flexible parameterization.

Step 3: Create an Argo CD Application for Argo Rollouts

With manifests or chart configuration in Git, the next step is to teach Argo CD about them via an Application resource. This Application is responsible for syncing Argo Rollouts into your cluster.

A minimal Application for plain manifests might look like this:

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

  name: argo-rollouts

  namespace: argocd

spec:

  project: default

  source:

    repoURL: https://github.com/your-org/cluster-config.git

    targetRevision: main

    path: platform/argo-rollouts

  destination:

    server: https://kubernetes.default.svc

    namespace: argo-rollouts

syncPolicy:

automated:

prune: true
selfHeal: true

Commit this manifest into the section of your Git repo where Argo CD expects Applications (for example, argocd/ or apps/). Then either let Argo CD discover it via an App‑of‑Apps pattern or apply it directly with kubectl.

Once created, the Application will sync the Argo Rollouts manifests from Git into the argo-rollouts namespace.

Step 4: Let Argo CD Perform the Initial Sync

With the Application defined, open the Argo CD UI or use the CLI to trigger an initial sync.

Using the CLI, you might run:

argocd app sync argo-rollouts

Argo CD will create the argo-rollouts namespace if needed, apply CRDs, roles, and the controller deployment, and then report sync status. Treat this like any other infrastructure Application: watch logs for failures and adjust manifests in Git if needed.

Once sync is healthy, the Argo Rollouts controller should appear as a standard Kubernetes Deployment in the argo-rollouts namespace, owned by the Argo CD Application.

Step 5: Verify Installation and GitOps Ownership

After the first sync, verify two things: that Argo Rollouts is running as expected, and that Argo CD clearly owns its resources.

Use kubectl to confirm the basics:

kubectl get deploy -n argo-rollouts
kubectl get crd | grep rollouts.argoproj.io

Then, in the Argo CD UI, inspect the argo-rollouts Application. You should see the Deployment, CRDs, and RBAC objects listed as managed resources with a green, synced status. Any drift you introduce by manually altering these objects in the cluster should be detected and, with selfHeal enabled, corrected by Argo CD to match the Git configuration.

Step 6: Manage Upgrades and Configuration Through Git

Once Argo Rollouts is managed as an Argo CD Application, upgrades become a Git change rather than a kubectl command.

For plain manifests, upgrading means updating the install.yaml file to a new version in a pull request. For Helm‑based setups, you would bump the chart version or adjust values in the Application spec or values file. In both cases, Argo CD will detect the change, display it in the UI, and sync when you approve.

This pattern keeps a clear audit trail of when and why Argo Rollouts was upgraded, which environments received the change, and what configuration adjustments accompanied it.

Step 7: Integrate Application Rollouts into the Same GitOps Flow

With the controller itself now managed via GitOps, the final step is to treat your Rollout objects the same way. Instead of creating Rollouts manually, define them in the application repos that Argo CD already manages.

When developers open pull requests to change application versions or rollout strategies, they will be modifying the same manifests Argo CD applies. The result is a cohesive picture where:

Argo CD keeps both Argo Rollouts and application Rollouts in sync with Git.
Argo Rollouts handles progressive delivery logic using those declared specs.

You can still use the kubectl argo rollouts plugin or UI to observe and occasionally intervene, but Git remains the source of truth.

Bringing It All Together: GitOps Workflow with Argo Rollouts

Installing Argo Rollouts with GitOps through Argo CD turns your progressive delivery controller into a first‑class citizen of your declarative platform. Instead of a one‑off installation, you have a repeatable, auditable process in which changes flow through Git, are reconciled by Argo CD, and are manifested as behavior in Argo Rollouts.

By investing a little time upfront to structure your repo, define a dedicated Application, and standardize how you represent Rollouts in manifests, you set your team up for safer, more predictable progressive delivery across every environment.

Conclusion: Seamless GitOps Integration

By 2026, the industry has moved beyond manual “Click-to-Deploy.” Combining Argo Rollouts with Argo CD is the logical evolution of the Kubernetes platform. Think of it this way: Argo CD is your Compliance Engine (ensuring Git matches the cluster), while Argo Rollouts is your Safety Engine (ensuring new code doesn’t break production).

When you install the controller using GitOps, you eliminate “snowflake” clusters. Your staging and production environments will run the exact same version of the controller, with the same RBAC rules, because they both pull from the same Git source of truth.

FAQ: Argo Rollouts + Argo CD (GitOps)

1. Does Argo CD conflict with Argo Rollouts during a Canary?

No, as long as you configure it correctly. The Conflict: By default, Argo CD wants to “correct” any difference between Git and the cluster. During a Canary, Argo Rollouts dynamically changes replica counts or traffic weights.
The Solution: In your Argo CD Application, set ignoreDifferences to true for the replicas field in your Rollout resources. This tells Argo CD: “I know the replicas are changing; let the Rollout controller handle it.”

2. Should I put the Argo Rollouts Controller and my Apps in the same Argo CD Project?

Best practice is to separate them. Infrastructure Project: Put the Argo Rollouts controller here. This project usually has ClusterAdmin permissions.
Put your actual app Rollout manifests here. This project can be restricted to specific namespaces, limiting the blast radius of a developer error.

3. How do I handle CRD updates via GitOps?

In 2026, the “App-of-Apps” pattern is the standard.
Use one Argo CD Application to manage the Argo Rollouts CRDs.
Use a second Application to manage the Controller Deployment. This ensures the API schema is always updated before the controller tries to use new features.

4. Can I use the Argo CD UI to “Promote” a Rollout?

Partially. While Argo CD shows you the status of the pods, it doesn’t natively have a “Promote” button for Argo Rollouts.
Most teams use the Argo Rollouts Extension for Argo CD. This adds a tab directly into the Argo CD UI that lets you see the canary steps and click “Promote” or “Abort” without leaving the browser.

5. What happens if I revert a commit in Git?

This is where GitOps shines. If you revert a commit in Git, Argo CD will immediately see the change and update the Rollout resource in the cluster. Argo Rollouts will then treat that as a “new” deployment and follow your defined strategy (e.g., a Blue-Green flip) to safely return you to the previous stable version.

Latest Post: