Blue-Green Deployment: How It Works and When to Use It for Backends
Blue-green deployment keeps two production environments and switches traffic at once for fast rollback. How the pattern works on ALB weighted target groups, ECS and Kubernetes, when it beats rolling deploys, and where Encore fits for backends.
Blue-green deployment is a release pattern that keeps two production-ready environments and moves all user traffic from one to the other in a single cutover. The idle environment becomes the place you stage the next version, and rollback is the same switch in reverse.
For backends that means two sets of compute behind a router that can change where requests go without rebuilding the app. This guide explains how that works on AWS and Kubernetes, when it is worth the extra capacity, and what Encore (infrastructure from code) does and does not do for traffic shifting.
How blue-green deployment works
Label the live environment blue and the idle one green. Deploy the new revision only to green, run smoke tests and migrations against it, then point the load balancer or DNS at green. Blue stays untouched until you are confident, which is why rollback is fast: send traffic back to blue and investigate green offline.
The costly part is duplication. You pay for roughly twice the production compute during the window when both environments are up, and stateful pieces such as databases are shared carefully or migrated in a way that both versions can run. Schema changes have to be backward compatible across the cutover, or the rollback path breaks.
Blue-green at a glance
Patterns on AWS and Kubernetes
Application Load Balancer weighted target groups
An Application Load Balancer can forward a listener rule to more than one target group and assign each a weight. Blue and green are two target groups. Cutover means setting green to weight 100 and blue to 0, as described in AWS's weighted target groups model. Sticky sessions can delay the shift, so teams often shorten or disable stickiness for the cutover window.
ECS with CodeDeploy
Amazon ECS can run a blue/green deployment type controlled by AWS CodeDeploy. CodeDeploy creates a replacement task set, optionally sends test traffic to a second listener, then reroutes production traffic all at once, linearly, or with a canary schedule. You need two target groups, a production listener, and the CodeDeploy IAM role ECS documents for this path.
Kubernetes
On Kubernetes the same idea shows up as two Deployments behind one Service, or as an Ingress/Gateway that switches backends. Service selectors flip from the blue ReplicaSet to the green one, or a mesh shifts a virtual service weight. Progressive delivery tools build on that model; classic blue-green is the special case where the weight jumps from 0/100 to 100/0.
When blue-green is the right choice
Choose blue-green when rollback time matters more than peak capacity cost, when you want a production-shaped rehearsal before users arrive, or when mixed-version traffic is unsafe for the change you are shipping. Skip it for low-risk releases where a rolling update with health checks is enough, and when the database migration cannot run safely against both versions at once.
Shared state is the usual blocker: if the new code writes a schema the old code cannot read, switching back to blue after cutover fails even though the compute switch itself worked.
What does Encore offer for safer releases?
Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. Encore does not provide a built-in blue-green traffic switch or weighted listener controls. On AWS it deploys services as Fargate tasks (or on EKS) behind an Application Load Balancer and rolls out new tasks gradually while old ones are removed, with the load balancer routing only to healthy targets, as described in the AWS infrastructure docs.
What Encore does give you for safer releases:
Set up the app
Run in your terminal to get started locally.
A service that is safe to roll forward and back keeps handlers thin and schema changes expandable:
// hello/hello.ts
import { api } from "encore.dev/api";
export const version = api(
{ expose: true, method: "GET", path: "/version" },
async (): Promise<{ release: string }> => {
return { release: "2026-11-05" };
},
);
Link the app to GitHub. Each pull request gets a preview environment with its own API URL, so frontend and QA can hit the change before merge. Production still uses Encore's rolling deploy into your account: new tasks are introduced gradually while old ones are removed, and only healthy targets receive traffic. Encore provisions an IAM role for the service. An AI coding agent can ship the /version change in the same PR that updates tests and rely on the preview environment for the shared check.
If you need classic blue-green cutover on ECS, that remains an AWS CodeDeploy configuration on infrastructure you manage yourself. Encore provisions application resources from code and gives you preview environments and redeploys, and it does not replace CodeDeploy's traffic switch.
Best fit: Teams that want production deploys in their own cloud with preview environments for review, with rolling updates as the default release path.
Good to know
- Always rehearse the rollback switch, not only the forward cutover.
- Keep migrations expandable (add columns, dual-write, then remove) so blue can still run after green has written data.
- Preview environments are not a second production. They validate behavior; blue-green is about how production traffic moves.
Related guides
Frequently asked questions
What is blue-green deployment?
Blue-green deployment runs two production-capable environments: blue serving live traffic and green running the new version. After green passes checks, you switch the load balancer or router to green. Rollback means switching back to blue.
What is the difference between blue-green and rolling deployment?
A rolling deployment replaces instances or tasks gradually inside one environment, so old and new code share traffic during the rollout. Blue-green keeps the old environment intact and cuts over in one step, which makes rollback a traffic switch instead of a redeploy.
When should I use blue-green deployment for a backend?
Use blue-green when you need instant rollback, want to test the new version on production infrastructure before users see it, or must avoid mixed-version traffic. Prefer rolling deploys when you want to reuse capacity and can tolerate a short mixed-version window.
Does Encore support blue-green traffic shifting?
Encore does not expose a built-in blue-green traffic switch. It deploys backends into your AWS or GCP account with rolling updates behind load balancer health checks, and preview environments per GitHub pull request let you validate a change before it reaches production.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
