Progressive Delivery with Argo Rollouts

By Kokil Thapa | Last reviewed: September 2026

Progressive Delivery with Argo Rollouts turns risky Kubernetes deploys into controlled, measurable releases. A plain Deployment swap replaces every pod at once. That works until a bad build slips through CI. Argo Rollouts adds canary steps, traffic splitting, and automated analysis so you catch errors before most users do. If you already run GitOps with Argo CD or ship Laravel APIs behind an ingress controller, this is the next layer I recommend for production clusters.

What Is Progressive Delivery with Argo Rollouts?

Progressive delivery means releasing software in small, verified steps instead of one big cutover. You send a slice of traffic to the new version, watch error rates and latency, then promote or abort. Feature flags handle application-level toggles. Argo Rollouts handles infrastructure-level traffic control inside Kubernetes.

Argo Rollouts is a CNCF incubating project. It replaces the standard Deployment controller behaviour with a Rollout custom resource. You define steps like “send 20% traffic, wait five minutes, run a Prometheus query, then promote.” The controller manages ReplicaSets, updates Services, and coordinates with ingress controllers or service meshes.

The mental model is simple. Stable pods serve most users. Canary pods receive a growing share. Metrics decide whether the rollout continues. Failed analysis triggers an automatic rollback. That beats watching a dashboard and clicking “undo” at 2 a.m.

How Does Argo Rollouts Differ from Standard Kubernetes Deployments?

A native Deployment supports maxSurge and maxUnavailable for rolling updates. It does not natively split traffic between two versions or pause for metric checks. You can hack this with two Deployments and manual ingress weight changes. That gets messy fast.

Argo Rollouts adds first-class canary and blue-green strategies. It integrates with NGINX Ingress, AWS ALB, Istio, Linkerd, SMI, and Traefik for traffic routing. It also ships an AnalysisRun CRD that queries Prometheus, Datadog, New Relic, or webhooks.

For teams running Linux and Kubernetes infrastructure in Nepal, the trade-off is operational complexity versus deploy safety. A three-person team on a single cluster may start with simple rolling updates. Once you serve paying customers through an API gateway, Argo Rollouts pays for itself after the first bad release it catches.

How Do You Install Argo Rollouts on a Kubernetes Cluster?

Installation takes minutes on any cluster with kubectl access. You need cluster-admin for the initial CRD install. Pin a release tag rather than pulling latest in production.

Install the controller and CRDs

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

kubectl argo rollouts version

Install the kubectl plugin for CLI visibility. On Linux amd64:

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

Verify the controller pod is running:

kubectl get pods -n argo-rollouts
kubectl argo rollouts dashboard

The dashboard runs locally and shows live rollout status. It is useful during your first canary experiments. For production, wire alerts through Prometheus and Alertmanager instead of staring at UI panels.

Enable your ingress or mesh integration

Pick one traffic provider and enable its plugin. For NGINX Ingress:

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

kubectl patch deployment argo-rollouts -n argo-rollouts --type='json' \
  -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--nginx-ingress-classes=nginx"}]'

Consult the official Argo Rollouts NGINX traffic management docs for your ingress class name. Mesh integrations follow similar patterns with Istio VirtualServices or SMI TrafficSplit resources.

How Do You Configure a Canary Rollout with Argo Rollouts?

Below is a practical canary Rollout for a stateless API. It mirrors patterns I use when containerising Laravel services behind Kubernetes. The app itself might be PHP 8.3 on Laravel 12, but the rollout YAML is framework-agnostic.

Define the Rollout manifest

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-rollout
  namespace: production
spec:
  replicas: 6
  strategy:
    canary:
      canaryService: api-canary
      stableService: api-stable
      trafficRouting:
        nginx:
          stableIngress: api-ingress
          annotationPrefix: nginx.ingress.kubernetes.io
          additionalIngressAnnotations:
            canary-by-header: X-Canary
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: success-rate
            args:
              - name: service-name
                value: api-canary.production.svc.cluster.local
        - setWeight: 30
        - pause: {duration: 5m}
        - setWeight: 60
        - pause: {duration: 5m}
        - setWeight: 100
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:2.4.1
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

Key fields deserve attention. canaryService and stableService point to two ClusterIP Services the controller manages. The steps array defines the progressive delivery cadence. Each setWeight shifts ingress traffic. Each pause gives metrics time to stabilise.

Pair Services and an AnalysisTemplate

Create stable and canary Services that select the same label. Argo Rollouts patches pod labels during the rollout. Then define an AnalysisTemplate:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
  namespace: production
spec:
  args:
    - name: service-name
  metrics:
    - name: error-rate
      interval: 1m
      count: 5
      successCondition: result[0] < 0.02
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{service="{{args.service-name}}",status=~"5.."}[2m]))
            /
            sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))

This query fails the step if the canary error rate exceeds 2% across five one-minute intervals. Tune thresholds to your SLO. A booking API on a project like Adventure Third Pole Trek might tolerate slightly higher latency during low season. A payment endpoint should be stricter.

Trigger and watch the rollout

1. Apply the Rollout, Services, Ingress, and AnalysisTemplate manifests.
2. Change the container image tag in Git or patch the Rollout directly.
3. Run kubectl argo rollouts get rollout api-rollout -n production --watch.
4. Confirm traffic weights shift on the ingress controller.
5. Verify Prometheus receives canary metrics with correct labels.

Manual promotion is also supported. Add - pause: {} without a duration to wait for human approval. That hybrid model suits regulated workloads where automation and sign-off coexist.

How Do Blue-Green Deployments Work in Argo Rollouts?

Blue-green swaps all traffic at once after the new version passes checks. It suits apps that cannot run two versions simultaneously, or teams that want instant rollback by switching Service selectors.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-rollout
spec:
  replicas: 4
  strategy:
    blueGreen:
      activeService: web-active
      previewService: web-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
          - templateName: success-rate
        args:
          - name: service-name
            value: web-preview.default.svc.cluster.local
      scaleDownDelaySeconds: 30
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/web:7.1.0
          ports:
            - containerPort: 80

With autoPromotionEnabled: false, the new ReplicaSet runs behind the preview Service until you promote. QA hits the preview URL. Analysis runs against preview traffic. Promotion switches the active Service to the new pods. The old ReplicaSet scales down after scaleDownDelaySeconds.

Blue-green uses more resources during the overlap window. Budget for double pod capacity during deploys. On a cost-sensitive Nepal startup cluster, schedule blue-green deploys off-peak.

What Are Common Production Gotchas with Argo Rollouts?

Most failures I see are configuration gaps, not controller bugs. Address these before your first production canary.

• Missing readiness probes. Unready canary pods still receive traffic if probes are absent. Always define HTTP or TCP readiness checks.
• Metric label mismatch. Prometheus queries must filter on labels your ServiceMonitor or scrape config actually emits.
• Session affinity conflicts. Sticky sessions on NGINX can skew canary measurement. Test with affinity off first.
• Database migrations. Backward-incompatible schema changes break canary deploys. Ship expand-contract migrations separately.
• Resource limits. Doubling ReplicaSets during blue-green spikes node CPU. Set requests and limits on both stable and canary pods.
• GitOps drift. If Argo CD manages the Rollout, ensure sync policies allow the controller to patch Services and Ingress annotations.

If your team still deploys PHP apps with Deployer 7 symlink releases on a single VM, Argo Rollouts is not your first step. Move to containers and a managed cluster first. Then add progressive delivery. The path from enterprise application development on bare metal to Kubernetes is incremental. Rollouts fit the Kubernetes stage, not the Apache vhost stage.

How Do You Integrate Argo Rollouts with GitOps and CI Pipelines?

Argo Rollouts works cleanly with Argo CD. Store Rollout manifests in Git. Argo CD syncs them. CI builds and pushes a new image tag. A bot or pipeline commits the tag bump. The Rollout controller starts the canary automatically.

A typical pipeline for a Laravel API might look like this:

1. Run PHPUnit and static analysis in GitLab CI.
2. Build a container image with PHP 8.3 and push to your registry.
3. Update the image tag in the Rollout manifest via Kustomize or Helm.
4. Argo CD detects the commit and syncs.
5. Argo Rollouts executes canary steps and analysis.
6. Slack or PagerDuty alerts fire on abort.

This mirrors the GitLab CI plus Deployer workflow I run on EC2, but with pod-level control instead of symlink swaps. For JSON manifest linting in CI, a local JSON formatter and validator catches syntax errors before they hit the cluster.

Keep image tags immutable. Never reuse :latest in production Rollouts. Pin digests or semver tags so rollbacks target a known artefact. The same discipline applies when you add automated review steps to CI—every deploy artefact should be traceable to a commit SHA.

For multi-cluster setups, consider whether you need active-active failover first. Read active-active versus active-passive multi-cloud patterns before wiring cross-region rollouts. Progressive delivery per cluster is simpler than coordinated global traffic shifts.

Key Takeaways

• Progressive Delivery with Argo Rollouts adds canary, blue-green, and automated analysis to Kubernetes without replacing your existing GitOps flow.
• Start with a single canary Rollout on a non-critical service; validate Prometheus queries before touching production APIs.
• Pair rollouts with readiness probes, backward-compatible migrations, and immutable image tags—YAML alone does not prevent bad deploys.
• Use canary when two versions can coexist; use blue-green when you need preview validation before a full traffic swap.
• Integrate abort alerts with Alertmanager so failed analysis pages the on-call engineer immediately.
• VM-based Deployer workflows and Kubernetes progressive delivery solve different problems—containerise first, then add Rollouts.

People Also Ask

Is Argo Rollouts the same as Argo CD?

No. Argo CD syncs Git manifests to the cluster. Argo Rollouts manages how new pod versions receive traffic during an update. They complement each other. Argo CD deploys the Rollout resource; Argo Rollouts executes the canary or blue-green strategy defined inside it.

Can you run Argo Rollouts without a service mesh?

Yes. NGINX Ingress, AWS ALB, Traefik, and Gateway API providers all support traffic splitting through Rollouts integrations. A mesh adds finer-grained routing but is not required for basic canary deploys.

What happens when analysis fails during a canary?

The Rollout aborts. Traffic reverts to the stable ReplicaSet. Canary pods scale down. The controller marks the revision as degraded. You fix the image or config, then trigger a new rollout. No manual ingress weight editing is needed.

Does Argo Rollouts work with Helm and Kustomize?

Yes. Rollout manifests live alongside Deployment YAML in Helm charts or Kustomize overlays. Reference AnalysisTemplates by name. Kustomize patches work for image tag updates in CI pipelines.

Ship Safer Releases with Progressive Delivery

Progressive Delivery with Argo Rollouts gives you measurable, reversible Kubernetes deploys. You define the steps once. Metrics gate every promotion. Failed releases roll back before customers notice. That is the standard I aim for when moving client APIs from single-server Deployer releases to container platforms.

Start small. One Rollout, one AnalysisTemplate, one service with solid observability. Expand once the first canary completes without manual intervention. If you want help designing a deploy pipeline for a Laravel, Symfony, or custom API workload, contact us about your infrastructure goals. You can also explore testing and optimization services or review production platforms we maintain for real-world deploy patterns.

For ongoing cluster work, pair Rollouts with support and maintenance and solid API development practices. Validate YAML in CI with a regex tester for log parsing rules tied to your analysis queries. Read more on the blog, browse the full services overview, or learn about my background in shipping production systems since 2010.

Official references: the Argo Rollouts documentation and the Kubernetes Deployment guide cover controller behaviour and native rolling update semantics. Use both when designing your strategy.