# Argo Rollouts: canary and blue-green deployments on Kubernetes

> Argo Rollouts replaces the Kubernetes Deployment controller with a CRD that shifts traffic gradually and can abort an update on its own. It is a good fit for teams that already run an ingress controller or service mesh and need automated rollback; it is the wrong tool if you only want a slower rolling update.

**argoproj/argo-rollouts** — Progressive Delivery for Kubernetes

- Repository: https://github.com/argoproj/argo-rollouts
- Website: https://argo-rollouts.readthedocs.io/
- Stars: 3,589 · Forks: 1,216
- Language: Go
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/argoproj-argo-rollouts

## The gap Argo Rollouts fills between a Deployment and a real release process

A Kubernetes Deployment with the RollingUpdate strategy gives you readiness probes and a surge limit. The README is blunt about where that stops being enough: few controls over the speed of the rollout, no control over traffic flow to the new version, readiness probes that are unsuitable for deeper or one-time checks, no way to query external metrics, and an inability to automatically abort and roll back. In a high-volume production environment those gaps add up to an uncontrolled blast radius.

Argo Rollouts is aimed at the teams that feel that gap. It is a Kubernetes controller plus a set of CRDs, so the audience is platform engineers and release engineers who already run workloads on Kubernetes and who have an ingress controller or a service mesh in front of them. The project describes itself as providing blue-green, canary, canary analysis, experimentation and progressive delivery features. The unit of work is a Rollout object, not a Deployment.

## How the controller, the Rollout CRD and traffic shaping fit together

The architecture visible in the repository is a standard Kubernetes operator shape: cmd/, controller/, pkg/, rollout/, analysis/, metricproviders/, ingress/, service/ and ui/ sit alongside manifests/ and examples/. The controller watches Rollout objects and reconciles them, and the analysis/ and metricproviders/ directories are where metric querying lives.

Traffic shifting is delegated. Argo Rollouts integrates with ingress controllers and service meshes and uses their traffic shaping abilities to move traffic to the new version during an update. The README's integration table is the most important page for planning, because support is not uniform. NGINX Ingress, ALB, Ambassador, SMI, Traefik and Istio support SetWeight as stable; Contour supports it as beta; Apache APISIX and Gateway API support it as alpha. SetMirror is stable only on Istio and alpha there, and SetHeader is stable on ALB but alpha on APISIX, Istio and Gateway API. Contour and Gateway API are implemented as plugins. If your traffic layer is missing from that table, the controller has no lever to pull.

Metric analysis is the second half. Rollouts can query and interpret metrics from providers to verify key performance indicators and drive automated promotion or rollback. The listed providers are Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic and InfluxDB. go.mod confirms the dependency surface: prometheus/client_golang, influxdb-client-go, newrelic-client-go, go-wavefront, the AWS SDK v2 CloudWatch and ELBv2 clients, and the SMI SDK. That is a lot of third-party code pulled into the controller binary, and it is also why the provider list is what it is.

## Installing Argo Rollouts and running a first canary

The README's quick start is two commands. The first creates a namespace, the second applies the published install manifest for the latest release.

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

After that the README points to the getting started guide in docs/getting-started.md, which walks through creating and then updating a Rollout object. The repository ships example manifests under examples/, including rollout-canary.yaml, rollout-bluegreen.yaml, rollout-canary-preview.yaml, rollout-analysis-step.yaml, rollout-background-analysis-step.yaml, rollout-baseline-vs-canary.yaml and rollout-experiment-step.yaml, plus a cluster-analysis-templates.yaml and analysis-templates.yaml. Those files are the fastest way to see the shape of a Rollout spec without reading the API reference.

There is also a kubectl plugin. The Makefile names the binary kubectl-argo-rollouts, and the repository contains a server/ directory and a ui/ directory built from a Node 22 and pnpm pipeline in the Dockerfile, which is what backs the Argo Rollouts dashboard. The README itself does not document the plugin's subcommands or the dashboard's port, so check the docs before assuming a command exists.

## Where Argo Rollouts is the wrong tool

The first limitation is the traffic layer. Weighted traffic shifting is not a feature the controller implements itself; it is a feature it asks your ingress controller or mesh to perform. On a cluster with no supported ingress or mesh, a canary Rollout cannot gradually move traffic, which removes most of the reason to install it. The integration table also shows that capabilities are uneven: if you need traffic mirroring, only Istio lists it, and only as alpha. If you need header-based routing, ALB is stable while APISIX, Istio and Gateway API are alpha.

The second limitation is operational surface. You are adding a controller, a CRD, an optional dashboard, and a dependency tree that includes AWS, Datadog, New Relic, InfluxDB, Wavefront and Prometheus clients. The controller queries those systems during a rollout, so a metric provider outage becomes a release-path outage unless the analysis is configured to tolerate it. The README does not describe the failure semantics of a metric query that times out, and that is exactly the behaviour you want to understand before you let an AnalysisTemplate gate production.

The third is scope. Argo Rollouts manages the deployment of a workload. It is not a GitOps reconciler and it is not a workflow engine; the README positions it next to Argo CD and Argo Workflows in the community material rather than as a replacement for either.

## Argo Rollouts compared with Flagger and with a plain Deployment

The most direct alternative is Flagger, and the difference is mostly in where the policy lives. Flagger is built around the service mesh and ingress providers it already integrates with and drives a Kubernetes Deployment through a Canary custom resource; Argo Rollouts replaces the Deployment with its own Rollout CRD and puts the strategy, the steps and the analysis inside that object. The practical consequence is that with Argo Rollouts your workload kind changes, so anything that assumes apps/v1 Deployment objects (some dashboards, some autoscalers, some GitOps sync rules) needs to be checked. With Flagger the workload stays a Deployment and the canary object sits beside it.

Against a plain Deployment, the difference is the abort path. A Deployment can halt progression, but the README states it cannot automatically abort and roll back. A Rollout can, because the analysis step is part of the rollout definition. That is the single feature that justifies the extra moving parts, and if you do not intend to use metric-driven promotion, a Deployment with tuned maxSurge and maxUnavailable is simpler and has no controller to operate. The same logic applies when comparing against Istio alone: Istio gives you traffic splitting primitives, but not the rollout state machine, the analysis templates or the promotion and abort logic that read them.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived and the last push was on 2026-09-23, so this is a project under current development rather than a dormant one. The release cadence visible in the recent tags is steady: v1.10.0 on 2026-08-27, v1.9.1 on 2026-07-17, and v1.10.0-rc1 on 2026-07-03. The presence of a release candidate before the final tag suggests a staged release process rather than tags cut straight from master.

Upgrade cost is real but bounded. The install manifest is versioned by release URL, so an upgrade is a re-apply of a new manifest, and the CRDs move with it. The controller bundles clients for many metric providers, which means a CVE or a breaking change in any of those SDKs becomes your upgrade. go.mod pins k8s.io/api, k8s.io/apimachinery and k8s.io/apiextensions-apiserver at v0.34.5, so the supported Kubernetes version range is tied to that client-go generation; check it against your cluster before planning an upgrade.

The licence is Apache-2.0, which is permissive and includes an explicit patent grant. That is a normal choice for a CNCF-adjacent controller and imposes no copyleft obligation on your own manifests or application code. This is a description of the licence text, not legal advice; your own counsel decides what your distribution does.

## Conclusion

Adopt Argo Rollouts if you run a high-traffic service behind NGINX Ingress, ALB, Istio, Linkerd, SMI or Traefik and you want promotion or abort driven by measured metrics rather than by a readiness probe. Do not adopt it if a RollingUpdate with a readiness probe already matches your risk tolerance, or if your traffic layer is not on the supported integration list, because the controller cannot shape traffic it cannot reach. Before you commit, verify three things: which SetWeight and SetMirror capabilities your specific ingress or mesh supports in the table above, how your AnalysisTemplate queries behave when the metric provider is briefly unreachable, and whether your GitOps tool will fight the controller over the replica count on the Rollout object.

## FAQ

### What is Argo Rollouts?

It is a Kubernetes controller and a set of CRDs that add blue-green, canary, canary analysis, experimentation and progressive delivery to Kubernetes. It replaces the Deployment's RollingUpdate strategy with a Rollout object that can shift traffic and promote or abort based on measured metrics.

### What is the difference between Argo CD and Argo Rollouts?

Argo Rollouts manages how a workload is released inside a cluster; Argo CD is a GitOps reconciler that keeps cluster state in sync with Git. They are separate projects in the same organisation and the README lists them side by side in the community material rather than as substitutes.

### How do I install Argo Rollouts?

The README's quick start creates a namespace and applies the published install manifest for the latest release. The getting started guide in docs/getting-started.md then walks through creating and updating a Rollout object.

### Is Argo Rollouts free?

Yes. The repository is licensed under Apache-2.0, which is a permissive licence with an explicit patent grant and no copyleft obligation on your own code.

### How does Argo Rollouts compare with Flagger?

Flagger drives an existing Kubernetes Deployment through a Canary custom resource and leans on the mesh or ingress providers it integrates with. Argo Rollouts replaces the Deployment with its own Rollout CRD and puts the strategy, steps and analysis inside that object, so the workload kind changes.

## Sources

- [argoproj/argo-rollouts on GitHub](https://github.com/argoproj/argo-rollouts)
- [License: Apache-2.0](https://github.com/argoproj/argo-rollouts/blob/master/LICENSE)
- [Project website](https://argo-rollouts.readthedocs.io/)
- [README](https://github.com/argoproj/argo-rollouts/blob/master/README.md)
- [Releases](https://github.com/argoproj/argo-rollouts/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/argoproj-argo-rollouts