Blue-green deployment explained: How it works and when to use it

Blue-green deployment creates a production-ready escape route, but only if both environments can really coexist.

A blue-green deployment runs two equivalent production environments side by side. The blue environment usually serves the current release. The green environment receives the candidate release, is verified without replacing blue, and then becomes production when the team switches traffic. Blue remains available for a defined rollback window.

The colors are labels, not permanent roles. After a successful cutover, green is the live environment and blue becomes the target for the next release. What matters is that the active and inactive environments are distinguishable, independently deployable, and capable of carrying production traffic.

This pattern can reduce deployment downtime and make environment-level rollback much faster. It does not make a release automatically safe. Shared databases, queues, caches, third-party side effects, configuration drift, and weak health checks can all make a routing rollback ineffective. Teams get the value of blue-green deployment only when they design the entire release for temporary coexistence.

How blue-green deployment works

The basic sequence has six steps:

1. Keep the current blue environment serving production.
2. Provision or update the idle green environment with the new application and infrastructure configuration.
3. Verify green through smoke tests, integration tests, synthetic traffic, and operational checks.
4. Move production traffic from blue to green through a load balancer, proxy, service, ingress controller, DNS layer, or platform revision.
5. Observe green under real load while blue remains intact.
6. Promote green permanently or route traffic back to blue, then prepare the idle environment for the next cycle.

AWS defines blue-green deployment as releasing applications by shifting traffic between two identical environments running different versions. Azure Container Apps implements the pattern with revisions, labels, and traffic weights. Both descriptions emphasize the same control point: deployment creates the candidate environment; routing makes it live.

That distinction is useful because it separates two events that are often conflated:

• Deployment moves code and configuration into a production-capable environment.
• Release determines when real users or requests encounter the new behavior.

The traffic switch might be atomic, but it does not have to be. Amazon ECS supports blue-green traffic shifting, and modern routers can put a small percentage on green before completing the cutover. At that point, the topology is blue-green while the exposure policy also resembles a canary.

The environments must be equivalent where it matters

"Identical" does not mean that blue and green have the same resource identifiers. It means they have the same capacity, dependencies, permissions, network behavior, observability, and production configuration necessary to handle the same workload.

Environment parity should include:

• Application artifacts and runtime versions.
• Infrastructure definitions and autoscaling rules.
• Secrets, service identities, and dependency permissions.
• Load balancer health checks and connection-draining behavior.
• Logging, tracing, metrics, and alert labels.
• Background workers, scheduled jobs, and queue consumers.
• Regional placement and production-sized capacity.

Infrastructure as code helps reproduce that shape, but a successful provisioning run does not prove parity. Green can still have a missing permission, stale secret, different rate limit, or new network path. Pre-cutover tests should exercise production dependencies without causing duplicate side effects.

The router is the release control

The switch between environments can happen at several layers:

• A load balancer swaps its active target group.
• A Kubernetes Service changes the labels selected for its pods.
• An ingress controller or service mesh changes route weights.
• A managed platform moves traffic between application revisions or slots.
• DNS changes the destination for a hostname.

The choice affects rollback speed and consistency. A load-balancer change can be nearly immediate, while DNS responses may remain cached until their time-to-live expires. Long-lived WebSocket or streaming connections may remain on blue after new connections begin reaching green. Plan connection draining, retry behavior, and session persistence as part of the switch.

Benefits of blue-green deployment

Blue-green deployment is most useful when the organization needs to change a complete runtime while preserving a known-good alternative.

Fast environment-level rollback

If green shows a serious regression, the team can point traffic back to blue. That is normally faster and more predictable than rebuilding an old artifact during an incident. The rollback mechanism is the same routing control used for cutover, so it can be tested before the release.

This advantage disappears if the pipeline destroys or immediately repurposes blue. A practical DevOps community discussion highlights the operational tension: preserving the previous environment makes fallback possible, while updating it too soon removes the known-good target. Define a rollback window based on how long failures take to emerge, not simply how quickly the next build is ready.

Little or no cutover downtime

Green can start, warm caches, complete readiness checks, and receive synthetic tests before users depend on it. Production traffic moves only after it is ready. This is especially valuable when startup takes minutes, runtime dependencies need warm connections, or an in-place deployment would stop all instances at once.

"Zero downtime" should remain an objective rather than a promise. Connection draining, DNS propagation, stateful sessions, and incompatible clients can still interrupt requests. Measure cutover behavior with representative traffic and define what acceptable disruption means for the service.

Production-like verification before cutover

Because green is built with production infrastructure and dependencies, teams can test more of the real delivery path than a separate staging environment usually permits. They can verify routing, permissions, TLS, autoscaling configuration, telemetry, and dependency access before switching all traffic.

Green is still not proven under full production load. Synthetic checks can miss unusual customer data and long-tail request paths. That is why monitoring and a rollback window remain necessary after the switch.

Infrastructure changes can travel with application changes

A complete green environment can include application code, base images, runtime versions, networking, and infrastructure configuration. That makes the pattern useful for immutable infrastructure and high-risk platform upgrades. Instead of modifying the live environment in place, the team validates a new deployment stamp and then routes traffic to it.

The tradeoff is cost and orchestration complexity. For the overlap period, both environments need enough capacity to serve the workload. Stateful infrastructure may be too expensive or difficult to duplicate, which means the real boundary is often the stateless application tier rather than the entire system.

The hardest part: shared state and database changes

Application instances can be duplicated much more easily than production data. Most blue-green systems therefore share a database, message broker, object store, or another stateful service. During deployment, both application versions may read and write that shared state.

AWS recommends decoupling schema changes from code changes and maintaining backward compatibility while both versions can operate. A common expand-and-contract sequence is:

1. Expand the schema. Add nullable columns, new tables, or new message fields without removing what blue expects.
2. Deploy compatible code. Green can understand both the old and new representations. If necessary, it dual-writes or falls back safely.
3. Migrate and verify data. Backfill separately, with observability and a recovery plan.
4. Switch traffic. Keep blue capable of reading data written during the green period.
5. Close the rollback window. Confirm that green is stable and that no consumers require the old shape.
6. Contract later. Remove obsolete fields, code, or topics in a separate release.

Destructive migrations performed before cutover can make blue unusable even though its servers are healthy. The same risk exists in event schemas: if green publishes a message that blue workers cannot parse, routing web traffic back does not repair the queue. Version contracts and consumer compatibility need the same attention as database tables.

Side effects also cross the color boundary. Green smoke tests must not send real invoices, duplicate notifications, or execute customer transactions. Use test accounts, idempotency keys, isolated queues, or explicit dry-run modes to verify behavior without creating production consequences.

A practical blue-green deployment checklist

A reliable implementation is a release system, not a pair of server groups. Build the workflow in stages.

1. Define the environment boundary

List exactly what blue and green duplicate and what they share. Include compute, network routes, jobs, caches, databases, object storage, queues, scheduled tasks, secrets, and external integrations.

For every shared component, ask whether both versions can use it simultaneously. If the answer is no, either redesign the change for compatibility or choose a different deployment strategy.

2. Make environments reproducible

Provision both colors from the same version-controlled definitions. Use immutable application artifacts so the candidate tested in green is the artifact that receives traffic. Record image digests, configuration versions, schema state, and infrastructure revisions with the deployment.

Do not rely on color names to communicate status. Attach explicit metadata such as active, candidate, release_id, and created_at. This reduces operator mistakes after the colors swap roles.

3. Establish pre-cutover gates

Green should pass more than a process-level readiness probe. Useful gates include:

• Artifact integrity and configuration checks.
• Dependency connectivity and permission tests.
• API contract and integration tests.
• Synthetic critical journeys.
• Security and policy checks.
• Resource and autoscaling verification.
• Telemetry confirmation for the green revision.

Health checks should exercise the application, but they must be safe to repeat. A /health endpoint that returns 200 while a critical database permission is missing is not a meaningful cutover gate.

4. Define traffic and rollback behavior

Specify who can change routing, what the exact command or automation does, how long connections drain, and how quickly the change propagates. Rehearse the switch in a noncritical environment and periodically test production rollback controls.

Set explicit triggers. For example: route back to blue if green's error rate exceeds a fixed ceiling for five minutes, if p95 latency regresses beyond a defined margin, or if a critical business transaction fails. Monitor version-specific signals so the team can distinguish a release regression from an unrelated incident.

5. Cut over and observe

At cutover, verify route state independently rather than trusting the deployment job's exit code. Confirm that new requests reach green, old connections drain as expected, and both user-facing and downstream metrics remain within thresholds.

Microsoft's current safe deployment guidance recommends enough bake time to expose behavior across different regions and usage patterns. The appropriate window can be minutes for an obvious API failure, hours for peak-load behavior, or days for scheduled jobs and infrequent workflows.

6. Retain and then retire the previous environment

Keep blue immutable while it is the rollback target. When the rollback window ends, capture the deployment record and either decommission blue or prepare it for the next candidate.

Automate cleanup to avoid paying indefinitely for abandoned resources, but protect the active and rollback environments from accidental deletion. A cleanup job should select resources by verified release metadata, never by a color label alone.

Blue-green compared with other release strategies

Blue-green, rolling, canary, and feature-flag releases solve overlapping but different problems.

Use blue-green when replacing a runtime or infrastructure unit is the main risk and quick reversal matters. Use a rolling deployment when temporary version coexistence is acceptable and duplicating the environment is wasteful. Use a canary deployment when the team needs to learn from a small production cohort before expansion.

Feature flags in CI/CD add a different control plane. The same application revision can run in both environments while a flag keeps a new feature unavailable, limits it to employees, or exposes it to a percentage of eligible users. This prevents the infrastructure cutover from automatically becoming the product launch.

How feature flags complement blue-green deployment

Blue-green deployment answers, "Which environment handles this request?" A feature flag answers, "Which behavior should this user receive?" Combining them separates infrastructure validation from product exposure.

A team might:

1. Deploy the new code to green with the feature off.
2. Verify the green environment and move production traffic to it.
3. Enable the feature for employees or test accounts.
4. Expand exposure through a percentage rollout.
5. Convert the flag to an A/B test when the goal is to estimate product impact.
6. Remove the old code and retire the flag after the decision.

This layering creates two rollback paths. Routing back to blue reverses an environment-level problem. Turning off the flag reverses an isolated feature problem without moving the whole application. Neither control repairs incompatible data writes, so state design still comes first.

Flag evaluation must also be resilient. Cache configuration locally where supported, choose safe default values, and verify that the inactive code path remains functional. GrowthBook's feature flagging platform supports targeted rollouts, while its experimentation platform connects controlled exposure to outcome analysis.

When blue-green deployment is the right choice

Blue-green deployment is a strong fit when:

• Downtime during application startup or replacement is unacceptable.
• The previous release must remain available for rapid routing rollback.
• Infrastructure is reproducible and the duplicate-capacity cost is manageable.
• Application versions can coexist against shared state.
• The team can observe and automate traffic switching reliably.
• A runtime, base image, network, or infrastructure change needs production-like verification as a unit.

It may be a poor fit when the main risk is an irreversible database migration, duplicating capacity is prohibitively expensive, traffic cannot be routed consistently, or external side effects make concurrent versions unsafe. A rolling update, a small canary, regional deployment stamps, or a flag-gated release may control the actual risk more directly.

The strategy name is less important than the guarantees. If the previous environment is destroyed at cutover, the team does not have a ready rollback target. If only some instances are replaced inside one pool, the process is closer to rolling deployment. If traffic shifts progressively, the team is combining blue-green topology with canary exposure. Document the real behavior so responders know what rollback can and cannot do.

Treat blue-green as a temporary coexistence contract

The clearest way to design blue-green deployment is to ask whether blue and green can safely operate at the same time. That question exposes the work hidden behind the diagram: compatible schemas, idempotent side effects, versioned messages, production-grade health checks, observable routing, sufficient capacity, and a protected rollback window.

When those conditions hold, blue-green deployment can turn a high-risk replacement into a controlled traffic decision. When they do not, two colored boxes provide little protection.

Feature flags add user-level control after the environment is healthy. If you want to separate deployment, rollout, and experimentation in one workflow, get started with GrowthBook.