> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/manage-deployments/blue-green-across-platforms.md).

# Blue-Green Deployment Across Platforms

Understand how Blue-Green deployments work across different platforms in Harness CD

## What you will learn from this topic

* How the [Blue-Green deployment strategy](#overview) works in general
* How to run [Blue-Green deployments on Kubernetes](#kubernetes)
* How to run [Blue-Green deployments on Amazon ECS](#amazon-ecs)
* How to run [Blue-Green deployments on AWS Auto Scaling Groups](#aws-auto-scaling-groups)
* How Blue-Green deployment works on [other platforms](#other-platforms), including Azure Web Apps, Tanzu Application Service, Google Cloud Functions, and Helm

### Overview

Blue-Green deployment is a release strategy that minimizes downtime and deployment risk by running two identical production environments called Blue and Green. At any time, one environment serves live production traffic while the other remains idle or serves as a staging environment. When deploying a new version, you deploy to the idle environment, verify it works correctly, and then switch production traffic to it. The previous version remains available for immediate rollback if issues arise.

Harness Continuous Delivery (CD) implements Blue-Green deployments differently for each platform based on that platform's native capabilities and constraints. The core principle remains the same: maintain two parallel environments and control which one receives production traffic. However, the mechanisms for creating these environments, managing traffic routing, and handling rollbacks vary significantly between Kubernetes, Amazon ECS, AWS Auto Scaling Groups, and other platforms.

### Kubernetes

Kubernetes Blue-Green deployments in Harness work by creating two sets of pods labeled with different colors (blue and green) and using Kubernetes Services to route traffic between them. The deployment uses Kubernetes native label selectors to instantly switch which pod set receives production traffic.

Go to [Kubernetes Blue-Green deployment documentation](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md) for complete setup instructions and configuration details.

**First Deployment**

When you perform your first deployment, Harness creates a primary service (from your service manifest) and automatically generates a stage service with a `-stage` suffix. Both services initially point to the same set of pods labeled with `harness.io/color: blue`. This initial pod set runs version 1 of your application, and the primary service receives all production traffic while the stage service remains available for verification. The Stage Deployment step creates the initial pods, points the stage service at them, and waits for all pods to pass readiness probes before proceeding.

![Primary and stage services pointing to the same blue pod set on the first Kubernetes Blue-Green deployment](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-1ccaa0c5940553f2c8d721d072859a23d7fb8585%2Fk8s-bluegreen-1.png?alt=media)

**Second and Subsequent Deployments**

For the second deployment with version 2, Harness creates a new set of pods labeled with `harness.io/color: green` and reuses the existing services. The Stage Deployment step deploys the green pods and updates the stage service selector to point at them. At this point, production traffic still flows to the blue pods (version 1) through the primary service, while you can verify version 2 through the stage service. Once verification completes, the Swap Primary with Stage step updates the primary service selector to point at the green pods, instantly redirecting all traffic to version 2. The stage service selector simultaneously updates to point at the blue pods, keeping version 1 available for rollback. This traffic switch is atomic because it requires only an update to the service selector label.

![Primary service selector switching from blue pods to green pods on a Kubernetes Blue-Green deployment](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-769b8441fe773a264dce5fcdc7b813570588dd1a%2Fk8s-bluegreen-2.png?alt=media)

For third and subsequent deployments, Harness automatically alternates the color labels. Version 3 reuses the blue label, while version 4 reuses the green label; this pattern continues. Rollback is instant because old pods remain running under the stage service. To roll back, Harness updates the primary service selector to point back at the old color label, with no redeployment required. After confirming the new version is stable, you can run a Blue Green Stage Scale Down step to remove old pods and free resources, but this operation is irreversible.

**Key characteristics:** Kubernetes Blue-Green in Harness only supports Deployment workloads (not StatefulSets, DaemonSets, or Jobs), requires a single Deployment per service, and performs atomic traffic switches with no progressive traffic shifting. For progressive rollouts, use Canary deployments instead.

Go to the [Kubernetes Blue-Green deployment guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md) for deployment configuration details.

***

### Amazon ECS

Amazon ECS Blue-Green deployments use separate ECS services mapped to Application Load Balancer (ALB) Target Groups. Harness supports two deployment modes: traditional swap mode, which uses separate listener rules for production and stage environments, and traffic-shifting mode, which uses weighted target groups for progressive rollouts. The choice depends on whether you need instant cutover or gradual traffic migration.

Go to the [ECS deployment tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-deployment-tutorial.md) for detailed setup and configuration.

**First Deployment**

For the first deployment, Harness creates an ECS service with your task definition (version 1) and registers it to the production Target Group, where it receives 100% of traffic. The stage Target Group exists but remains empty. This ECS service is considered the blue environment. The ALB production listener (typically on port 80) routes all user traffic to the production Target Group, while an optional stage listener (port 8080) points to the empty stage Target Group for later use.

![ECS production listener routing all traffic to the first service while the stage Target Group stays empty](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-8408f2172bc0751012f38e9d6998c04536ff5234%2Fecs-bluegreen-1.png?alt=media)

**Second and Subsequent Deployments**

For the second deployment, Harness creates a new ECS service (`myapp__2`) with version 2 of your task definition and registers it in the Target Group stage.

**Traditional Swap Mode:** Harness uses two separate ALB listeners (production on port 80, stage on port 8080). The stage listener allows you to test version 2 before swapping. Once verification passes, the **ECS Blue Green Swap Target Groups** step swaps the listener rules so the production listener points to the Target Group containing version 2 and the stage listener points to the Target Group with version 1. This swap is instantaneous from the user's perspective.

**Traffic Shifting Mode:** Harness uses a single production listener and two Target Groups with configurable weights. The **ECS Blue Green Create Service** step (with `isTrafficShift: true`) deploys the new service to the stage Target Group. Then, the **ECS Blue-Green Traffic Shifting** step gradually shifts traffic from version 1 to version 2 by adjusting weights. You configure the **New ECS Weight** parameter in each traffic shift step (for example, 10%, then 50%, then 100%). You can add multiple traffic-shifting steps with approval gates between them to enable controlled rollouts.

This mode requires you to manually specify which Target Group to use as the stage target for each deployment. You must alternate between Target Groups across deployments because Harness deletes any non-blue services in the stage Target Group at deployment start. If you reuse the stage Target Group that contains your active service, it will be deleted.

Go to the [ECS Blue-Green traffic shifting documentation](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/traffic-shifting.md) for configuration details and step-by-step instructions.

![ECS traffic shifting step gradually moving weight from the old service to the new service across two Target Groups](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-92f3382dda76595ac6ccbf92e1664285b0429558%2Fecs-bluegreen-2.png?alt=media)

For third deployment and beyond, Harness follows the same pattern. In swap mode, it creates a new service (`myapp__3`) and deletes the old non-blue service from the Target Group stage. In traffic shifting mode, you must manually alternate which Target Group is specified as the stage. Rollback in both modes is near-instant by re-swapping the listener rules or by reverting the target group weights. The old service continues to run until explicitly deleted.

**Key characteristics:** ECS Blue-Green supports both atomic and progressive traffic shifting, requires manual Target Group alternation in traffic shifting mode, and works only with Application Load Balancers (Network Load Balancers support only single listener pairs).

The following resources provide additional details on ECS Blue-Green deployments:

* [ECS Blue-Green traffic shifting guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/traffic-shifting.md)
* [ECS deployment tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-deployment-tutorial.md)
* [ECS Blue-Green FAQs](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-blue-green-faqs.md)

***

### AWS Auto Scaling Groups

AWS Auto Scaling Group (ASG) Blue-Green deployments use separate Auto Scaling Groups (entire EC2 instance fleets) for blue and green environments, with traffic controlled via Application Load Balancer Target Group weights. This approach provides progressive traffic shifting between full instance fleets.

Go to the [ASG deployment tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-tutorial.md) for complete setup instructions.

**First Deployment**

For the first deployment, Harness creates an Auto Scaling Group using your provided launch template and ASG configuration. It also creates a launch template with the same name as the ASG, containing your Amazon Machine Image (AMI) and instance configuration. EC2 instances are provisioned based on your desired capacity setting and attached to the production Target Group. The ALB routes 100% of traffic to this initial ASG while the stage Target Group remains empty. This Auto Scaling Group represents the blue environment running version 1.

![ASG with EC2 instances attached to the production Target Group while the stage Target Group stays empty on the first deployment](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-8c3b4202acad2d0b94495aca6f01ea7b11250a99%2Fasg-bluegreen-1.png?alt=media)

**Second and Subsequent Deployments**

For the second deployment, Harness creates a new Auto Scaling Group with a revision suffix (`myapp-asg__2`), a new launch template version with your updated AMI, and provisions a new fleet of EC2 instances. The **ASG Blue Green Deploy** step creates this new ASG, registers it to the stage Target Group, and waits for instances to warm up and pass health checks. During this time, the production ASG continues serving 100% of traffic.

Once the new instances are healthy, the **ASG Traffic Shift** step progressively shifts traffic by adjusting Target Group weights. You configure the **New Autoscaling Group Weight (%)** parameter in each traffic shift step. For example, you might add multiple traffic-shift steps: first shifting 30%, then, after verification, shifting to 100%. You can add approval steps between traffic shifts for controlled rollouts. When you shift to 100%, you can enable the **Downsize Old ASG** option to automatically scale the old ASG down to 0 instances.

Go to the [ASG traffic shifting documentation](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-traffic-shift.md) for configuration details and step-by-step instructions.

![ASG Traffic Shift step moving weight from the old Auto Scaling Group to the new Auto Scaling Group](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-2a797e79b6259c07704590d18ca2fe2eab9c26e8%2Fasg-bluegreen-2.png?alt=media)

For third and subsequent deployments, Harness alternates between updating the two existing Auto Scaling Groups rather than creating new ones. Version 3 updates `myapp-asg__1` (the oldest) with a new launch template, it triggers an Instance Refresh to replace EC2 instances, and shifts traffic `ASG__2` to `ASG__1`. Version 4 does the same with `ASG__2`. This rolling update pattern continues, always maintaining two ASGs that alternate being the active version. Rollback is performed by shifting Target Group weights back to the old ASG, which takes moderate time depending on ALB health check intervals and connection draining settings. After successful deployment, you can downsize or delete the old ASG to reduce costs.

**Key characteristics:** ASG Blue-Green incurs high cost overhead (two full EC2 fleets running simultaneously), has slower deployments due to EC2 provisioning time, supports progressive traffic shifting with the ASG Traffic Shift step, requires pre-built AMIs, and requires Application Load Balancer integration with Target Groups configured.

The following resources provide additional details on ASG Blue-Green deployments:

* [ASG traffic shifting guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-traffic-shift.md)
* [ASG deployment tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-tutorial.md)

***

### Other platforms

**Azure Web Apps**

Azure Web Apps Blue-Green deployments use deployment slots (staging and production). The first deployment goes to the production slot. Subsequent deployments go to the staging slot, and after verification, you swap slots to make staging the production slot. This swap is instantaneous and similar to ECS listener swap mode. The rollback is performed by swapping the slots again.

Go to the [Azure Web Apps deployment guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/azure/azure-web-apps-tutorial.md) to configure Blue-Green deployments for Azure Web Apps.

**Tanzu Application Service**

Tanzu (formerly Pivotal Cloud Foundry) Blue-Green uses Cloud Foundry routes to map applications. The first deployment pushes an app and maps a route to it. Subsequent deployments push a new app version, map the route to the new app, and unmap from the old app. This provides atomic traffic switching with configurable amounts of overlap.

Refer to the [Tanzu deployment guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/tanzu/tanzu-app-services-quickstart.md) to configure Blue-Green deployments.

**Google Cloud Functions**

Google Cloud Functions Blue-Green uses Cloud Run revisions with traffic splitting. New revisions are deployed, and traffic is split between revisions using configurable percentages (0% to 100%). This supports both atomic switches and progressive rollouts similar to ECS traffic shifting.

Go to the [Google Cloud Functions deployment guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/google-cloud-functions/google-functions.md) to configure Blue-Green deployments for Google Cloud Functions.

**Helm**

Harness supports Blue-Green with Kubernetes Helm by applying the Blue-Green strategy to rendered Helm templates, using the same mechanism as native Kubernetes deployments. Native Helm mode does not support Blue-Green or Canary strategies.

Go to the [Helm deployment guide](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/helm/helm-cd-quickstart.md) to configure Blue-Green deployments.

***

## Next steps

After understanding Blue-Green deployment behavior across platforms, go to the relevant platform guide to set up your pipeline:

* [Deployment concepts and strategies](/continuous-delivery/use-continuous-delivery/manage-deployments/deployment-concepts.md): Review strategy comparisons and trade-offs.
* [Create a Kubernetes Blue-Green deployment](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/kubernetes/kubernetes-executions/create-a-kubernetes-blue-green-deployment.md): Configure a full Kubernetes Blue-Green pipeline.
* [ECS Blue-Green traffic shifting](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/traffic-shifting.md): Enable progressive traffic shifting.
* [ECS deployment tutorial](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/ecs/ecs-deployment-tutorial.md): Walk through an end-to-end ECS deployment.
* [ASG traffic shifting](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-traffic-shift.md): Configure weighted Target Group shifting for ASG.
* [AWS ASG deployments](/continuous-delivery/use-continuous-delivery/deploy-services-on-different-platforms/aws/asg/asg-tutorial.md): Walk through an end-to-end ASG deployment.
* [Rollback deployments](/continuous-delivery/use-continuous-delivery/manage-deployments/rollback-deployments.md): Understand how to revert a Blue-Green swap.