Written by Nelson Koning
on September 10, 2025

Argo Rollouts vs. Flagger: The Ultimate Kubernetes Canary Cage Match

Let’s be honest. Throwing a new version of your application into production and just hoping it works is the software equivalent of skydiving with a backpack you found at a garage sale. You think it’s a parachute. It smells like a parachute. But until you pull the cord, it’s just faith-based deployment.

Thankfully, in the modern Kubernetes ecosystem, we’ve moved beyond such barbaric practices. We have tools that allow us to be sophisticated, graceful, and intelligent about how we release our software. Today, we’re pitting two of the heavyweight champions of the progressive delivery ring against each other: Argo Rollouts and Flagger.

It’s the canary cage match you didn’t know you needed. Let’s get ready to rumble.

Tale of the Tape: What Are We Even Talking About?

Before we let them swing at each other, let’s size up our contenders.

Progressive Delivery is the evolution of continuous deployment. Instead of bombarding all your users with v2.0 all at once, you slowly, carefully, and intelligently roll it out. You send a small percentage of traffic its way, see if it starts crying (i.e., throwing 5xx errors), measure its performance, and only proceed if it meets your strict, parent-like expectations. The two most common strategies are:

Canary Release: A cautious, measured rollout. You release the new version to a small subset of users (e.g., 10%), monitor it, and if all looks good, gradually increase the percentage until it completely replaces the old version.
Blue-Green Deployment: You have two identical environments: Blue (current version) and Green (new version). You deploy the new version to Green and test it thoroughly. Once it’s ready, you switch all traffic from Blue to Green in one fell swoop. It’s a instant cutover, not a gradual one.

Now, let’s meet our gladiators.

Contender #1: Argo Rollouts

Argo Rollouts is a Kubernetes controller and set of CRDs (Custom Resource Definitions) that provide advanced deployment capabilities. It’s part of the larger, incredibly powerful Argo Project, which includes Argo CD (GitOps), Argo Workflows, and Argo Events.

Key Weaponry:

A custom resource called, you guessed it, Rollout. It’s designed to be a drop-in replacement for the standard Kubernetes Deployment resource.
Deep integration with service meshes (Istio, Linkerd, SMI) and ingress controllers (NGINX, ALB) to control traffic flow.
Native integration with metrics providers (Prometheus, Datadog, Wavefront, etc.) for automated analysis-based rollbacks.
A killer web UI if you’re already using Argo CD.

Contender #2: Flagger

Flagger is a progressive delivery tool that operates as a Kubernetes operator. It’s part of the Flux family of GitOps tools and is a CNCF project. Its philosophy is different: instead of replacing the Deployment, it works alongside it.

Key Weaponry:

It automates the promotion of canaries using metrics from providers like Prometheus, Datadog, and others.
It works with a variety of providers: service meshes (Istio, Linkerd, App Mesh), ingress controllers (NGINX, Gloo, Contour), and even just a simple Kubernetes Service.
It defines its canary process through a custom resource called a Canary.
Its superpower is its simplicity in getting a basic canary setup running.

Round 1: Installation and Setup

Argo Rollouts

Installing Argo Rollouts is a straightforward kubectl affair.

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

This gets you the controller. You’ll also want the nifty CLI plugin that gives you a dashboard-like view of your rollouts:

brew install argoproj/tap/kubectl-argo-rollouts

Now, the real work begins. You need to configure your traffic routing. If you’re using Istio, for example, you’ll need to ensure you have a VirtualService and Service defined to split traffic between your stable and canary versions. Argo Rollouts gives you the power but also expects you to know how to drive the manual transmission.

Flagger

Flagger installation is also simple, often requiring a Helm chart.

helm repo add flagger https://flagger.app
helm upgrade -i flagger flagger/flagger \
  --namespace=istio-system \
  --set meshProvider=istio

Here’s where Flagger starts to feel a bit different. Its Canary resource is a meta-object that defines the process around an existing Deployment. You don’t replace your Deployment; you create a Canary resource that points to it. Flagger then takes that Deployment and creates a series of child resources (e.g., a second deployment for the canary, services, etc.) to manage the process.

Winner of Round 1: It’s a tie. Both are easy to install. Argo Rollouts gives you more direct control, while Flagger can feel a bit more magical by automating the creation of auxiliary resources.

Round 2: Configuration & The GitOps Experience

This is where their philosophies truly diverge.

Argo Rollouts: The Declarative Purist

With Argo Rollouts, you are declaring your entire desired state. You write a Rollout manifest that looks strikingly similar to a Deployment but with a strategy section that contains all your canary steps and analysis.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  strategy:
    canary:
      canaryService: my-app-canary-svc # Service pointing to canary pods
      stableService: my-app-stable-svc # Service pointing to stable pods
      trafficRouting:
        istio:
          virtualService:
            name: my-app-vs
            routes:
              - primary
      steps:
        - setWeight: 10
        - pause: { duration: 5m } # Wait 5 minutes
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100

You apply this YAML, and the Argo Rollouts controller works to make the cluster match what’s on paper. This is GitOps nirvana. Your entire application deployment process is version-controlled and declarative.

Flagger: The Process Automator

Flagger’s Canary resource doesn’t replace your Deployment; it wraps a process around it.

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  service:
    port: 9898
  analysis:
    interval: 1m
    threshold: 5
    iterations: 10
    metrics:
      - name: request-success-rate
        threshold: 99
        interval: 1m
      - name: request-duration
        threshold: 500
        interval: 1m

You still have your regular, boring, old Deployment YAML. The Canary resource is a separate entity that says, “Hey, see that Deployment over there? When it changes, here’s the fancy, progressive way I want you to roll it out.”

Winner of Round 2: Argo Rollouts, by a nose, for the GitOps enthusiast. Having the entire rollout strategy defined in a single, version-controlled resource that replaces the standard Deployment is incredibly clean and powerful. Flagger’s approach is clever and less intrusive, but having the process separated from the app definition can feel a bit disjointed.

Round 3: The “Oh Crap!” Factor: Automated Rollbacks

This is the main event. Anyone can slowly send traffic to a new pod. The real value is in the automated rollback when your new code is a dumpster fire.

Both tools integrate with metrics providers to do this. The concept is similar: you define a metric (e.g., error rate > 5%) and if that metric is violated during the canary phase, the rollout is aborted and automatically rolled back.

Argo Rollouts Analysis

Argo uses a concept called AnalysisTemplates. You can define a template that queries Prometheus and defines the failure conditions.

# In your Rollout spec
analysis:
  templates:
    - templateName: success-rate
  args:
    - name: service
      value: my-app-service.default.svc.cluster.local

---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 5m
      successCondition: result[0] >= 0.95 # Roll back if success rate < 95%
      failureLimit: 3
      provider:
        prometheus:
          address: http://prometheus.example.com:9090
          query: |
            sum(rate(istio_requests_total{reporter="destination", destination_service=~"", response_code!~"5.*"}[5m])) / sum(rate(istio_requests_total{reporter="destination", destination_service=~""}[5m]))

This is incredibly powerful but also complex. You’re essentially writing PromQL queries in your YAML. It’s the “you can have whatever you want, you just have to build it yourself” approach.

Flagger Analysis

Flagger bakes a lot of this in. It comes with a set of pre-defined metrics checks out of the box.

analysis:
  metrics:
    - name: request-success-rate
      threshold: 99 # Fail if success rate < 99%
      interval: 1m
    - name: request-duration
      threshold: 500 # Fail if P99 latency > 500ms
      interval: 1m

For common checks (success rate, latency), Flagger is dramatically simpler. It knows how to query Prometheus for standard metrics related to the specified mesh/provider. For custom metrics, you can still use a custom metric template, similar to Argo.

Winner of Round 3: Flagger, by a knockout for most use cases. Its built-in metrics for success rate and latency cover 90% of rollback scenarios and require almost no configuration. Argo’s system is more flexible, but that flexibility comes with a steep complexity cost.

The Final Bell: And The Winner Is…

It depends. (I know, I know. You wanted a clean answer. This is engineering, not a fairy tale.)

Choose Argo Rollouts if:

You are already deeply invested in the Argo ecosystem (Argo CD is your GitOps hammer and everything looks like a nail).
You need maximum flexibility and control over your rollout process and metrics analysis.
You want your application’s deployment manifest to be a single, declarative source of truth.
You enjoy writing custom PromQL queries for fun.

Choose Flagger if:

You want to get a robust, metrics-driven canary deployment running fast.
You love the simplicity of its built-in metrics and sane defaults.
You prefer a tool that works alongside your existing Deployment manifests rather than replacing them.
You’re a fan of the Flux/GitOps Toolkit philosophy.

The Judge’s Decision

Think of it like this:

Argo Rollouts is a professional kitchen. Every pot, pan, and knife is exactly where you want it. You have every ingredient imaginable. You can cook anything, exactly how you want it. But you have to know how to cook.
Flagger is a fancy, smart oven with a million pre-sets. You put in the chicken, press the “ juicy poultry” button, and it just works. It might not sear the skin exactly how you would, but the result is fantastic with minimal effort.

For me, the sheer power and GitOps purity of Argo Rollouts makes it my personal favorite for complex, mission-critical applications. But I have to tip my hat to Flagger for its elegance and simplicity, making progressive delivery accessible to teams that just need it to work without a PhD in Kubernetes networking.

So, stop skydiving with that dubious parachute. Pick your tool, and start deploying with confidence. Your users (and your pager) will thank you.

← → Top