Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Bumps []( from 1.8.3 to 1.8.4.
- [Release notes](
- [Commits](stretchr/testify@v1.8.3...v1.8.4)

- dependency-name:
  dependency-type: direct:production
  update-type: version-update:semver-patch

Signed-off-by: dependabot[bot] <>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]>

Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Argo Rollouts - Progressive Delivery for Kubernetes

codecov slack CII Best Practices Artifact HUB

What is Argo Rollouts?

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.

Argo Rollouts (optionally) integrates with ingress controllers and service meshes, leveraging their traffic shaping abilities to gradually shift traffic to the new version during an update. Additionally, Rollouts can query and interpret metrics from various providers to verify key KPIs and drive automated promotion or rollback during an update.

Argo Rollotus Demo

Quick Start

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f

Follow the full getting started guide to walk through creating and then updating a rollout object.

Why Argo Rollouts?

Kubernetes Deployments provides the RollingUpdate strategy which provide a basic set of safety guarantees (readiness probes) during an update. However the rolling update strategy faces many limitations:

  • Few controls over the speed of the rollout
  • Inability to control traffic flow to the new version
  • Readiness probes are unsuitable for deeper, stress, or one-time checks
  • No ability to query external metrics to verify an update
  • Can halt the progression, but unable to automatically abort and rollback the update

For these reasons, in large scale high-volume production environments, a rolling update is often considered too risky of an update procedure since it provides no control over the blast radius, may rollout too aggressively, and provides no automated rollback upon failures.


  • Blue-Green update strategy
  • Canary update strategy
  • Fine-grained, weighted traffic shifting
  • Automated rollbacks and promotions
  • Manual judgement
  • Customizable metric queries and analysis of business KPIs
  • Ingress controller integration: NGINX, ALB, Apache APISIX
  • Service Mesh integration: Istio, Linkerd, SMI
  • Metric provider integration: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, InfluxDB

Supported Traffic Shaping Integrations

Traffic Shaping Integration SetWeight SetWeightExperiments SetMirror SetHeader
ALB Ingress Controller (stable) (stable) (alpha)
Ambassador (stable)
Apache APISIX Ingress Controller (alpha) (alpha)
Istio (stable) (stable) (alpha) (alpha)
Nginx Ingress Controller (stable)
SMI (stable) (stable)
Traefik (beta)

= Supported

= Not Supported


To learn more about Argo Rollouts go to the complete documentation.


You can reach the Argo Rollouts community and developers via the following channels:

Who uses Argo Rollouts?

Official Argo Rollouts User List

Community Blogs and Presentations