// the find
argoproj/argo-rollouts
Progressive Delivery for Kubernetes
Argo Rollouts extends Kubernetes with a custom controller and CRDs to give you canary and blue-green deployments that actually work — traffic shifting via your existing ingress or service mesh, plus metric-based automated promotion and rollback. It's for platform teams running Kubernetes at a scale where the default RollingUpdate strategy is too blunt. If you're deploying to a single cluster with a handful of services, this is probably more machinery than you need.
The metric analysis integration is the real payoff: you define AnalysisTemplates pointing at Prometheus, Datadog, or whatever you have, and the controller promotes or rolls back based on actual signal rather than just pod readiness. The plugin architecture for both traffic routing and metric providers means you're not locked into a specific ingress or observability stack — Gateway API support (even at alpha) shows they're tracking where Kubernetes networking is heading. The kubectl plugin gives you a useful `kubectl argo rollouts get rollout` watch view that shows canary weight and analysis status at a glance, which is genuinely better than trying to read Deployment events. Test coverage shows serious engineering discipline; the controller code has corresponding `_test.go` files throughout.
Stateful workloads are a known pain point — the docs acknowledge it but progressive delivery and PersistentVolumeClaims are a rough combination that you'll have to solve yourself. The CRD is a parallel resource to Deployment, not an enhancement of it, which means you have to migrate your existing Deployments over and any tooling that generates standard Deployments (Helm charts, CI templates) needs adapting — the Helm integration docs are there but it's still friction. Gateway API support is alpha, which matters because SMI (listed as stable) is effectively dead as a standard; if you build on SMI you'll be migrating again. The analysis step debugging experience is poor — when an AnalysisRun fails you're often reading raw Kubernetes events to figure out why a metric query returned what it did, and the error messages from metric providers can be cryptic.