What Is Blue-Green Deployment?

Blue-green deployment is a release strategy that maintains two nearly identical production environments. One environment serves live traffic while the other receives and validates the new application version.

When the new version is ready, traffic is switched from the current environment to the new one. Instead of replacing application instances gradually, the deployment changes which complete environment receives production traffic.

Table of Contents

• Why Blue-Green Deployment Exists
• How Blue-Green Deployment Works
  • Blue Environment
  • Green Environment
  • Traffic Switch
• Blue-Green Deployment Step by Step
• How Traffic Is Switched
• Rollback with Blue-Green Deployment
• Database Changes
  • Expand-and-Contract Migrations
• Sessions, Caches, and Background Workers
• Blue-Green vs Rolling Deployment
• Blue-Green vs Canary Deployment
• Production Design Example
• Monitoring and Validation
• Common Blue-Green Deployment Mistakes
• When to Use Blue-Green Deployment
• Conclusion
  • More Articles to Read

Why Blue-Green Deployment Exists

Traditional deployments often replace an application directly in the environment currently serving users.

For example:

Production v1
     ↓
Stop or replace instances
     ↓
Production v2

This creates risk during the transition. If the new version fails, recovery may require another deployment.

Blue-green deployment separates deployment from traffic activation:

Blue  → v1 → Live Traffic
Green → v2 → Validation

The new version can start, warm up, pass health checks, and undergo validation before receiving normal production traffic.

Once it is considered ready:

Blue  → v1
Green → v2 → Live Traffic

The old environment can remain available temporarily as a rollback target.

This separation makes blue-green deployment useful for systems where reducing deployment downtime and shortening rollback time are important.

How Blue-Green Deployment Works

The terms blue and green are simply labels for two environments. Neither color permanently represents production or staging.

After a successful deployment, their roles can reverse during the next release.

Blue Environment

Suppose Blue currently runs application version 1.8:

Load Balancer
     ↓
Blue
v1.8
100% traffic

This is the active production environment.

Green Environment

Version 1.9 is deployed separately to Green:

Blue  → v1.8 → Production traffic

Green → v1.9 → No normal traffic

Green can now initialize dependencies, establish database connections, warm caches, and pass readiness checks without replacing the active application.

Automated tests or internal requests can also exercise Green before the production cutover.

Traffic Switch

After validation, the routing layer moves production traffic to Green:

Before:
Traffic → Blue v1.8

After:
Traffic → Green v1.9

Blue can remain running for a defined rollback period instead of being destroyed immediately.

The next release may then deploy version 2.0 into Blue and switch traffic back.

Blue-Green Deployment Step by Step

A typical release follows this sequence:

1. Blue serves the current production version.
2. The deployment pipeline deploys the new version to Green.
3. Green starts without receiving normal production traffic.
4. Readiness and health checks verify that instances can serve requests.
5. Smoke tests exercise important application paths.
6. Required caches and connections are warmed.
7. The routing layer switches traffic from Blue to Green.
8. Metrics, logs, traces, and business signals are monitored.
9. Blue remains available during the rollback window.
10. Blue is eventually terminated or becomes the target for the next deployment.

The important distinction is that deploying software and exposing it to production traffic are separate operations.

This provides a validation window that does not exist when new instances immediately replace active ones.

How Traffic Is Switched

Blue-green deployment depends on a routing layer capable of directing traffic between environments.

Common mechanisms include:

• load balancer target groups;
• reverse proxy configuration;
• Kubernetes Services;
• service mesh routing;
• cloud traffic-routing services;
• DNS, although DNS caching can make fast rollback less predictable.

A load-balancer-based architecture might look like:

             ┌→ Blue Target Group → v1.8
Load Balancer
             └→ Green Target Group → v1.9

Before deployment:

Blue  = 100%
Green = 0%

After cutover:

Blue  = 0%
Green = 100%

The traffic switch should account for existing connections. A load balancer may stop sending new requests to Blue while allowing in-flight requests or persistent connections to drain gracefully.

For broader zero-downtime routing techniques, see Traffic Routing Strategies for Zero-Downtime Deployments.

Rollback with Blue-Green Deployment

Fast rollback is one of the main advantages of the pattern.

Suppose Green starts producing elevated error rates after the switch:

Traffic → Green v1.9
              ↓
          Errors increase

If Blue is still healthy and compatible with the current system state, routing can return to it:

Traffic → Blue v1.8

This can be significantly faster than rebuilding and redeploying version 1.8.

However, the ability to switch application traffic back does not guarantee that the entire release is reversible.

If version 1.9 has already changed database data or schemas in a way version 1.8 cannot understand, the old Blue environment may no longer be safe.

Rollback therefore depends heavily on backward-compatible state changes.

Database Changes

Database migrations are one of the hardest parts of blue-green deployment because both environments commonly share the same production database.

Blue v1.8 ──┐
            ├→ Production Database
Green v1.9 ─┘

During deployment, both application versions may exist simultaneously. The database schema must therefore support both versions until the old environment is retired.

A destructive migration such as:

ALTER TABLE users
DROP COLUMN full_name;

can immediately break Blue if version 1.8 still reads full_name.

Deployments should instead favor backward-compatible migrations.

Expand-and-Contract Migrations

An expand-and-contract migration separates incompatible schema changes across releases.

Suppose full_name is being replaced by first_name and last_name.

First, expand the schema:

ALTER TABLE users
ADD COLUMN first_name VARCHAR(100);

ALTER TABLE users
ADD COLUMN last_name VARCHAR(100);

The new application version can support both representations while the old application continues using the original column.

Data is migrated gradually. Only after all production application versions stop depending on full_name should a later deployment remove it.

Release A → Add new schema
Release B → Move application usage
Release C → Remove old schema

This approach makes rollback much safer because the previous application version remains compatible during the transition.

Sessions, Caches, and Background Workers

HTTP traffic is not the only state that changes during a deployment.

Blue-green architecture also needs to consider sessions, caches, queues, scheduled jobs, and background workers.

If sessions are stored only in application memory:

User session → Blue instance memory

switching to Green can effectively log users out.

External session storage or stateless authentication avoids tying user state to one deployment environment. Sticky Sessions and Stateless Applications covers this distinction in more detail.

Cache compatibility matters as well. Green may interpret cached objects differently from Blue after serialization or schema changes. Cache keys can be versioned when representations are incompatible.

Background workers require particular care.

Suppose both environments contain workers:

Blue workers  ─┐
               ├→ Same Queue
Green workers ─┘

Starting Green before stopping Blue may cause both versions to process messages simultaneously.

This may be acceptable when consumers are compatible and queue semantics support it, but it can be dangerous when a new version changes message formats or processing behavior.

Deployment plans should therefore define activation separately for request-serving processes and asynchronous workers.

Blue-Green vs Rolling Deployment

A rolling deployment gradually replaces instances of the old version with instances of the new version.

v1 v1 v1 v1
v2 v1 v1 v1
v2 v2 v1 v1
v2 v2 v2 v1
v2 v2 v2 v2

Blue-green maintains two distinct environments and performs a routing cutover.

Rolling deployment can be more resource-efficient, while blue-green provides stronger separation between old and new application environments.

Blue-Green vs Canary Deployment

A canary deployment intentionally exposes the new version to a small portion of production traffic before increasing exposure.

v1 → 95%
v2 → 5%

If metrics remain healthy:

v1 → 75%
v2 → 25%

then

v1 → 0%
v2 → 100%

Traditional blue-green deployment performs a much sharper cutover:

Blue 100% → Green 100%

The techniques can also be combined. A Green environment can first receive a small percentage of traffic and later become the full production environment.

Production Design Example

Consider a stateless API running behind a load balancer.

The current production version is 4.2:

Internet
   ↓
Load Balancer
   ↓
Blue Target Group
   ↓
API v4.2

The deployment pipeline needs to release version 4.3 without interrupting active requests.

First, a Green target group is created or updated:

Blue Target Group  → API v4.2
Green Target Group → API v4.3

Version 4.3 starts and passes infrastructure health checks.

The pipeline then runs smoke tests directly against Green:

GET /health
GET /api/products/8472
POST /internal/deployment-check

Readiness checks verify that the application can reach required dependencies such as the database and cache.

The release uses a backward-compatible database migration, so both versions can operate against the production schema.

After validation, the load balancer switches new requests to Green:

Internet
   ↓
Load Balancer
   ↓
Green Target Group
   ↓
API v4.3

Blue remains running during a 30-minute rollback window.

Monitoring immediately compares:

• HTTP error rate;
• p50, p95, and p99 latency;
• CPU and memory utilization;
• database error rate;
• dependency failures;
• business transaction success rates.

Suppose the previous production error rate was 0.2%, but Green begins returning 3% errors for checkout requests.

The deployment system can route new traffic back to Blue while engineers investigate:

Green v4.3 → removed from production traffic
Blue v4.2  → restored as active environment

No application rebuild is necessary because Blue was deliberately preserved.

After the rollback window expires and Green is considered stable, Blue can be scaled down, removed, or retained as the destination for the next release.

In environments using load balancers, the routing mechanics are closely related to the strategies described in Designing Highly Available Load Balancing Architectures.

Monitoring and Validation

A successful deployment should not be defined only as "the new instances started."

Green can pass health checks while still containing application-level failures.

Useful deployment signals include:

Deployment validation should combine technical and business signals.

An API returning HTTP 200 while silently failing to create orders is not a healthy release.

Observability should therefore be part of the release decision rather than something checked only after users report problems. Observability Best Practices for Production Systems covers the broader monitoring strategy.

Common Blue-Green Deployment Mistakes

• Assuming traffic switching makes every deployment reversible. Incompatible database changes can prevent rollback.
• Destroying Blue immediately. This removes one of the main advantages of the strategy: fast rollback.
• Using destructive schema migrations during cutover. Both application versions may need to work with the database temporarily.
• Ignoring in-flight requests. Existing connections should normally be drained instead of terminated abruptly.
• Keeping sessions only in local memory. Users can lose session state when traffic changes environments.
• Starting duplicate background workers accidentally. Blue and Green may both consume from the same queues.
• Checking only infrastructure health. Healthy processes can still produce broken business behavior.
• Allowing environments to drift. Blue and Green should differ primarily by the application release, not unrelated configuration.
• Ignoring capacity during cutover. Green must be able to handle full production traffic immediately.
• Using DNS as if it were an instantaneous switch. Resolver and client caching can delay traffic changes.

The safest blue-green deployments treat infrastructure, database schemas, asynchronous processing, configuration, and observability as parts of the same release process.

When to Use Blue-Green Deployment

Blue-green deployment is particularly useful when releases require minimal downtime and fast application rollback.

Good candidates include:

• stateless APIs;
• web applications;
• containerized services;
• high-availability production systems;
• applications with backward-compatible database migrations;
• services where maintaining temporary duplicate capacity is acceptable.

The pattern becomes harder when infrastructure is expensive to duplicate, application instances contain important local state, database changes are difficult to make backward compatible, or old and new workers cannot safely coexist.

Blue-green deployment should therefore be selected based on the application's state model and rollback requirements rather than simply because it provides a convenient traffic switch.

Conclusion

Blue-green deployment maintains two production-capable environments so a new release can be deployed and validated separately from the version currently serving users. Production traffic is then switched to the new environment, while the previous environment can remain available for rollback.

The traffic switch itself is the easy part. Reliable blue-green deployments also require backward-compatible database migrations, safe session handling, controlled background workers, connection draining, equivalent environments, sufficient capacity, and strong post-deployment monitoring.

The core principle is: separate deploying a new version from activating it, and preserve the previous version long enough to provide a fast recovery path when the new release fails.

More Articles to Read

• Health Checks, Readiness, and Liveness Probes
• Reliability Best Practices for Production Systems
• Cloud Architecture Best Practices