Blue-green deployment
bloo green deh-PLOY-ment
A deployment strategy using two identical environments to enable instant cutover and rollback.
Blue-green deployment uses two identical production environments. One (blue) serves live traffic. The other (green) sits idle. When you deploy a new version, you deploy it to the idle environment (green), test it, and then switch traffic from blue to green. If something goes wrong, you switch back. Rollback takes seconds, not minutes or hours.
The beauty is zero downtime. Users never see a maintenance page. There is no moment where the old version is partially replaced by the new one. Traffic switches atomically from one complete, tested environment to another. The DNS or load balancer handles the cutover.
The cost is running two full production environments. For a small application, this is trivial. For a company running hundreds of servers, it doubles infrastructure costs during deployment. That is why many teams keep the idle environment scaled down and only scale it up before a deployment. Cloud infrastructure makes this easier since you only pay for compute while it is running.
Examples
A fintech company deploys with zero tolerance for downtime.
The blue environment runs version 4.2 and handles all payment processing. The team deploys version 4.3 to the green environment and runs the full test suite including payment processing simulations. Everything passes. They switch the load balancer to route traffic to green. Version 4.3 is live. If a critical bug appears within the first hour, one API call switches traffic back to blue, which is still running 4.2.
A database migration complicates blue-green deployment.
Version 5.0 requires a new database column. Both blue and green environments share the same database. The team adds the column with a default value (backwards compatible) before the deployment. The old version ignores the new column. The new version uses it. After confirming the green deployment is stable, the team removes the old column in the next release cycle.
A team automates blue-green switching in Kubernetes.
Two Kubernetes deployments run in the same cluster: app-blue and app-green. A service resource controls which deployment receives traffic. The deploy pipeline updates the idle deployment, runs health checks, and updates the service selector. The switch happens in under a second. The team stores the rollback command in their incident runbook: one kubectl command to switch back.
In practice
Read more on the blog
Frequently asked questions
What is the difference between blue-green and canary deployments?
Blue-green switches all traffic at once from the old version to the new one. Canary gradually shifts traffic: 1% first, then 5%, then 25%, then 100%. Blue-green is simpler but riskier because all users are affected simultaneously. Canary is more cautious because problems are caught when only a small percentage of users are affected. Choose blue-green for fast rollbacks. Choose canary for gradual risk reduction.
How do you handle database changes in blue-green deployments?
Both environments typically share the same database, so schema changes must be backwards compatible. Add new columns with default values before the deployment. Never remove or rename columns until both environments run the new version. Use the expand-contract pattern: expand the schema (add new), deploy the code, contract the schema (remove old). This is the hardest part of blue-green deployments.
Related terms
Gradually rolling out a new version to a small subset of users before making it available to everyone.
Updating instances of an application one at a time (or in batches) so the service stays available.
The process of releasing code to servers where users can access it.
Configuration toggles that control which features are active in production without deploying new code.
The live environment where real users interact with the application.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.