Blue-Green Deployments on Cloud Infrastructure

Two Complete Environments, Only One Serving

A blue-green deployment keeps two full copies of the production environment. One of them, call it blue, is receiving live traffic. The other, green, is idle. You deploy the new release to green while nobody is using it, check it thoroughly, then move traffic across in a single action.

The appeal is that release and exposure become separate events. Installing software stops being the risky moment, because the software is installed on a machine no user can reach. The risky moment shrinks to one switch, and that switch has an inverse.

The colours are arbitrary and they alternate. After the change, green is live and blue is the idle environment that will receive the next release. Nothing is named "production" in the configuration, which takes a little getting used to.

Where the Switch Actually Happens

Everything depends on the layer that decides which environment receives a request. There are four practical choices and they behave very differently.

Load balancer membership

The cleanest option. Both environments register with the balancer as separate pools or target groups, and the switch changes which pool receives traffic. It takes effect in seconds, existing connections can be drained gracefully, and nothing outside the platform needs to know.

A floating or reserved address

Providers that offer a movable public address let you point it at a different server through an API call. This is the usual approach on developer clouds without a managed balancer, and the mechanism is described in floating IPs and failover on developer clouds.

A reverse proxy upstream

If a proxy already fronts the application, the switch is a one line change to the upstream address plus a reload. Cheap, transparent and easy to script, though the proxy host itself becomes a component you must keep highly available.

DNS

Listed last on purpose. Changing a record works, but resolvers and client libraries cache aggressively and some ignore your time to live entirely. Expect a long tail of traffic still arriving at the old environment, as explained in DNS setup for cloud servers. Use it for regional failover, not for routine releases.

The Database Does Not Have Two Colours

This is where the pattern meets reality. Duplicating stateless application servers is easy. Duplicating the data layer is either impossible or expensive, so in almost every implementation both environments share one database.

That shared database must therefore work with both versions of the application at the same time, at least during the switch and the rollback window. Which means schema changes have to be additive and reversible.

The discipline is usually called expand and contract. Add the new column as nullable and deploy code that writes to both the old and the new shape. Once the new release is live and stable, backfill. Only in a later, separate release do you remove the old column and the compatibility code.

Anything that cannot follow that pattern, such as a destructive rename or a type change that loses precision, needs a maintenance window or a more elaborate migration. The options are laid out in database migration strategies.

Proving the Idle Side Is Good

An idle environment is only valuable if you actually test it. Give green its own hostname, reachable internally or restricted by address, so the release can be exercised against production infrastructure before any user reaches it.

Run the health check the balancer will run, then go further: a smoke test that logs in, reads something, writes something and reads it back. Automated in the pipeline, it turns "we think it works" into a pass or fail the switch can depend on.

Warm the new environment before it takes load. Caches are empty, connection pools are unopened and just in time compilation has not happened, so a freshly promoted environment is at its slowest exactly when it inherits full traffic. Sending synthetic requests for a minute costs nothing and avoids a latency spike that looks like a failed release.

The verification step belongs in the delivery workflow rather than in someone's head. Wiring it in is a natural extension of the pipeline described in CI/CD pipelines that deploy to cloud servers.

Rollback as a Route You Have Driven

The entire value of the pattern is that reverting is the same operation in reverse. Keep the old environment running and untouched for a defined period after the switch, long enough to cover the window where problems surface.

Decide in advance what triggers a return: an error rate above a stated level, a latency percentile beyond a stated limit, or any report of data corruption. Written down before the release, that decision takes ten seconds. Debated during an incident, it takes twenty minutes.

Then practise it. A rollback path that has never been executed is a hypothesis. Teams that deliberately switch back and forth during a quiet hour find the missing firewall rule and the stale configuration file at a time when it costs nothing.

Once the retention window passes, the old environment becomes the target for the next release. Redeploy it from scratch rather than leaving it as it was, so that configuration drift never accumulates on the idle side.

How It Compares With Rolling and Canary

Blue-green gives the fastest reversal but exposes every user simultaneously. Canary gives limited exposure but needs weighted routing and per cohort metrics to be worth anything. Plenty of teams combine them: switch a small weight to green first, watch, then move the rest.

Paying for Two of Everything

The obvious objection is capacity. Running a second full environment doubles the compute bill for the application tier, and for a modest service that can be hard to justify.

Several things soften it. The idle environment only needs to exist around a release, so it can be created before the deployment and destroyed after the retention window, which is straightforward when the environment is defined in code. On container platforms the second copy is a set of pods rather than a set of machines, so the marginal cost is small.

The honest guidance is that blue-green suits services where a bad release is expensive and traffic is high enough that a slow rollback hurts. An internal tool used by thirty people does not need it. The shared address style implementations are cheap enough to try on a small platform first, and the DigitalOcean account listings describe an account where reserved addresses and load balancers are both available. The DigitalOcean versus Vultr comparison notes how each handles movable addresses.

DigitalOcean documents the address mechanism in its reserved IP documentation, and AWS covers the target group approach in its Application Load Balancer documentation.

Before You Switch

• Choose a switch layer that takes effect in seconds; avoid DNS for routine releases.
• Make every schema change additive and compatible with the previous release.
• Give the idle environment a private hostname and run real smoke tests against it.
• Warm caches and connection pools before promoting it.
• Write the rollback trigger conditions down before the release starts.
• Keep the previous environment intact for a defined retention window.
• Rebuild the idle side from scratch rather than reusing a drifted one.
• Rehearse the reverse switch while nothing is on fire.