Skip to main content
Let’s explore how Argo Rollouts implements a Blue-Green deployment pattern to switch production traffic between application versions atomically.
A presentation slide with a blue-green gradient background and a centered white title reading "Argo Rollouts - Blue-Green Deployment." A small "© Copyright KodeKloud" appears in the bottom-left corner.
What makes Blue-Green different from Canary:
  • Argo Rollouts still manages ReplicaSets for each version, but in Blue-Green the rollout controller swaps Service resources to redirect traffic from the old ReplicaSet (blue) to the new ReplicaSet (green).
  • The Rollout spec references two Services (in the same namespace):
    • activeService (required): receives production traffic and points to the currently active ReplicaSet (the stable version).
    • previewService (optional): points to the new ReplicaSet so you can validate it without exposing it to production.
Key behaviors:
  • When autoPromotionEnabled is false, promotion to active must be done manually (via CLI or UI).
  • When promotion happens, the controller updates the activeService to point at the new ReplicaSet, switching production traffic atomically.
Table: Blue-Green rollout services
Service rolePurposeExample name
activeServiceRoutes production traffic to the active ReplicaSethighway-bluegreen-active
previewServiceOptional: routes non-production/preview traffic to new ReplicaSethighway-bluegreen-preview
Minimal Rollout spec that demonstrates the blueGreen strategy and both services: 
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-bluegreen
spec:
  replicas: 2
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-bluegreen
  template:
    metadata:
      labels:
        app: rollout-bluegreen
    spec:
      containers:
      - name: rollouts-demo
        image: argoproj/rollouts-demo:blue
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    blueGreen:
      # activeService is mandatory; the rollout controller updates this service
      # to point to the ReplicaSet deemed "active" after promotion.
      activeService: rollout-bluegreen-active
      # previewService is optional; it is updated to point to the new ReplicaSet
      # while production (activeService) continues to serve the old ReplicaSet.
      previewService: rollout-bluegreen-preview
      # autoPromotionEnabled:false disables automated promotion. With this set to
      # false you must manually promote the new ReplicaSet (via CLI or UI).
      autoPromotionEnabled: false
Concrete example — highway animation application
  • Namespace: blue-green
  • 10 replicas of the application for each version (blue or green)
  • Two Services referenced in the strategy: highway-bluegreen-active and highway-bluegreen-preview
Rollout manifest: 
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: highway-bluegreen
  namespace: blue-green
spec:
  replicas: 10
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: highway-bluegreen
  template:
    metadata:
      labels:
        app: highway-bluegreen
    spec:
      containers:
      - name: highway-bluegreen
        image: siddharth67/highway-animation:blue
        ports:
        - containerPort: 3000
        env:
        - name: POD_COUNT
          value: "10"
  strategy:
    blueGreen:
      activeService: highway-bluegreen-active
      previewService: highway-bluegreen-preview
      autoPromotionEnabled: false
Service manifests (two services with identical selectors and ports; only the names differ): 
apiVersion: v1
kind: Service
metadata:
  name: highway-bluegreen-active
  namespace: blue-green
spec:
  selector:
    app: highway-bluegreen
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: NodePort
---
apiVersion: v1
kind: Service
metadata:
  name: highway-bluegreen-preview
  namespace: blue-green
spec:
  selector:
    app: highway-bluegreen
  ports:
    - protocol: TCP
      port: 3000
      targetPort: 3000
  type: NodePort
The preview service is optional. When present, it provides a non-production endpoint for the new ReplicaSet so you can validate the new version before switching production traffic to it.
Deployment steps
  1. Create the namespace:
kubectl create ns blue-green
  1. Apply the manifests:
kubectl apply -f .
# or explicitly
kubectl apply -f rollout.yml -n blue-green
kubectl apply -f service.yml -n blue-green
Verify resources: 
kubectl -n blue-green get all
Expected sample output (consolidated):
  • 10 pods for the current ReplicaSet
  • Two services with NodePort mappings
  • A ReplicaSet that reflects the current revision
NAME                                        READY   STATUS    RESTARTS   AGE
pod/highway-bluegreen-674c49d44d-2xp7m     1/1     Running   0          2m
...
pod/highway-bluegreen-674c49d44d-zf58b     1/1     Running   0          2m

NAME                                 TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)             AGE
service/highway-bluegreen-active     NodePort   10.110.42.78     <none>        3000:30920/TCP      2m
service/highway-bluegreen-preview    NodePort   10.110.199.112   <none>        3000:31981/TCP      2m

NAME                                     DESIRED   CURRENT   READY   AGE
replicaset.apps/highway-bluegreen-674c49d44d   10        10        10      2m
Note: Because both services initially use the same selector, both will route to the same pods (blue). Production traffic is served through the activeService. Introducing a new version (green)
  1. Update the Rollout manifest image to the green tag, for example:
# change this in the Rollout template spec
image: siddharth67/highway-animation:green
  1. Apply the updated rollout manifest:
kubectl apply -f rollout.yml -n blue-green
Behavior:
  • With autoPromotionEnabled: false, Argo Rollouts creates a new ReplicaSet for the green version and updates the previewService to select the new ReplicaSet.
  • Both ReplicaSets run in parallel (10 blue + 10 green), so you’ll see ~20 pods while both versions are active.
  • activeService continues to serve the blue pods (production). previewService points to the green pods for validation.
Verify pods: 
kubectl -n blue-green get pods
Promote the new version to production
  • Use the Argo Rollouts UI, or the kubectl plugin:
kubectl argo rollouts promote highway-bluegreen -n blue-green
After promotion, the rollout controller updates the activeService to point at the green ReplicaSet. Production traffic is now routed to the green pods. Rollback
  • If the green version has issues, you can rollback to a previous revision using the Argo Rollouts UI or CLI. The controller keeps revision history (controlled by revisionHistoryLimit), which enables safe rollbacks.
If autoPromotionEnabled is false, the new ReplicaSet will not receive production traffic until you manually promote it. Make sure to validate the previewService before promotion, and coordinate promotion with your release process.
Observability
  • The Argo Rollouts UI displays the strategy (blue-green), revisions, and which revision is active, preview, or stable.
  • Unlike Canary releases, Blue-Green does not show incremental traffic weights; traffic is switched atomically by updating the activeService.
Quick reference: common commands
TaskCommand
Create namespacekubectl create ns blue-green
Apply manifestskubectl apply -f rollout.yml -n blue-green
List resourceskubectl -n blue-green get all
Promote rolloutkubectl argo rollouts promote <rollout-name> -n <ns>
Get rollout statuskubectl argo rollouts get rollout <rollout-name> -n <ns>
Summary
  • Blue-Green with Argo Rollouts uses two services (active and optional preview) to switch traffic atomically between ReplicaSets.
  • Use previewService to validate new versions without impacting production.
  • Set autoPromotionEnabled to false to require manual promotion for safer releases.
  • Use the Argo Rollouts UI or kubectl plugin for promotion, observation, and rollback.
Links and References

Watch Video