Zero-downtime deployment with blue green

What blue green is

Blue green deployment keeps two identical environments, conventionally called blue and green. Only one serves live traffic at a time; the other is idle. To release a new version you deploy it to the idle environment, test it, then switch the router or load balancer so all traffic flows there. The switch is a single, atomic re-pointing step, so there is no window where old and new are mixed and no moment the site is down.

The name is just a label. The mechanism is: run the new build next to the old build, point traffic at the new one, and keep the old one ready to switch back if the new build fails.

Running two environments

For blue green to work, environments must be switchable without a shared mutable half-step:

• Both environments serve the same hostname, so a switch changes where traffic goes, not what the URL is.
• Use identical configuration, environment variables and database expectations so behaviour matches.
• Handling the database is the hard part. If the new release migrates the schema, the old environment can no longer serve it safely. Plan migrations so both can operate on the data, or accept that schema-changing releases complicate a clean rollback.

A common pattern is automated deployments to a platform that supports instant routing between two slots, preview URLs, or edge configurations. The key requirement is that switching is cheap, repeatable and reversible, not that you hand-manage two servers.

Switching and rollback

The release sequence:

1. Deploy the new build to the idle environment.
2. Run sanity checks against it, ideally via a staging or preview URL.
3. Switch routing so live traffic reaches the new environment.
4. Watch synthetic checks and error rates for a short window.
5. On success, retire the previous environment. On failure, switch back to it immediately.

The same switch that moves traffic forward moves it back, so rollback is symmetric and near-instant. Keep the previous environment warm until you are confident the new release is stable.

Three cautions that usually catch people:

• A blue green switch does not clear caches. Run the cache invalidation needed after a release, as covered in cache invalidation after migration.
• A schema migration that is not backward compatible breaks the ability to roll back cleanly. Treat the database as the one thing that cannot be "switched" as easily as code.
• Blue green avoids downtime from release, but it is separate from cutover during a host move and deployment to live for the first time. Use the right tool for the phase you are in.

Pair that with moving between data centres when the goal is resilience rather than a code release.