Blue-green deployment

Also called: blue-green deploy, red-black deployment

Last updated:

A blue-green deployment keeps two production environments side by side. One, blue, serves all live traffic while the other, green, receives the new release and is verified in isolation. When green is ready the router flips all traffic to it in a single cutover; if a problem appears, you flip straight back to blue. The switch happens at the infrastructure layer and is all-or-nothing.

Blue-green deployment vs feature flags

They operate at different layers. Blue-green swaps the whole environment at once: every user moves to the new build together, and rollback means pointing the router back at blue. A feature flag works one level up, inside a single running environment, toggling an individual feature and serving it to a percentage or a targeted segment of users rather than everyone at once. Blue-green answers "which version of the whole app is live?"; a flag answers "which users see this one feature?". A canary release sits between them, shifting a fraction of traffic to the new version first.

Using them together

The two compose cleanly, because they solve different halves of a release. Deploy the new build with blue-green while the risky feature is dark-launched behind a flag held at 0%, cut traffic over to green, then ramp the feature with a percentage rollout on its own schedule. That is the deploy-versus-release split: blue-green gets the code safely into production, and the flag controls when users actually see the feature. The rollout strategies guide shows how the serving side is configured.

Want the full picture? Read the concept guide: Rollout strategies →

Try it in your own app

Free Solo plan covers 10 flags and 2 environments. No credit card, no demo call — sign up and ship.