Most teams that adopt Kubernetes eventually hit the same wall: a standard Deployment object only knows how to roll pods out all at once or in a simple rolling window. There is no built-in way to send 5% of production traffic to a new version, watch error rates for ten minutes, and automatically back out if something looks wrong. That gap is why Argo Rollouts has become one of the default answers for progressive delivery on Kubernetes in 2026, and why “argo rollouts” now pulls roughly 880 monthly searches in the US with low keyword competition, according to DataForSEO search volume data pulled in September 2026.
This tutorial walks through installing Argo Rollouts v1.10.0 (released August 5, 2026, per the project’s GitHub releases page), wiring up canary and blue-green deployment strategies, connecting analysis templates that gate promotion on real metrics, and integrating the controller with Argo CD for a full GitOps loop. It also covers a critical security issue disclosed in late August 2026 that every team running the Argo Rollouts dashboard needs to address before going further. By the end you will have a working canary pipeline you can adapt to your own services, plus a troubleshooting reference for the errors you are most likely to hit.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Argo Rollouts Does and Why It Matters in 2026
Argo Rollouts is a Kubernetes controller and set of custom resource definitions (CRDs) that replace the standard Deployment object with a Rollout object supporting canary and blue-green release strategies, automated analysis, and experimentation. It is part of the Argo project family alongside Argo CD, Argo Workflows, and Argo Events, but according to the project’s own FAQ documentation, Argo Rollouts is a standalone controller that does not require Argo CD to be installed on the same cluster. It works well with Argo CD, which can read Rollout status through Lua-based health checks and even trigger actions like unpausing a rollout directly from the Argo CD UI, but you can run Argo Rollouts entirely on its own.
The core idea is simple: instead of shipping a new version to 100% of pods immediately, Argo Rollouts lets you define a sequence of steps. A typical canary sequence might send 10% of traffic to the new version, pause for five minutes while an AnalysisTemplate checks Prometheus for error rate and latency, then step up to 25%, 50%, and finally 100% if every check passes. If a metric breaches its threshold at any step, Argo Rollouts automatically pauses or aborts the rollout and routes traffic back to the stable version, without a human needing to watch a dashboard in real time.
This matters more in 2026 than it did a few years ago because deployment frequency keeps climbing while the blast radius of a bad release keeps getting more expensive. A team shipping multiple times a day cannot manually gate every release with a human watching dashboards for twenty minutes. Progressive delivery tooling like Argo Rollouts (and its closest competitor, Flagger) turns that gate into code that runs the same way every time, which is the whole point of treating deployment safety as an engineering problem rather than a process problem.
Prerequisites: Tools, Versions, and Cluster Requirements
Before starting, confirm you have the following. Version numbers below reflect what was current and verified through official sources as of September 10, 2026.
- A running Kubernetes cluster, version 1.26 or later (any managed offering — EKS, GKE, AKS — or a local cluster via kind or minikube works for this tutorial)
kubectlinstalled and configured to talk to your clusterhelmv3.x installed for the controller install- Argo Rollouts controller v1.10.0 (latest stable as of August 5, 2026) or the current release at the time you follow this guide — always check the GitHub releases page first
- The
kubectl-argo-rolloutsCLI plugin, installed via Krew or as a standalone binary - Cluster-admin or namespace-admin RBAC permissions to install CRDs and create a new namespace
- Optional but recommended: Prometheus running in-cluster if you want automated AnalysisTemplate-based promotion rather than manual promotion
- Optional: Istio, NGINX Ingress Controller, an AWS Application Load Balancer, or a Gateway API implementation if you want weighted traffic splitting rather than replica-based canary
You do not need Istio or a service mesh to follow this tutorial. Argo Rollouts supports a “basic canary” mode that adjusts the ratio of stable-to-canary pod replicas without any traffic-shaping integration at all, which is the fastest way to get a first rollout working before you add a mesh or ingress controller into the mix.
Step 1: Verify Your Cluster and Create a Namespace
Start by confirming your cluster version and creating a dedicated namespace for the controller. Keeping Argo Rollouts in its own namespace makes RBAC scoping and later upgrades much cleaner.
kubectl version --short
kubectl get nodes
kubectl create namespace argo-rolloutsIf kubectl version --short reports a server version older than 1.26, upgrade the cluster first. Gateway API integrations and some AnalysisTemplate features assume a reasonably current control plane, and running an end-of-life Kubernetes version alongside a fast-moving CRD-based controller is a common source of hard-to-diagnose errors later.
Step 2: Install the Argo Rollouts Controller via Helm
The officially documented Helm repository for Argo Rollouts is hosted at https://argoproj.github.io/argo-helm. Add it, update your local chart index, and install the controller into the namespace you just created.
helm repo add argo https://argoproj.github.io/argo-helm
helm repo update
helm install argo-rollouts argo/argo-rollouts \
--namespace argo-rollouts \
--version 2.x.xReplace 2.x.x with whatever Helm chart version currently maps to the controller image you want (the chart and the controller do not always share the same version string, so check helm search repo argo/argo-rollouts --versions before pinning). After the install finishes, confirm the controller pod is running and the CRDs landed correctly:
kubectl get pods -n argo-rollouts
kubectl get crd | grep argoproj.ioYou should see CRDs for rollouts.argoproj.io, analysistemplates.argoproj.io, clusteranalysistemplates.argoproj.io, analysisruns.argoproj.io, and experiments.argoproj.io. If any are missing, the Helm chart’s CRD installation step likely failed silently — rerun helm upgrade with --install or apply the CRD manifests directly from the GitHub releases page for your target version.
Step 3: Install the kubectl-argo-rollouts CLI Plugin
The controller manages Rollout resources, but the CLI plugin is what gives you a readable terminal view of a rollout in progress, plus commands to promote, pause, abort, and retry. The fastest path is through Krew, the kubectl plugin manager:
kubectl krew install argo-rollouts
kubectl argo rollouts versionIf you do not have Krew installed, download the platform-specific binary from the project’s GitHub releases page, make it executable, and place it on your PATH as kubectl-argo_rollouts so kubectl picks it up as the argo rollouts subcommand. Match the plugin version to your controller version where possible — mismatched major versions between the CLI and controller are a common source of “unknown field” errors when the plugin renders a rollout’s status.
Step 4: Lock Down the Dashboard Before You Turn It On (CVE-2026-82277)
Before you enable the built-in Argo Rollouts dashboard, you need to know about a critical vulnerability disclosed while this controller version was current. CVE-2026-82277, published August 28, 2026, describes the Argo Rollouts dashboard through version 1.10.0 binding to all network interfaces and exposing mutating rollout operations — including promote, abort, and restart actions — with no authentication, authorization, or CSRF protection. The CVE record on cve.org lists this as a critical-severity issue, and as of this writing no dedicated patched release had been published; the available guidance is to disable the dashboard or restrict network access to it rather than wait for a point release.
In practice, that means you should not run kubectl argo rollouts dashboard and expose it via a LoadBalancer Service or public Ingress. Keep it bound to localhost through kubectl port-forward, or if you need shared team access, put it behind an authenticating reverse proxy (an OAuth2 proxy sidecar, or your existing SSO gateway) and restrict the Service to ClusterIP only:
# Safe: dashboard only reachable from your machine
kubectl argo rollouts dashboard --port 3100
# In a separate terminal, once the controller is running
kubectl port-forward -n argo-rollouts svc/argo-rollouts-dashboard 3100:3100CVE-2026-56852 is unrelated to Argo Rollouts — it is a vulnerability in the golang.org/x/text/unicode/norm package (an infinite loop when handling invalid UTF-8 input), not a flaw in the argo-rollouts-gateway-api-router image, and it does not affect “versions before 0.16.0-r2”; if you plan to use Gateway API traffic routing later in this tutorial, pin that router image to 0.16.0-r2 or newer.
Step 5: Write Your First Canary Rollout Manifest
A Rollout resource looks almost identical to a standard Deployment — same selector, same pod template — except the spec.strategy block replaces the simple RollingUpdate settings with a canary step sequence. Save the following as rollout-canary.yaml:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-app
namespace: default
spec:
replicas: 6
revisionHistoryLimit: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: myregistry/web-app:1.2.0
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
strategy:
canary:
steps:
- setWeight: 10
- pause: { duration: 5m }
- setWeight: 25
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 10m }
- setWeight: 100Apply it and watch the rollout progress with the CLI plugin’s live view, which is far more readable than raw kubectl get output for a resource that changes state every few minutes:
kubectl apply -f rollout-canary.yaml
kubectl argo rollouts get rollout web-app --watchWithout a Service mesh or ingress controller wired in, this “basic canary” runs by adjusting the ratio of pod replicas — with 6 total replicas and a 10% weight, Argo Rollouts rounds up to run at least one canary pod while the rest stay on the stable version. It is a coarse approximation of real weighted traffic splitting, but it is enough to prove the mechanics work before you add a traffic-shaping layer.
Step 6: Add a Preview Service for Manual Testing
Most teams want a way to hit the canary version directly before it takes any production traffic — for smoke tests, a QA sign-off, or a manual click-through. Define two Services, one pointing at the stable pods and one at the canary pods, and reference them in the Rollout’s strategy:
apiVersion: v1
kind: Service
metadata:
name: web-app-stable
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: web-app-canary
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080spec:
strategy:
canary:
canaryService: web-app-canary
stableService: web-app-stable
steps:
- setWeight: 10
- pause: {}Note the pause: {} with no duration — that creates an indefinite pause, which requires someone (or a CI job) to explicitly run kubectl argo rollouts promote web-app to continue. This is the manual-gate pattern: useful for the first few rollouts on a service while you build confidence, before switching to timed or metric-based pauses.
Step 7: Configure Analysis Templates for Automated Promotion
Timed pauses are a starting point, but the real value of progressive delivery is gating promotion on actual service health. An AnalysisTemplate defines a metric query — typically against Prometheus — and a success condition. If you already run Prometheus in-cluster (via kube-prometheus-stack or similar), this is a small addition:
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
args:
- name: service-name
metrics:
- name: error-rate
interval: 1m
count: 5
successCondition: result[0] <= 0.05
failureLimit: 2
provider:
prometheus:
address: http://prometheus-operated.monitoring.svc:9090
query: |
sum(rate(http_requests_total{service="{{args.service-name}}", status=~"5.."}[2m]))
/
sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))Reference it from the Rollout's canary steps in place of a timed pause:
steps:
- setWeight: 10
- analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: web-app
- setWeight: 50
- analysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: web-app
- setWeight: 100With failureLimit: 2, the AnalysisRun tolerates two failed checks out of five before it marks the step as failed and Argo Rollouts automatically aborts the rollout, rolling traffic back to the stable ReplicaSet. This is the mechanism that turns a canary release from "someone watches a dashboard for twenty minutes" into "the pipeline either promotes itself or backs itself out, every time, the same way."
Step 8: Add Real Traffic Splitting With a Mesh or Ingress
Replica-ratio canary is a blunt instrument once you have more than a handful of pods. For precise, weight-based traffic splitting, Argo Rollouts integrates with a traffic-management provider that actually enforces the percentage split at the network layer. According to the project's traffic management documentation, supported providers as of August 2026 include AWS ALB Ingress Controller, Ambassador Edge Stack, Apache APISIX, Google Cloud load balancing, Gateway API, Istio, Kong Ingress, NGINX Ingress Controller, Service Mesh Interface (SMI), and Traefik Proxy, with a plugin system available for anything not natively supported.
An Istio-based configuration references a VirtualService and lets Argo Rollouts manipulate its weighted routes directly:
spec:
strategy:
canary:
canaryService: web-app-canary
stableService: web-app-stable
trafficRouting:
istio:
virtualService:
name: web-app-vsvc
routes:
- primary
steps:
- setWeight: 5
- pause: { duration: 2m }
- setWeight: 20
- pause: { duration: 5m }
- setWeight: 50
- pause: { duration: 5m }
- setWeight: 100For a Gateway API setup instead of Istio, swap the trafficRouting block to reference an HTTPRoute and remove this reference — CVE-2026-56852 does not pertain to the Gateway API router image (it affects an unrelated Go text-normalization package). Whichever provider you pick, test the traffic split with a load-testing tool like hey or k6 hitting the shared hostname, and confirm the observed ratio of stable-to-canary responses roughly matches the configured weight before trusting it in production.
Step 9: Set Up Blue-Green Deployments for Higher-Risk Releases
Canary releases are ideal for gradual, metric-gated rollouts of routine changes. Blue-green is the better fit when a release needs an all-or-nothing cutover — a schema-coupled deploy, or a change you want to validate completely in isolation before any production traffic touches it. The strategy block looks different but the underlying Rollout object is the same kind:
spec:
strategy:
blueGreen:
activeService: web-app-active
previewService: web-app-preview
autoPromotionEnabled: false
scaleDownDelaySeconds: 300
prePromotionAnalysis:
templates:
- templateName: success-rate
args:
- name: service-name
value: web-app-previewWith autoPromotionEnabled: false, the new ReplicaSet scales up fully behind the previewService, runs the prePromotionAnalysis against it, and waits for an explicit kubectl argo rollouts promote before the activeService selector flips over to the new pods. The scaleDownDelaySeconds value keeps the old ReplicaSet running for five minutes after cutover, which is your rollback window — kubectl argo rollouts undo during that window is a near-instant flip back rather than a fresh pod scheduling cycle.
Step 10: Integrate With Argo CD for a Full GitOps Loop
If you already run Argo CD for GitOps deployments, Argo Rollouts objects sync like any other Kubernetes resource — commit the Rollout YAML to your app's manifest repository and let Argo CD apply it. The integration point is health reporting: Argo CD uses a Lua health check to translate Rollout status (Progressing, Paused, Degraded, Healthy) into its own sync-status view, and it exposes a "Resume Rollout" action in its UI that maps to the same promote operation you'd run from the CLI. Nothing extra needs installing on the Argo CD side for this — the Lua checks for Argo Rollouts resource kinds ship as part of Argo CD's built-in health check library.
This pairing gives you a clean division of responsibility: Argo CD owns "what should be running, according to Git," and Argo Rollouts owns "how we get from the old version to the new version safely." Teams that already compared Argo CD against Flux for their GitOps layer can layer Argo Rollouts on top of either sync engine, since progressive delivery and GitOps reconciliation solve different problems.
Step 11: Monitor Rollouts With the CLI and Dashboard
Day-to-day, most teams live in the terminal rather than the dashboard once they trust the plugin's output. The three commands you'll use constantly:
# Live, color-coded view of a rollout's current step and pod state
kubectl argo rollouts get rollout web-app --watch
# List every rollout in a namespace with current status
kubectl argo rollouts list rollouts
# Full step-by-step history for post-incident review
kubectl argo rollouts status web-appFor the dashboard, remember Step 4: only run it behind kubectl port-forward or an authenticating proxy until a hardened release addresses CVE-2026-82277. When you do open it, it renders the same step timeline as the CLI but with a visual traffic-weight graph that is genuinely useful for demoing a rollout to people who don't want to read YAML.
Step 12: Promote, Pause, Abort, and Roll Back in Production
The operational commands you'll reach for when something needs a human decision mid-rollout:
# Skip the current pause and move to the next step immediately
kubectl argo rollouts promote web-app
# Skip every remaining step and go straight to 100%
kubectl argo rollouts promote web-app --full
# Stop a bad rollout and route all traffic back to stable
kubectl argo rollouts abort web-app
# Retry a rollout stuck in a degraded state after a transient failure
kubectl argo rollouts retry rollout web-app
# Revert to the previous stable revision entirely
kubectl argo rollouts undo web-appabort is the one to reach for during an active incident — it immediately sets the canary weight back to zero and marks the rollout as degraded without waiting for any in-flight AnalysisRun to finish. undo is closer to a full rollback and works even after a rollout has already completed and moved on to a new revision, which is the command you want a few hours after a bad release made it to 100% before anyone noticed.
Argo Rollouts Version and Release Timeline
| Version | Release Date | Notable Change |
|---|---|---|
| v1.10.0 | August 5, 2026 | Latest stable; current baseline for CVE-2026-82277 advisory |
| v1.9.1 | July 6, 2026 | Patch release on the 1.9 line |
| v1.9.0 | March 19, 2026 | Minor release adding traffic-routing and plugin refinements |
| v1.8.3 | June 5, 2025 | Prior long-lived stable release before the 1.9/1.10 cycle |
Always check the project's GitHub releases page before pinning a version in a production Helm values file — the Argo project ships frequently, and a version that was current when this tutorial was written may have a newer patch release by the time you read it, especially given the open CVE-2026-82277 advisory.
Traffic Routing Provider Support
| Provider | Integration Type | Best Fit |
|---|---|---|
| Istio | VirtualService weight manipulation | Teams already running Istio service mesh |
| NGINX Ingress Controller | Canary annotations on Ingress | Simple HTTP ingress setups without a mesh |
| AWS ALB Ingress Controller | Target group weighted routing | EKS clusters using ALB for ingress |
| Gateway API | HTTPRoute weight manipulation | Teams standardizing on the Kubernetes-native Gateway API |
| SMI (Service Mesh Interface) | TrafficSplit resource | Meshes implementing the SMI spec |
| Traefik Proxy | Weighted round-robin service | Traefik-based ingress deployments |
| Kong Ingress | Canary plugin weight control | API-gateway-centric architectures already on Kong |
Common Pitfalls When Adopting Argo Rollouts
Teams migrating from plain Deployments to Rollouts tend to hit the same handful of mistakes. Knowing them ahead of time saves a lot of debugging.
- Forgetting that HorizontalPodAutoscaler needs to target the Rollout, not a Deployment. If you migrate a service to a Rollout but leave an HPA pointed at a
DeploymentscaleTargetRef, the autoscaler silently does nothing. Update the HPA'sscaleTargetRef.kindtoRollout. - Exposing the dashboard publicly before patching for CVE-2026-82277. This is the single most consequential mistake covered in this guide — an internet-reachable, unauthenticated dashboard on a controller with promote/abort/restart powers is a direct path to a production incident triggered by someone who was never supposed to have access.
- Skipping a canaryService/stableService split and wondering why manual testing hits a random pod. Without separate Services, there's no way to deliberately hit only the canary pods for a smoke test — you get whatever the load balancer round-robins to.
- Writing an AnalysisTemplate query that measures too short a window. A 1-minute rate window on a low-traffic service can flap between pass and fail from noise alone. Widen the window or raise
count/failureLimituntil the signal is stable relative to your actual request volume. - Mismatching the kubectl plugin version against the controller version. The CLI and controller are versioned somewhat independently; a plugin that's several minor versions behind the controller can misrender newer strategy fields or throw parsing errors on rollout status.
- Leaving
scaleDownDelaySecondsat zero on a blue-green Rollout. That deletes the old ReplicaSet the instant traffic cuts over, which means anundoafter a bad promotion triggers a full cold-start reschedule instead of an instant rollback. - Treating replica-ratio canary as equivalent to real traffic-weight canary. With few replicas, a "10% weight" step can round up to one whole pod taking 33% of real traffic on a 3-replica service — not the small blast radius the number implies.
Troubleshooting Argo Rollouts
Eight issues that come up repeatedly in production, and the fix for each.
- Rollout stuck at "Paused" with no analysis running. Check whether the current step is an unconditional
pause: {}, which requires a manualpromote. Runkubectl argo rollouts status web-appto see the exact step index it's waiting on. - AnalysisRun stuck in "Pending" forever. Usually means the controller can't reach the metrics provider. Exec into a debug pod and curl the Prometheus address from the AnalysisTemplate directly to rule out a DNS or NetworkPolicy block.
- "unknown field" errors when applying a Rollout manifest. The CRD version installed by Helm doesn't match the API fields you're using. Re-run
helm upgradeto pull the latest CRDs, or check thatapiVersion: argoproj.io/v1alpha1is correct for your controller version. - Canary weight not actually splitting traffic. If you're relying on basic (replica-ratio) canary with a low replica count, the math may round the effective split far from the configured weight. Increase
replicasor add a real traffic-routing provider. - Rollout auto-aborts immediately on every deploy. The AnalysisTemplate's
successConditionis likely evaluating against a query returning no data (a fresh deploy with zero traffic yet), which Prometheus can return as null rather than zero. Add a fallback or widen the initial pause before the first analysis step. - Dashboard shows "connection refused" after port-forward. Confirm the dashboard Service and Deployment/Pod are actually in
Runningstate — a common cause is the dashboard component being disabled entirely in a minimal Helm values file. - Old ReplicaSets never get cleaned up. Check
revisionHistoryLimitin the Rollout spec; the default can be higher than teams expect, leaving several generations of ReplicaSets around and inflatingkubectl get rsoutput. - Argo CD shows the Rollout as "OutOfSync" even though it matches Git. This typically happens when the controller mutates the Rollout's status subresource in ways Argo CD's diff doesn't fully ignore. Confirm your Argo CD Application has the recommended
ignoreDifferencesrules for Rollout status fields, documented in the Argo CD health-check integration guide.
Argo Rollouts vs Flagger: Choosing a Progressive Delivery Tool
Flagger is the other well-known progressive delivery controller for Kubernetes, originally built around tight Istio integration and later expanded to other meshes and ingress controllers. The two projects solve the same core problem with different philosophies: Argo Rollouts replaces the Deployment object with its own Rollout CRD and gives you a CLI-driven, imperative promote/abort/retry workflow, while Flagger sits alongside your existing Deployment and drives progressive delivery through a separate Canary CRD that wraps it, leaning more heavily on automatic, metrics-only promotion by default.
| Factor | Argo Rollouts | Flagger |
|---|---|---|
| Workload model | Replaces Deployment with a Rollout CRD | Wraps an existing Deployment via a Canary CRD |
| Ecosystem | Part of the Argo project family (CD, Workflows, Events) | Originated in the Flux/CNCF ecosystem, mesh-agnostic today |
| Manual control | Rich CLI for promote, pause, abort, retry, undo | Primarily automated; manual intervention is less central |
| GitOps pairing | Commonly paired with Argo CD | Commonly paired with Flux |
| Traffic providers | Istio, NGINX, ALB, Gateway API, SMI, Traefik, Kong, APISIX, Ambassador, Google Cloud | Istio, Linkerd, App Mesh, NGINX, Gloo, Skipper, Traefik, Gateway API |
| Blue-green support | Native strategy type | Supported via mirroring and traffic shifting |
In practice, the choice often comes down to which GitOps engine you already run. Teams standardized on Argo CD tend to pick Argo Rollouts for the tighter status integration and shared CLI conventions; teams standardized on Flux tend to reach for Flagger for the same reason. If you're not committed to either GitOps engine yet, Argo Rollouts' more granular manual controls (particularly abort and undo as distinct, fast operations) tend to matter more once you're operating rollouts under real incident pressure rather than in a demo.
Advanced Tips for Production-Grade Progressive Delivery
Once the basic canary and blue-green flows are working, a few refinements make the setup materially more reliable in production.
- Use ClusterAnalysisTemplate for shared checks. If ten services all want the same error-rate-and-latency gate, define it once as a
ClusterAnalysisTemplaterather than copy-pasting anAnalysisTemplateinto every namespace. - Run Experiments for A/B testing, not just canary safety. The
ExperimentCRD spins up multiple ReplicaSets simultaneously (not a progression, a fixed side-by-side comparison) and is the right tool when you're testing two genuinely different implementations against each other rather than validating a single rollout is safe. - Wire rollout events into your existing alerting. The controller emits Kubernetes Events on every step transition and analysis failure — a lightweight event-forwarder into Slack or PagerDuty means a failed AnalysisRun pages someone immediately instead of waiting to be noticed on a dashboard.
- Pin the Gateway API router image explicitly if you use Gateway API traffic routing. Given CVE-2026-56852, don't rely on a floating
latesttag forargo-rollouts-gateway-api-router— pin to 0.16.0-r2 or newer in your Helm values. - Set conservative
failureLimitandcountvalues for early adoption, then tighten them. A generous failure tolerance while your team builds trust in the automated gate is safer than an aggressive one that aborts good rollouts on noise and trains engineers to ignore the tool. - Combine timed pauses with analysis, don't replace one with the other. A timed pause before the first analysis step gives new pods time to warm up (JIT compilation, connection pool priming, cache fill) before metrics are evaluated against them, avoiding false-positive failures from cold-start latency.
Complete Working Project: End-to-End Canary Pipeline
Putting every piece from this tutorial together, here is a single, complete Rollout manifest for a web service with a canary strategy, dual Services for manual testing, real traffic-weight routing through NGINX Ingress, and a Prometheus-backed AnalysisTemplate gating each promotion step. Save this as one file and apply it directly to a cluster running the Argo Rollouts controller and NGINX Ingress Controller.
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: web-app-success-rate
spec:
args:
- name: service-name
metrics:
- name: error-rate
interval: 1m
count: 5
successCondition: result[0] <= 0.05
failureLimit: 2
provider:
prometheus:
address: http://prometheus-operated.monitoring.svc:9090
query: |
sum(rate(http_requests_total{service="{{args.service-name}}", status=~"5.."}[2m]))
/
sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))
---
apiVersion: v1
kind: Service
metadata:
name: web-app-stable
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: web-app-canary
spec:
selector:
app: web-app
ports:
- port: 80
targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: web-app-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx
rules:
- host: web-app.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-app-stable
port:
number: 80
---
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: web-app
namespace: default
spec:
replicas: 6
revisionHistoryLimit: 3
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: myregistry/web-app:1.2.0
ports:
- containerPort: 8080
resources:
requests:
cpu: 100m
memory: 128Mi
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
strategy:
canary:
canaryService: web-app-canary
stableService: web-app-stable
trafficRouting:
nginx:
stableIngress: web-app-ingress
steps:
- setWeight: 5
- pause: { duration: 2m }
- analysis:
templates:
- templateName: web-app-success-rate
args:
- name: service-name
value: web-app-canary
- setWeight: 25
- pause: { duration: 5m }
- analysis:
templates:
- templateName: web-app-success-rate
args:
- name: service-name
value: web-app-canary
- setWeight: 50
- pause: { duration: 5m }
- setWeight: 100This is close to what a real production canary pipeline looks like: a warm-up pause before the first metrics check, two analysis gates at meaningfully different traffic percentages, and a readiness probe so new pods don't take traffic before they're actually ready to serve it. From here, the natural next steps are wiring the image tag to your CI pipeline (so a new build automatically updates spec.template.spec.containers[0].image and triggers a fresh rollout) and committing this manifest to the Git repository your Argo CD Application already watches, closing the GitOps loop end to end.
Frequently Asked Questions
Do I need Argo CD to use Argo Rollouts?
No. According to the project's own FAQ documentation, Argo Rollouts is a standalone controller and does not require Argo CD on the same cluster. It integrates well with Argo CD through Lua-based health checks, but you can run it entirely independently with plain kubectl apply or any other deployment mechanism.
Is the Argo Rollouts dashboard safe to expose publicly right now?
No. CVE-2026-82277, published August 28, 2026 with a critical severity rating, describes the dashboard through version 1.10.0 binding to all interfaces and exposing mutating rollout operations without authentication, authorization, or CSRF protection. Keep the dashboard behind kubectl port-forward or an authenticating proxy, and restrict the Service to ClusterIP, until a dedicated fix ships.
What's the difference between canary and blue-green strategies?
Canary gradually shifts a percentage of traffic to the new version in steps, with pauses and optional metric checks between each step. Blue-green runs the new version fully scaled up in isolation, validates it, then cuts over all traffic at once. Canary limits blast radius through gradual exposure; blue-green limits it through full pre-production validation before any exposure at all.
Can I use Argo Rollouts without a service mesh?
Yes. The "basic canary" mode adjusts the ratio of stable-to-canary pod replicas without any traffic-shaping integration, which works with zero additional infrastructure. It's a coarser approximation of a true percentage split, but it's a reasonable way to start before adding Istio, NGINX Ingress, Gateway API, or another supported provider.
How does Argo Rollouts compare to Flagger?
Both are CNCF-ecosystem progressive delivery controllers solving the same problem. Argo Rollouts replaces the Deployment object with its own Rollout CRD and offers a rich CLI for manual promote/pause/abort/undo operations, and pairs naturally with Argo CD. Flagger wraps an existing Deployment through a separate Canary CRD, leans more toward automated metric-only promotion, and pairs naturally with Flux. Neither is strictly "better" — the right pick usually follows whichever GitOps engine a team already runs.
Why did my rollout abort immediately after I applied it?
The most common cause is an AnalysisTemplate query evaluating against zero traffic on a freshly deployed canary — Prometheus can return null rather than a usable numeric result, which some success conditions treat as a failure. Add a timed pause before the first analysis step so the canary has real traffic to measure, and confirm your query has a sensible fallback for the no-data case.
What Kubernetes version do I need for Argo Rollouts?
Kubernetes 1.26 or later is the practical minimum for current Argo Rollouts releases and their CRD schemas. If you're also planning to use Gateway API-based traffic routing, confirm your cluster's Gateway API CRD installation is on a compatible version, since Gateway API and Argo Rollouts version independently of each other.
Does Argo Rollouts cost anything to run?
Argo Rollouts itself is open source and free under the Apache 2.0 license, distributed through the Argo project on GitHub and its official Helm chart repository. Your actual cost is the compute the controller and any additional canary/preview pod replicas consume during a rollout, plus whatever traffic-routing provider (Istio, an AWS ALB, a managed Gateway API implementation) you pair it with, which may carry its own infrastructure cost.
Related Coverage
- PlayFab Multiplayer Servers Setup: 12 Steps, 90 Min [2026]
- Sunshine and Moonlight on AWS G7: 12 Steps, 90 Min [2026]
- Migrate to AWS Graviton5: 12 Steps, 90 Min [2026]
- Deploy Agones on Kubernetes: 12 Steps, 90 Min [2026]
- How to Deploy AWS SAM Apps: 12 Steps, 90 Min [2026]
